rndc addzone/delzone in 9.7.2rc1 (was: rndc reconfig delays)

[Timothe Litt]

Seems to me that if you stick with this, a couple of things are necessary
for manageability:

 o Some command to translate a zone file name to a view/zone name, and
vice-versa.  That would enable people to debug based on file contents...

 o A method to migrate zones from today's 'named.conf-configured' to
'named-managed'.  I think this needs to be scalable to Rob's 10k* zones.
Perhaps a migration renames a zone file to the new scheme, and writes a stub
file with a magic token in a file with the old name to tell named to ignore
the named.conf entry and look for the new file?  This way, named.conf can be
cleaned of the old entries at leisure...

  o And, as I think I mentioned before, I'd really prefer to see this
function added to the RFC2136 protocol than added under rndc.  Rndc is not
easy to automate reliably (as Rob notes). And of course it will drive
similar non-standardized approaches in the other nameservers - which is a
hassle for management tools.  If you stick with rndc as the mechanism, I'd
at least like to see a perl library that talks the rncd protocol and
provides reliable communciations and useful status.  (Of course if 2136 were
used, extending Net::DNS (::SEC) would make this easier.)

I have always managed my zones as dynamic - and I think DNSSEC will drive
many others to do the same.  I'm all in favor of making it possible to
add/delete zones dynamically - but it has to be possible to
mange/troubleshoot the result.  (Other interesting operations are 'rename',
and perhaps 'copy'....)


---------------------------------------------------------
This communication may not represent my employer's views,
if any, on the matters discussed.
-----Original Message-----
From: Rob Foehl [mailto:rwf at loonybin.net] 
Sent: Friday, August 27, 2010 18:46
To: Evan Hunt
Cc: bind-users at lists.isc.org
Subject: Re: rndc addzone/delzone in 9.7.2rc1 (was: rndc reconfig delays)

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