On Fri, 27 Aug 2010, Evan Hunt wrote:
"Non-obvious" isn't the point. We thought of having the file be named
directly after the view, but view names are allowed to include characters
that are forbidden in file names. Before opening the file we'd have to
check the name's legality, ensure it doesn't include "../" at the beginng,
etc. Rather than deal with that, I decided to just hash the view name, and
get a guaranteed-unique, guaranteed-legal filename for each view.
How does this compare with the defaults for, say, the managed keys zones
for each view? In any case, 3bf305731dd26307.nzf isn't obvious, having
more than one configured view will make troubleshooting more difficult for
the uninitiated, and something like dynamic-zones.conf.viewname (where
'viewname' is a sanitized version of such -- say all non-alphanumerics
replaced with underscores or dashes) should be simple enough.
We needed a unique filename for each view because views can't share
new-zone files. (In the prior version, this wasn't explicitly
disallowed, but it caused big ugly failure modes if you tried it.)
Shouldn't named explicitly check for overlap, then? That seems in line
with many of the other sanity checks named does during normal operation...
Why take away the ability to remove arbitrary zones from the current
configuration?
There are two parts to removing a zone: removing it from the currently
running server, and removing it from the configuration file so that it
doesn't come back when you restart.
The second part can only be done with zones that are in the new-zone file.
(You wouldn't want named to be directly editing named.conf.)
If you haven't done the second part, then the zone isn't really "removed",
just temporarily disabled. I felt that if we can't do both parts, we
shouldn't do the first. If you have a strong argument otherwise, though,
I'm listening...
I have a process that implements very careful zone configuration
management and bulk zone updates, which currently triggers per-zone rndc
reloads for existing zones followed by an rndc reconfig if zones have been
added or removed. The problem I've run into is that rndc reconfig is
intolerably slow past 50,000 or so configured zones, and I'm trying to
determine whether addzone/delzone would be a viable option.
So, I explicitly don't want named to be managing the config. Changing the
current server state without touching a config would be a drop-in change
here, whereas having named manage the config removes most of the
visibility I have into whether or not changes were successful. The
boolean error status available from rndc is insufficiently robust for this
purpose, unfortunately; my process makes a number of decisions about
whether or not it should retry an operation based on how it failed.
Of course, none of this would matter if reconfig wasn't a problem with
this many zones, so I'm still interested in that question too... :)
-Rob
_______________________________________________
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users
