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> In general terms, NOTIFY was designed as a way for masters
    Kevin> to tell slaves that a change has occurred to a zone. The
    Kevin> transition from non-existence to existence is a change is
    Kevin> it not

It is. But is not a change in the context of what RFC1996 was
developed for. Mark Andrews made that clear. And I'm sure he was
involved in the IETF discussions as NOTIFY was developed.

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

    Kevin> There you go making wild assumptions again. What's wrong
    Kevin> with a simple "if you don't slave this zone already, and
    Kevin> you're configured to slave every zone for which machine
    Kevin> foo.example.com is master, then (assuming the NOTIFY was
    Kevin> verified as coming from foo.example.com) start slaving the
    Kevin> zone from foo.example.com using your configured defaults
    Kevin> for the other metadata"? No header bits required. No
    Kevin> protocol change required.

That is itself a wild assumption. You're assuming the slave server is
under the same administrative control as the master. Or that it's OK
to subvert any change control mechanism that's in place for the slave
server's configuration file. Or that a slave server is able to change
its configuration. And what if it's just *some* of these auto-slave
zones that the slave is to serve? How do you do that without more
config file goop or changing the meaning of some bits in the NOTIFY
packets? 

    >> Hey, what about "remove this zone?"

    Kevin> [Hey, what about it? Zone removal is outside the of scope
    Kevin> of the proposal. Is this another one of your straw man
    Kevin> "logical next step"s? 

It is the logical next step, and not a straw-man. What else would you
expect to happen if NOTIFY was to be contorted into an afterthought
DNS provisioning protocol? Ever heard the expression "if the only tool
you have is a hammer, every problem looks like a nail"? In this
context, NOTIFY is the hammer being proposed for things it was not
designed to do. As one of the protocol developers has told us. If your
idea was adopted, you can be sure someone will propose adding "remove
this zone" as yet another corruption of the NOTIFY protocol.

    >> That would require as much admin effort as just adding the
    >> zone{} statements in the first place.

    Kevin> No, the admin effort is much less, because you just
    Kevin> configure "slave everything from foo.example.com" *once*
    Kevin> and never have to configure anything else for those slave
    Kevin> zones to start popping up indefinitely (unless one adopts
    Kevin> the probation/promotion alternative proposal, but that's
    Kevin> only for super-paranoid types).

You mentioned the idea of manual intervention to "promote" (your
words) these automatically slaved zones into fully-fledged slaved
zones, whatever that is. The effort of doing that -- presumably
logging in to the server, tinkering with named.conf then reloading the
server -- is no different from the amount of work to add new slave
zones by hand.

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

    Kevin> Already addressed above.

No it was not. What if someone wanted to selectively add new slave
zones via NOTIFY? [Not that I want NOTIFY abused like this at all.]
How is a server supposed to selectively decide which of these proposed
NOTIFYs are to be processed and which should be ignored or just logged
as errors? Your proposed solution was far too simplistic: all-or-nothing.

    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> NOTIFY-triggering would be a short- to medium-term
    Kevin> solution. A "DNS provisioning protocol" would be a
    Kevin> long-term solution.

It's probably the short-term solution. 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.

    Kevin> Well Jim, I don't know about your customers, but mine want
    Kevin> new zones available *immediately* (if not yesterday) with
    Kevin> full redundancy. With NOTIFY-triggering, the zones would be
    Kevin> slaved almost instantaneously

The same effect can be achieved with proper management of a set of
name servers under one administrative control. Most folk I know
achieve this perfectly well with minimal effort without extending or
corrupting the meaning of NOTIFY. They have a provisioning system
which keeps track of customer zones. This is used to generate the name
server config files: masters and slaves. The slaves don't need to be
told to do anything fancy for stray NOTIFYs. Of course, not that a
slave should ever need to be told that anyway IMO.

    Kevin> So why are you fighting so hard against automating it?

I'm not. I'm objecting to that automation being done by misuse of a
protocol that was not designed or intended for the purpose some people
here have proposed. If someone wants automatic DNS provisioning, they
should bring forward a protocol that was designed for that function.
They most definitely should not corrupt or abuse an existing protocol.
Especially when it was not designed or intended for that suggested
purpose.