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

[Kevin Darcy]

Jim Reid wrote:

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

That's ridiculous. Are you saying that no nameserver is allowed to implement
*additional* actions above and beyond what is explicitly mentioned in the
RFCs, in response to a DNS packet or particular kinds of DNS packets? By
that skewed logic, BIND's query logging and/or debug facilities are protocol
violations, since nothing in the RFCs explicitly mentions them. In the IETF,
there is a line which is drawn between protocol and implementation. The RFCs
cover the specifics of the NOTIFY interaction between a master and a slave.
What the master and/or slave do above and beyond interoperating with each
other is left up to the implementation. Auto-slaving is an implementation
issue, not a protocol issue. It's just another way of provisioning slave
zones, a process which the RFCs do not address.

Would it make any difference to you whether the auto-slaving mechanism ran
outside of the "named" process, e.g. as a cron job that scanned the logs for
new NOTIFYs, as opposed to being integral to "named" itself? If it makes a
difference to you, then step back and see how silly it is to base the
determination of whether something is a protocol issue or not on whether it
is implemented as one process or two. Alternately, if it makes *no*
difference to you, then you are condemning large categories of
locally-deployed "helper" scripts -- which perform nameserver-associated
actions which are not explicitly mentioned in the RFCs -- as "protocol
violations", which is equally silly. Neither "h2n" nor "webmin" violate the
DNS protocol. Your error is in drawing the protocol/implementation line in
the wrong place.

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

In undergraduate Philosophy, we were given a definition of "knowledge" as
"justified, true belief" (whereas an assumption is just a belief without
necessarily any justification or, for that matter, necessarily any truth to
it). The slave _believes_ that the sender of the NOTIFY is a master for the
zone because it is (pre-)configured to believe that. It is _justified_ in
believing it, because it just received an authenticated NOTIFY for the zone
in question. And the belief happens to be _true_. So in what sense does the
slave not "know" that the sender of the NOTIFY is master of the zone? How is
this "knowledge" any less valid than if the slave "knew" about the zone and
its master(s) because it was told so through some proprietary provisioning
protocol? In both cases, the slave's "knowledge" is the result of some local
configuration plus the existence/arrivial of some packet or sequence of
packets (either DNS packets or proprietary-provisioning-protocol
packets) over the wire. I really don't see any relevant difference.

Or, is your beef with the fact that the slave's "knowledge" is simultaneous
with its receipt of the NOTIFY packet? There is nothing in the RFC verbiage
which says the slave must have *prior* knowledge...


- Kevin