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

[Mark Damrose]

"Jim Reid" <jim at rfc1035.com> wrote in message
news:anbncl$5to2$1 at isrv4.isc.org...
>
>     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?

The intended function of NOTIFY
<QUOTE RFC1996>
Abstract

   This memo describes the NOTIFY opcode for DNS, by which a master
   server advises a set of slave servers that the master's data has been
   changed and that a query should be initiated to discover the new
   data.
</QUOTE>

A new zone is a change, just as much as the contents of an existing zone.

 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.

Yes, it would require extra "goop" in the config file.  All feature changes
do.  If the NOTIFY is one for a zone that is already configured - it is a
standard one. If it is one for a zone that is not already configured - and
the master matches the list allowed to autoconfigure, then it means "add
this zone".

I would modify the proposal to trigger an iterative SOA query - to verify
that the master is authoritive for the zone before adding it.

For removal, if it is an autoconfigured zone and it expires - delete it.
Expired zones are suppressed anyway.  If an expired/deleted zone is fixed on
the master (or the transport problem is fixed) autoconfigure it again.

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

The same thing that happens with a slave that isn't manually configured
(lame server / no zone transfers in log) or with a slave that can't serve
the domain and is manually configured (errors on slave).

 How does the victim server get that message back to the
> source of the NOTIFY? Or is that something to just not bother about?

No response or NOTIMP response triggers an autoconfigure aware master to log
an error.

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

The benefit of using NOTIFY is that it already exists.  If you have multiple
kinds of servers or can't upgrade all at once, it could be made backwards
compatable with existing servers that support NOTIFY.

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

All of which is done offline before adding the zone to the master.

> determining which name servers to use,

This feature would be most usefull if that had been pre-configured and a
policy set to:  All zones created on server1 are slaved on server2, all
zones on server3 slaved on server4, etc.

logging and
> auditing change requests,

Again done before you add/remove zone on master.

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?

For someone setting up a new service, this is something they need to create.
What's wrong with having a standard supported way to do it.  Automating zone
additions on a slave is only valuable if you re-invent it yourself?  How
about the scenario where you have an inter-department or inter-comany
agreement "I'll slave all of yours if you slave all of mine" where only 1
server is under your administrative control?