[sf-lug] DNS & zone expiry (e.g. SF-LUG.COM. slave), etc.

[Michael Paoli]

So, ... what is that drop-dead deadline on SF-LUG.COM. DNS?  ... that
is, when the slave will expire the zone due to lack of available master?

We have, from ...
http://linuxmafia.com/pipermail/sf-lug/2009q4/007127.html
|$ dig @198.144.195.186 -t SOA sf-lug.com. +short
|ns1.sf-lug.com. jim.well.com. 2007102904 3600 3600 1209600 10800
                                                     ^^^^^^^
$ echo '1209600/60/60/24/7' | bc -l
2.00000000000000000000
$ echo '60*60*24*7*2' | bc -l
1209600
So ... precisely two weeks (without daylight/summer/standard time
changes or leap seconds).

We also have from ...
http://linuxmafia.com/pipermail/sf-lug/2009q4/007139.html
|$ ls -l /var/cache/bind/sf-lug.com.zone
|-rw-r--r-- 1 root root 470 2009-11-11 18:29
|/var/cache/bind/sf-lug.com.zone
If we presume that mtime is from the last zone transfer ... we don't
know the timezone for the above, but also happening to know
approximately when the "old" master was shutdown(8), it's reasonable to
presume the timezone is PST8PDT US/Pacific -0800 ... and if we also
presume the time is quite accurate (e.g. NTP synced), we then have a
drop-dead (zone expiry on slave) deadline of:
2009-11-25T18:29-0800
... not that one should wait that long to correct the situation with
the master (or that such situation should have even occurred as it has),
but, notwithstanding any issues with slave or its availability, slave
should continue to serve up the zone data and not expire it before
2009-11-25T18:29-0800 (but will expire it by 2009-11-25T18:30-0800).

Having a somewhat long expiry time can be advantageous - e.g. in
disaster scenarios ... but it can also have its downsides - notably
slaves (or former slaves) potentially continuing to serve up outdated
data beyond the time it is, or would have been useful.

As some other random data points, balug.org. has 3 week expiry on its
domains (including also 3 subdomains), my employer has 1 week expiry on
most of its domains - both the wholly owned subsidiary where I work (and
am one of the DNS administrators), and (where I'm not one of the DNS
administrators) the owning parent company (large company - over 100,000
employees - such large companies/organizations typically have separate
group(s) that will quite exclusively do DNS administration - such was
also the case with my former employer).

references:
http://linuxmafia.com/pipermail/sf-lug/2009q4/007127.html
http://linuxmafia.com/pipermail/sf-lug/2009q4/007139.html
dig(1)
RFC 1034 Domain names - concepts and facilities:
http://www.ietf.org/rfc/rfc1034.txt
RFC 1035 Domain names - implementation and specification
http://www.ietf.org/rfc/rfc1035.txt