[sf-lug] SF-LUG DNS

[Rick Moen]

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
your /etc/named.conf[.local].