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

[Peter Koch <pk@TechFak.Uni-Bielefeld.DE>]

Kevin Darcy wrote:

> 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 

that dependds on your service model. There is not necessarily a 1:1 relationship
between master and slave, which is why "server replication" is not applicable
in many cases. Then, a slave may depend upon several masters (i.e. may offer
2ndary service to multiple parties). So, you need some notion of ownership
wrt the zones to be slaved. In addition, you need a channel to communicate
back some status information, i.e. addition succeeded/failed for reason x.
We've developed a simple request-response protocol some years ago and did NOT
use DNS as a "transport" mechanism, not only because TSIG wasn't yet around.

> that signed NOTIFY as a trigger to perform more-work-than-usual behind 
> the scenes?

Usually you have more information available than just "slave zone exapmle.com
off dns.example.net". There are - yet implementation specific - details which
need to be piggybacked to the slave request. AXFR limits, some people seem
to believe in them, are one example. You could prenegotiate and configure
some of these, but I do not believe DNS is the best or canonical way to
accomplish this task (although, for XFR limits in particular, that could
quite simply be done in band, i.e. within that particular zone).

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

Also here, a careful design would take into account the current delegation
status of that particular zone.

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

Well, a cracker wouldn't have to stop at the DoS level, they'd insert false
information. Anyway, from an operational perspective I do not really like
the idea, because it is already difficult enough to explain to the average
part time DNS zone maintainer that these things do not happen automagically.
If they'd work automagically only *sometimes*, that might be worse.

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

It can be slave with different sources (owners) of a zone.

> Eventually, it might be useful to take a look at the requirements -- or 
> lack of same -- for a "nameserver configuration control" protocol. Given 

I'd like to discuss this further but I suggest we take this off the list,
because it is not really DNS related. In fact, it looks a bit similar to what
happens at the registry-registrar level.

-Peter

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