Best Practices for Authoritative Servers

[Mark Andrews]

> Mark,
> 
> When you say "I would have all the slaves just talk to the master," do
> you mean the authoritative slaves talking to the primary master only(and
> not each other), or the resolving servers only talking to the primary
> master (only listing one master in the master substatement, not three as
> we had discussed)?

	I mean every single machine that has
	
		zone "example.net" {
			type slave;
			....
		};

	Mark
	 
> Thanks,
> 
> Josh
> 
> -----Original Message-----
> From: Mark_Andrews at isc.org [mailto:Mark_Andrews at isc.org]=20
> Sent: Thursday, January 31, 2008 6:16 PM
> To: Chris Buxton
> Cc: Baird, Josh; Bind-Users List
> Subject: Re: Best Practices for Authoritative Servers=20
> 
> 
> > Yes, that's an issue. To resolve it, you might consider entering .2 =20
> > in .3's masters list, and vice versa. This renders the expire timer =20
> > moot as long as you don't lose two servers unexpectedly.
> >=20
> > However, even if you don't, remember the value of the expire timer. =20
> > If .1 (the primary master) goes down, you have until (expire - =20
> > refresh) to fix it before things start to fail. So if your refresh =20
> > timer is set to 1 day, and your expire timer is set to 6 weeks, you =20
> > 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
> --=20
> Mark Andrews, ISC
> 1 Seymour St., Dundas Valley, NSW 2117, Australia
> PHONE: +61 2 9871 4742                 INTERNET: Mark_Andrews at isc.org
-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: Mark_Andrews at isc.org