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

In general terms, NOTIFY was designed as a way for masters to tell slaves
that a change has occurred to a zone. The transition from non-existence
to existence is a change is it not (watch out: I have a degree in
Philosophy so if you want to debate the finer points of ontology, I can
do so until the cows come home)? While this specifc *application* of
NOTIFY may not have been intended, it seems an entirely reasonable use of
the mechanism, not a "corruption" or "abuse". But, I see that in your
text below, you seem to be (baselessly) assuming that some very
intrusive, possibly not-downwards-compatible protocol changes would be
necessary to support this. If I thought that, maybe I'd object too.
Perhaps when you realize that the proposal can be implemented without any
protocol changes, you'll reconsider your position.

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

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

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

[Hey, what about it? Zone removal is outside the of scope of the
proposal. Is this another one of your straw man "logical next step"s? If
I were to automate slave-zone removal, I'd probably base it on whether
the zone has expired or not, or whether zone transfers have been failing,
not on NOTIFY at all.]

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

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

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

Already addressed above.

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

If that's an issue, it's an issue *regardless* of whether NOTIFY is used
as a trigger or not; in fact, it's an issue *whenever* a slave is or
becomes "lame", i.e. is (mis)configured to not be or no longer be slave
for a zone, which can happen any number of ways. The NOTIFY RFC appears
to be mute on this point: it only specifies NOERROR NOTIFY responses, and
only when everything is copasetic. If you think there should be a
mechanism within NOTIFY -- or some other extension to the DNS protocol --
for (non-)slaves to signal masters that they are misconfigured for a
zone, then feel free to propose same. But this issue isn't unique to
NOTIFY-triggered slave-creation, so it doesn't detract from the proposal.

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

NOTIFY-triggering would be a short- to medium-term solution. A
"DNS provisioning protocol" would be a long-term solution. And the
"unsightly warts on [...] the NOTIFY protocol" are only in your
imagination. As far as I see, there are no protocol changes required for
what has been proposed thusfar. If TSIG-signing NOTIFYs is _ipso_facto_ a
protocol violation, then apparently BIND is already committing that
violation:


      203.   [func]          notify and zone soa queries are now
     tsig signed when appropriate.

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

Well Jim, I don't know about your customers, but mine want new zones
available *immediately* (if not yesterday) with full redundancy. With
NOTIFY-triggering, the zones would be slaved almost instantaneously, and
if there is a "promotion" step it could be performed only daily, weekly,
monthly or whatever the administrator configures. So the administrator
would achieve economy of scale; they wouldn't have to be in there
constantly updating named.conf, only the occasional promotion session
where they could "finalize" several (if not hundreds) of zones at once.
And, remember, the whole probation/promotion thing would only be for
super-paranoid sites. In reality, I think most sites would be happy for
this to be completely automated, as long as the NOTIFYs were TSIG-signed,
thus providing reasonable (if not perfect) protection against spoofing.

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

So why are you fighting so hard against automating it?


- Kevin