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:

    >>  Indeed. However this is the logical next step if NOTIFY was to
    >> be abused like the OP suggested. Why just add the zone and not
    >> have some way of adding the zone-specific configuration info?
    >> Ever heard of the phrase "function creep"?

    Kevin> So are you objecting to the suggestion as it has been
    Kevin> stated, or are you objecting to what you perceive might be
    Kevin> the "logical next step" of the suggestion? 

Both. I'm objecting to a protocol being corrupted and abused for
things it was never designed to do.

    >>  Well for starters the NOTIFY protocol was not intended to do
    >> such a thing.

    Kevin> True, but so what? This mechanism would in no way impede
    Kevin> the intended function of NOTIFY.

Oh yeah? How do you figure that out? If NOTIFY is to be abused for
automatic zone slaving, presumably some header bit -- which one? -- or
extra RR in the packet would be needed to tell the server to slave
some zone instead of treating the packet as a regular NOTIFY. That
means a protocol change. Which is an impediment to the intended
purpose of NOTIFY. Or if the protocol remains unchanged, it implies
some extra config file goop to tell the server which NOTIFYs mean
"NOTIFY" and which mean "add this zone". [Hey, what about "remove this
zone?"] That would require as much admin effort as just adding the
zone{} statements in the first place.

    >> If someone wants a DNS provisioning protocol to add/remove
    >> zones or change zone-specific configuration options, why not
    >> define and implement something that was properly developed for
    >> that specific purpose? Why corrupt another protocol that was
    >> never intended to provide that functionality?

    Kevin> It's not a "corruption". I repeat: this mechanism would in
    Kevin> no way impeded the intended function of NOTIFY.

Yes it does. How would a name server be expected to distinguish
between a regular NOTIFY as defined in RFC1996 and one which means
"slave this zone if you don't already slave it"? And what happens if
the intended slave server can't or won't slave the new zone it's been
told to serve? How does the victim server get that message back to the
source of the NOTIFY? Or is that something to just not bother about?

    Kevin> As for this hypothetical "DNS provisioning protocol", I
    Kevin> agree it would be a useful thing to have. But there is no
    Kevin> proposal, no working group, no development in this area.

So go ahead and start one. This would be a more productive thing to
spend time on than advocating to cruft unsightly warts on to the
NOTIFY protocol.

    Kevin> For an extra helping of paranoia, perhaps the newly-created
    Kevin> zones could be put on "probation" for a while until a human
    Kevin> actually "promotes" the zone to a full-fledged slave
    Kevin> zone. If not promoted within a certain (configurable) time
    Kevin> period, the zone would "expire", and never be auto-created
    Kevin> again absent human intervention. Even if the time period
    Kevin> were set as low as 24 hours, for a busy hosting outfit a
    Kevin> once-a-day "promotion session" would still be a win over
    Kevin> having to log into the slave(s) multiple times a day to
    Kevin> edit named.conf (especially if the promotion operation
    Kevin> could be done remotely-yet-securely, e.g. through rndc).

This is too silly for words. The human who does this "promotion" could
just as easily add new zone{} statements to named.conf, obviating the
need for this bizarre proposal.

Another point: as I'm sure you realise, there's a lot more to serving
DNS zones than updating config files. Anyone who does this job
responsibly will already be doing a lot of provisioning for that zone:
capturing contact details for the zone's admin and technical contacts,
keeping track of contract expiry and renewal dates, making sure the
domain name has been approved by the competent authority (eg corporate
naming standards), determining which name servers to use, logging and
auditing change requests, documenting the name servers that are used,
etc, etc. So the task of adding the zone{} statement is just a one
small part of the overall process. And one that can be automated too.
There will probably be (or should be) a simple workflow item that's
part of routine operations to add and remove zones from name servers.
Given this exists, why bother contorting NOTIFY to do something it was
never intended to do?