NOTIFY-triggered Auto-slaving (was Re: how to list ALL zones of my master server)

[Jim Reid]

>>>>> "Kevin" == Kevin Darcy <kcd at daimlerchrysler.com> writes:

    Kevin> That's ridiculous. Are you saying that no nameserver is
    Kevin> allowed to implement *additional* actions above and beyond
    Kevin> what is explicitly mentioned in the RFCs, in response to a
    Kevin> DNS packet or particular kinds of DNS packets?

No of course not. there are plenty of things in BIND that are not
documented by RFCs: views, port 953 for name server control, logging,
per-zone control hooks, etc. However these things do not affect the
DNS protocols. Or impact interworking with other name servers or
protocols. Unless they use port 953 for something else of course...

What I am objecting to is the proposed misuse of the NOTIFY protocol
for something it was not intended to be used for. And the flimsy logic
that's being used to advance that case. Especially when there are
other, simpler ways of achieving the same result when the master and
slave servers are under the same administrative control. What's more,
you're proposing to use NOTIFY as a surrogate for a DNS provisioning
protocol. Why not do the Right Thing and develop *that* instead of
tinkering with the semantics of NOTIFY?

Your suggestion changes the semantics of NOTIFY. Therefore it's a
protocol change. [The stuff you mentioned like query logging or debug
traces are implementation matters that don't affect the DNS protocol
or interworking. Your proposed change does affect these things.] There
are also gaping holes in your proposal. For example, there's no way in
your proposal for the master server to know if the intended slave has
indeed picked up a copy of the new zone and is serving it. Or for the
target slave to say to the master "no, I can't/won't slave that zone".
This is bad. For a regular NOTIFY according to RFC1996, this is no
problem. The packet is just a strong hint to the slave to get an
updated copy of a zone instead of waiting for its refresh timer to
expire. Data convergence will happen eventually. In your scheme this
can't be guaranteed for on-the-fly zone addition: for instance if the
NOTIFY packet meaning "be a slave for a new zone" goes astray. In fact
a master could well believe a slave knows about a newly-added zone and
serves it when in fact the slave doesn't.

    Kevin> Auto-slaving is an implementation issue, not a protocol issue. 

Wrong. It *is* a protocol issue if the meaning of an already defined
packet, NOTIFY in this case, gets changed. There's a world of
difference between the master saying to a slave "the contents of
foo.com have changed" and "make yourself a slave for foo.com". These
things should not be confused with each other.

    Kevin> It's just another way of provisioning slave zones, a
    Kevin> process which the RFCs do not address.

So address that problem in the proper way with a protocol for
provisioning zones and other DNS configuration data. There's clearly a
demand and a need for such a beast.