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

From: Paul Vixie <[email-masked]>
Date: Wed, 11 Dec 2002 17:43:12 +0000

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.

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

---

From: Kevin Darcy <[email-masked]>
Date: Wed, 11 Dec 2002 14:02:44 -0500

>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

---

From: Peter Koch <[email-masked]>
Date: Wed, 11 Dec 2002 20:31:08 +0100

> 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 

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

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

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

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

> 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

---

From: Kevin Darcy <[email-masked]>
Date: Wed, 11 Dec 2002 15:16:18 -0500

>use DNS as a "transport" mechanism, not only because TSIG wasn't yet around.
I already have a notion of ownership in what I've implemented so far. An 
"autoslave" can have multiple masters for any given zone. As for status 
reporting, the master can always query the zone and see if the putative 
slave answers authoritatively. I don't see the need for a special "channel".

>quite simply be done in band, i.e. within that particular zone).
Right. I'm putting all of that stuff out of scope. The mechanism I'm 
talking about just adds a slave zone. The details of how that slave zone 
is configured is up to the slave, possibly using some out-of-band 
information from the master.

>status of that particular zone.
I don't quite catch your drift. What do you mean by "delegation status"? 
You mean whether the zone is delegated from its parent or not? I'm not 
sure what bearing this has on master/slave replication.

>information. 
The NOTIFY was signed, I'm assuming if that is in place, the zone 
transfers are signed too. Why would someone require NOTIFYs to be signed 
but then accept a zone transfer based on weaker authentication or no 
authentication at all? That seems rather remiss.

>Anyway, from an operational perspective I do not really like
Is it better to have a patchwork of homegrown solutions to the problem? 
Or to force everyone into DJB's server-replication model?
 
It is precisely because I'm sick and tired of my own homegrown solution, 
that I started working on this...

>It can be slave with different sources (owners) of a zone.
Right, slaves and masters for a given zone is potentially a many-to-many 
relationship. But between two given nameservers, either a given zone is 
being replicated between them, or it isn't.

>happens at the registry-registrar level.
Can I count that as implicitly a voice in support of "not a protocol 
change" then? :-)

                                        - Kevin

---

From: Bruce Campbell <[email-masked]>
Date: Wed, 11 Dec 2002 20:36:39 +0100 (CET)

[ post by non-subscriber.  with the massive amount of spam, it is easy to miss
  and therefore delete posts by non-subscribers.  if you wish to regularly
  post from an address that is not subscribed to this mailing list, send a
  message to <listname>[email-masked] and ask to have the alternate
  address added to the list of addresses from which submissions are
  automatically accepted. ]

On Wed, 11 Dec 2002, Kevin Darcy wrote:

> Well, perhaps this is as good a time as any to raise the fact that I've
> been working on an "auto-slaving" mechanism. The basic idea is that upon

http://archive.iecc.com/article/spamtools/20010608005

--==--
Bruce.