Best Practices for Authoritative Servers

[John Wobus]

On Jan 31, 2008, at 6:15 PM, Chris Buxton wrote:
> ...
>
> First, the resolving servers are authoritative for the zones, they're
> just not listed in the NS RRSet at each zone's apex. I'll call them
> stealth slaves for this discussion.
>
> The decision of whether to list the advertised slaves in the stealth
> slaves' zone statements is up to you. However, the more redundancy,
> the better - there's no downside to listing the advertised slaves as
> masters after the primary master, other than continuing administration
> over time if servers move. But of course if one of four masters move
> to a new address, there's no perceptible immediate harm. So again, no
> downside, some upside, so it's probably a good idea to do what you
> have suggested.

Hm, regarding possible downsides, to get really, really pedantic, there 
could be an issue of "cascading
timeouts".  For example, if, in your SOA, you specify that slaves are 
allowed to serve a zone for 30 days, then the
slave of a slave could be serving the zone 59 days after the zone was 
removed from the master.
Other potential effects include how quickly zone data modifications 
propagate, particularly if the published
slaves update themselves without benefit of NOTIFYs.

One might argue that "what's good for published slaves is good for 
stealth slaves".

But if the set of published authoritative servers are all masters, and 
an op is committed
to keeping them in synch through other means, this "downside" to 
listing them all would
not apply.

John

P.S. Thanks for answering my question regarding how bind9 decides to 
give authoritative responses.