Re: Poison in a zone

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On the IETF list, Claus Färber wrote:
> I think the only requirement that's really essential is that the serial
> number changes whenever the data that would be returned by a zone
> transfer changes (even if that breaks database consistency for the SOA
> record's serial number).

It is also essential that two different authoritative servers that
show the same serial number actually serve the same data.

> One strategy to implement this would be to keep an exact copy of a zone
> obtained from other servers for outgoing transfers (so you'll always use
> the original serial number), which is the BIND 9 strategy.
> 
> Another strategy would be to just increment the serial number of a zone
> when it is actually changed by importing glue records from another zone.
> This would solve the synchronisation problem, too: If the parent zone is
> updated too early, the server might throw away the glue record. But it
> will update the parent zone and increase its the serial number when it
> gets an up-to-date copy of the child zone.

In principle, this approach could work on the primary master server
(at least assuming the zone serial number is being maintained by the
server rather than the administrator), but it won't work on a slave.

If a slave "imports" glue into a zone, it can't update the serial
number, and even if it could, that wouldn't make the zone contents
consistent with the master.

Followups to namedroppers, please.
-- 
Andreas Gustafsson, gson@nominum.com


[Index of Archives]     [IETF Annoucements]     [IETF]     [IP Storage]     [Yosemite News]     [Linux SCTP]     [Linux Newbies]     [Fedora Users]