Best Practices for Authoritative Servers

[Kevin Darcy]

Mark Andrews wrote:
>> Mark Andrews wrote:
>>     
>>>> Mark, that's really clever. Thanks!
>>>>
>>>> As for loops in the AXFR chain, I used to not see the value until a  
>>>> post from Kevin Darcy in this very forum. (I'll just refer readers to  
>>>> the list archive, since I can't find the original post.) Basically,  
>>>> what happens if the primary master goes down in the middle of  
>>>> processing zone transfer requests from two slaves, such that one slave  
>>>> has it and the other does not? Having the slaves use each other as  
>>>> backup master ensures that the updated zone makes it to the other slave.
>>>>     
>>>>         
>>> 	Sure it helps get the latest zone out there.  It also breaks
>>> 	the failsafe that was built into the design of the DNS.
>>> 	You don't want the SOA/IXFR query to the slave to reset the
>>> 	expiry timer.
>>>
>>> 	For the example about resetting the expire timer on change
>>> 	would be reasonable but not on every SOA/IXFR query that
>>> 	is answered by the slave.
>>>
>>> 	
>>>       
>> I don't understand: why would answering SOA/IXFR reset a slave's expiry 
>> timer?
>>
>>                                                                          
>>                         - Kevin
>>     
>
> 	When a slave performs a refresh query (SOA/IXFR) and the
> 	current SOA serial is returned the expiry and refresh timers
> 	are re-started.   This happens regardless of whether the
> 	slave queried the master or another slave.
>   
Thanks for straightening that out. I was misreading your earlier message 
as saying that the act of *answering* a query would reset the expiry 
timer. But of course you are correct: a set of "cross-connected" slaves 
can keep refreshing each other and make the zone "immortal". This is not 
an issue for the vast majority of our zones, since when a zone is 
decommissioned from our master, our homegrown configuration-control 
system will automatically remove the zone definitions from all of our 
slaves. But, we have a few zones here and there that we slave from 
business partners, and we've occasionally run into problems with the 
master becoming unavailable and the cross-connected slaves continuing to 
serve up a stale version. I'll have to put more thought into how to 
prevent that from happening.
> 	If you have a loop in the axfr transfer graph all the slaves
> 	in that loop will converge to serving the same zone content
> 	(good) but will also keep resetting the refresh (with refresh
> 	not retry which is bad) and expiry timers (extremely bad)
>   
It's a shame BIND doesn't have any way of differentiating between "peer" 
masters and "upstream" masters, so that the resetting behavior can be 
controlled.

                                                                         
                        - Kevin