Best Practices for Authoritative Servers

[Mark Andrews]

> Yes, that's an issue. To resolve it, you might consider entering .2  
> in .3's masters list, and vice versa. This renders the expire timer  
> moot as long as you don't lose two servers unexpectedly.
> 
> However, even if you don't, remember the value of the expire timer.  
> If .1 (the primary master) goes down, you have until (expire -  
> refresh) to fix it before things start to fail. So if your refresh  
> timer is set to 1 day, and your expire timer is set to 6 weeks, you  
> have almost 6 weeks to notice the problem and fix it before you start  
> having any symptoms appearing.

	For every link in the axfr chain you essential add a expire
	period.  If the chain loops then you have infinite expiry.
	Loops in axfr chains are not good.

	I would have all the slaves just talk to the master.  I
	would also have all slaves run daily checks on the modification
	times for the slave master files and named records the last
	successful refresh in that timestamp.  If that time stamp get
	more than a couple of days old you have a operational
	problem to correct.

	I run something like this from cron daily.  Tune as appropriate.

		find path/to/slaves -type f -mtime +2  |
		mail -E -s "Slave zone not updating" operator-list

	I started doing this when I was running nameservers that
	were slaves to hundreds of zones all run by different
	administrators.  I continue to do this now that I only have
	a couple of zones to manage.  It often caught problems
	before the administator of the master was even aware of the
	problem.

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