Peter Koch wrote:
Kevin Darcy wrote: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".
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 masterthat 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.
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.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).
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.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.
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.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.
Is it better to have a patchwork of homegrown solutions to the problem? Or to force everyone into DJB's server-replication model?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.
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.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.
Can I count that as implicitly a voice in support of "not a protocol change" then? :-)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.