Best Practices for Authoritative Servers
Baird, Josh
jbaird at follett.com
Fri Feb 1 01:45:47 UTC 2008
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)?
Thanks,
Josh
-----Original Message-----
From: Mark_Andrews at isc.org [mailto:Mark_Andrews at isc.org]
Sent: Thursday, January 31, 2008 6:16 PM
To: Chris Buxton
Cc: Baird, Josh; Bind-Users List
Subject: Re: Best Practices for Authoritative Servers
> 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
More information about the bind-users
mailing list