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

[Kevin Darcy]

Jim Reid wrote:

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

Actually, what he said was that the idea of including metadata in the
NOTIFY protocol-extension was rejected by the Working Group. What I'm
proposing doesn't require the inclusion of metadata in the NOTIFY
protocol-extension. Ergo, what I'm proposing is not something which has
already been rejected by the Working Group in those particular discussions.
Whether it's compatible with the "intent" of the NOTIFY protocol-extension
is a fuzzier question which I address below.

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

No, *you* seem to be assuming that the metadata associated with a master
zone and the metadata associated with slave copies of the zone must be
identical. Different admins could define different metadata for the same
zone. This is exactly *why* my proposal doesn't involve sending metadata
through NOTIFY; because then you get into some sort of negotiation process
to determine what the final metadata should be, and the NOTIFY transaction
doesn't lend itself very well to that.

> Or that it's OK
> to subvert any change control mechanism that's in place for the slave
> server's configuration file.

How is this "subversion"? The slave only auto-slaves if its admin configures
it to do so. It's only doing what it is told to do by its administrator. How
is this "subversion"?

> Or that a slave server is able to change
> its configuration.

The only part of its configuration it would be able to change would be the
list of zones that it auto-slaves from a particular master. And it would
only change this dynamically if it were configured to do so by its own
administrator.

> And what if it's just *some* of these auto-slave
> zones that the slave is to serve?

No problem. The non-auto-slave zones would be configured the way they always
have been. I'm not proposing to *take*away* the ability to define slave
zones manually...

> How do you do that without more
> config file goop or changing the meaning of some bits in the NOTIFY
> packets?

Well, you can't really expect a nameserver to start slaving a new zone
without at least _some_ "config file goop", can you? Yes, you'd need some
"config file goop" for auto-slaving, but it would be only one config file
entry per master, or possibly one config file entry per master for each
"category" of zones to auto-slave (e.g. you might have a different variation
of the template for forward versus reverse zones). Compare this to the
"config file goop" of having one entry per slaved zone, as is necessary
without auto-slaving. Auto-slaving results in a net reduction of "config
file goop".

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

You still don't "get" it, do you? Nothing I have proposed requires any
protocol change nor interferes with the intended use of NOTIFY. It's a
low-impact, implementation-only change.

Now, if someone can come up with a way to implement "slave zone
delete" using NOTIFY without any protocol changes, then I say "more power to
them". But frankly I don't think it can be done, so I'm not proposing any
such thing, and your argument is a straw man.

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

Forget the whole "probation/promotion" idea for now. That would only be for
super-paranoid types and is something I don't think should be included in an
initial implementation.

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

As long as there was a way for the slave to programmatically -- e.g.
regular-expression match on the zone name -- decide which zones to slave and
which not to slave, then this could be accommodated. If not, then I would
say auto-slaving is not an option for that "someone" (or it _could_ be an
option, if the "someone" was willing to periodically go in and suppress the
auto-slaved zones that they didn't want; depending on the ratio of wanted
versus unwanted slave zones, this might still be a lot less work than having
to add a zone definition in named.conf for every zone).

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

Sigh. You still don't "get" it. No standards-track draft is required because
no protocol change is required.

Or did you mean a BCP of some kind?

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

Oh, so now *you* are the one assuming that the master and slaves are under
the same administrative control. Didn't you just accuse me of that?

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

Well, that's fine and dandy if it's already in place. But what if an admin
just wants a quick and easy, automatic way to keep his or her slaves'
configurations up to date? Or, what if the masters and slaves are not under
the same administrative control? I think this feature would be a timesaver
for a lot of admins (including myself). The ones who already have a working
system in place could just decline to use the feature.

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

Okay, once again: NOTIFY was designed to signal zone changes from masters to
slaves, thereby triggering the slave to bring the contents of its slave
zone(s) up to date. The creation of a zone is IMO a "change", so I find it
perfectly reasonable and consistent with the intent of the spec for a slave
to interpret a NOTIFY as a trigger to start slaving a zone. Conversely, I
find it incredibly myopic of you to think that NOTIFY must forevermore be
limited to signalling changes to only *existing* zones. Why construe the
intent of NOTIFY in such a cramped manner?


- Kevin