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

[Evan Hunt]

> I'm having a hard time following the motivation behind these changes.  Why 
> is the filename non-configurable and non-obvious?

"Non-configurable" may change.

"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.

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.)

> 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...

-- 
Evan Hunt -- each at isc.org
Internet Systems Consortium, Inc.