Best Practices for Authoritative Servers

[Mark Andrews]

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

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

	Mark
-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: Mark_Andrews at isc.org