Re: Autoslaving (was Re: rsync vs. axfr-clarify (was: in supportof axfr-clarify))

[Kevin Darcy <kcd@daimlerchrysler.com>]

Paul Vixie wrote:

> i'd like to register my somewhat passive opposition to in-band autoslaving
> as a defined function of the protocol.  out of band methods, like putting
> a list of zones into a "meta-zone" and transferring/postprocessing that,
> work fine.  if we do it in-band, we'll need a way to not just add slaves
> but also move and replace and delete them.  i'm perfectly happy just keeping
> an out of band list of who i want slaving what.  far less complexity inside
> the dns implementation itself that way.  "cron" is my friend.
I don't see that the mechanism I have outlined, when limited in scope to 
slave "adds", complicates the protocol _per_se_. After all, the master 
is going to send initial NOTIFYs to all of its configured slaves anyway, 
regardless of whether they are already configured to be slaves or not, 
and it is going to sign those NOTIFYs if it is configured to do so. How 
is there any more protocol complexity if the slave takes the receipt of 
that signed NOTIFY as a trigger to perform more-work-than-usual behind 
the scenes?

As for auto-UN-slaving, I see no reason why slave "adds" and slave 
"deletes" necessarily need to use the same mechanism. If I were to 
automate auto-UN-slaving at all, I'd probably base it on whether the 
putative master starts responding non-authoritatively to refresh checks. 
Perhaps there could be a configurable threshold, e.g. "x successive 
nonauth refresh-check responses and the zone gets deleted" in order to 
bridge temporary configuration errors on the master. On the other hand, 
one of the beauties of having an automatic NOTIFY-based autoslaving 
("add") mechanism is that if a slave were to accidentally -- or perhaps 
as a result of being hacked -- stop being a slave for a zone, it 
automatically heals itself the next time the zone changes and another 
NOTIFY gets sent out for it.

I'm not sure what you mean by "mov[ing] and replac[ing]" slave zones. In 
my conceptualization of autoslaving, a given nameserver is either slave 
for a zone or not slave for it. So there are only "adds" and "deletes" 
to the list of zones that a given nameserver slaves from some other 
given nameserver. I view the details of how those slave zones are 
configured within the slave (e.g. what servers down the delegation graph 
should get NOTIFYs, who can query the zone, update-forwarding 
configuration, etc.) to be out-of-scope of the autoslaving mechanism 
_per_se_.

Eventually, it might be useful to take a look at the requirements -- or 
lack of same -- for a "nameserver configuration control" protocol. Given 
the current lay of the land, I could see this being implemented through 
SNMP somehow. The autoslaving mechanism I have proposed and partially 
implemented, is a targeted, short- to medium- solution at best, not a 
first pass at or a first step towards a comprehensive 
configuration-control solution.

In any case, the question on the table here is: does a NOTIFY-based 
autoslaving mechanism require protocol-standards action, given that, on 
the one hand, it doesn't change the wire format at all, but, on the 
other, adds more "baggage" to NOTIFY than was originally intended? The 
question of whether it's a good idea or not is probably better suited to 
another forum.

                                                                       
                           - Kevin



--
to unsubscribe send a message to namedroppers-request@ops.ietf.org with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://ops.ietf.org/lists/namedroppers/>