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

Jim Reid jim at rfc1035.com
Fri Oct 4 13:27:34 UTC 2002


>>>>> "Fred" == Fred Viles <fv+abuse at nospam.epitools.com> writes:

    >> ...  A DNS provisioning protocol is more likely to get through
    >> the IETF standardisation process than a proposal to overload
    >> the NOTIFY protocol for things it was not designed for. If you
    >> disagree, go write an Internet Draft and see how far it gets at
    >> IETF.

    Fred> You keep ignoring the fact that what Kevin has proposed is a
    Fred> simple BIND feature, not a protocol change.  IETF is not
    Fred> involved.

RFC1996 says NOTHING about slaving newly created zones. Therefore what
is being suggested IS a protocol change, albeit one that does not
alter the wire protocol if Kevin's proposed config file kludge is the
way it gets implemented. The suggestion does change the semantics of a
NOTIFY packet. That IS a protocol change. And it's one that's not
documented in an RFC.

Oh and implementing this feature would appear to contradict Section
3.10 of RFC1996:

   3.10. If a slave receives a NOTIFY request from a host that is not a
   known master for the zone containing the QNAME, it should ignore the
   request and produce an error message in its operations log.

In the scenario you're advocating, the slave server cannot tell that
the NOTIFY came from a known master for the newly-added zone. [It
cannot know in advance that the other server is master for this new
zone since it wasn't aware this zone existed. The suggested config
file change is instructing the slave to assume that.] So at the very
least, this suggestion of you and Kevin means a clarification to RFC1996.


More information about the bind-users mailing list