[sf-lug] SF-LUG DNS
rick at linuxmafia.com
Tue Nov 17 12:17:00 PST 2009
Quoting Michael Paoli (Michael.Paoli at cal.berkeley.edu):
> Yes, definitely still stuff to be done (I keep hoping Jim or someone
> else will get SF-LUG.COM. DNS squared away before the secondary expires
> the zone ... but if the timing gets too close on that, I plan to correct
> it - and in the meantime Jim Stockford and/or other SF-LUG.COM.
> systems/DNS administrators can contact me if they need assistance or
> have questions).
If need be, it's simple to prevent zone expiration by temporarily
telling the secondary that it's master for the zone (until the
replacement master is ready).
> Actually, by coincidence, turns out the "new" (substituted) master DNS
> server is ... well, will be anyway, on the same IP (host is there, but
> last I checked it's not yet serving up DNS nor particularly being DNS
> for SF-LUG.COM.).
OK, good for me, then. ;-> Everything should Just Work when Jim has
the master DNS back online.
> # cat var/named/chroot/var/named/sf-lug.com
> $TTL 86400
> $ORIGIN sf-lug.COM.
> @ IN SOA ns1.sf-lug.com. jim.well.com. (
> 2007102904 ;Serial
> 3600 ;refresh period
> 3600 ;retry period
> 1209600 ;expire period
> 10800) ;minimum TTL period
Minor correction: The last SOA sub-field hasn't signified "minimum TTL
period" since BIND4 days. The above annotation is a dusty holdover,
probably copied from an old example file, and should be replaced. The
new-er purpose of that subfield is "negative TTL" aka "negative
caching", which is how many seconds a nameserver should cache a NAME
ERROR (NXDOMAIN) record.
FYI, the value you specify, 10800 = 3 hours, is the longest time period
for negative caching allowed by RFCs.
FWIW, I tend to use these values in SOAs:
7200 ; refresh 2 hours
3600 ; retry 1 hour
2419200 ; expire 28 days
10800 ; negative TTL 3 hours
[snip suggested steps when moving master DNS]
> Yes, ... not quite the situation in this case.
True, those remarks having been based on the assumption of moving master
DNS to a new IP.
It's still good to let your secondaries know about planned downtime.
Which of course means it's a good idea to keep contact information in
More information about the sf-lug