[sf-lug] SF-LUG domain runthrough (part 2 of 2)

[Rick Moen]

[Moving from a parallel thread in private mail.]

Quoting Lx Rudis (lx_rudis at sbcglobal.net):

> thank you, rick.  very interesting!

Yr. very welcome.  Not a complaint, and no _huge_ hurry, but I did mean
it when I said to please increase the zonefile's "60" value in the SOA
header, ASAP -- specifically to reduce the loading of my DSL line, 
since ns2.sf-lug.com _is_, after all, my nameserver running in my
garage.

However, I'm obliged to correct what I said about the name of that field:  

That field _used_ to be where "minimum TTL" (aka "default TTL") was
specified in zonefiles.  That's not what it's used for, any more.  My
apologies for confusingly using the old name.   These days (since the
late 1990s), most DNS includes "negative TTL" caching -- caching of the
fact that a DNS reference record (hostname or whatever) was
unresolvable.  And the timeout period for "negative time to live" is
what's now stored in that SOA field.

My own zonefile for linuxmafia.com has comments on most elements of the
SOA record, just to remind me what they're for:

$TTL 86400
$ORIGIN linuxmafia.COM.
@       IN      SOA     ns1.linuxmafia.COM.  rick.deirdre.NET. (
                        2006112700              ; serial
                        7200                    ; refresh 2 hours
                        3600                    ; retry 1 hour
                        2419200                 ; expire 28 days
                        259200                  ; negative TTL 3 days
                        )               

Notice the "259200 seconds" = 3 days in the "negative TTL" value
position:  That's where, by contrast, you have 60 seconds.  You 
need to fix that -- to something like 1-3 hours.


RFC2308 comments:

   Negative caching is useful as it reduces the response time for
   negative answers.  It also reduces the number of messages that have
   to be sent between resolvers and name servers hence overall network
   traffic.  A large proportion of DNS traffic on the Internet could be
   eliminated if all resolvers implemented negative caching.  With this
   in mind negative caching should no longer be seen as an optional part
   of a DNS resolver.

Section 4 explains the 1998 repurposing of the old "minimum TTL" field:

   SOA Minimum Field

   The SOA minimum field has been overloaded in the past to have three
   different meanings, the minimum TTL value of all RRs in a zone, the
   default TTL of RRs which did not contain a TTL value and the TTL of
   negative responses.

   Despite being the original defined meaning, the first of these, the
   minimum TTL value of all RRs in a zone, has never in practice been
   used and is hereby deprecated.

   The second, the default TTL of RRs which contain no explicit TTL in
   the master zone file, is relevant only at the primary server.  After
   a zone transfer all RRs have explicit TTLs and it is impossible to
   determine whether the TTL for a record was explicitly set or derived
   from the default after a zone transfer.  Where a server does not
   require RRs to include the TTL value explicitly, it should provide a
   mechanism, not being the value of the MINIMUM field of the SOA
   record, from which the missing TTL values are obtained.  How this is
   done is implementation dependent.

   The Master File format [RFC 1035 Section 5] is extended to include
   the following directive:

                           $TTL <TTL> [comment]

   All resource records appearing after the directive, and which do not
   explicitly include a TTL value, have their TTL set to the TTL given
   in the $TTL directive.  SIG records without a explicit TTL get their
   TTL from the "original TTL" of the SIG record [RFC 2065 Section 4.5].

   The remaining of the current meanings, of being the TTL to be used
   for negative responses, is the new defined meaning of the SOA minimum
   field.

Section 5 has:

   As with caching positive responses it is sensible for a resolver to
   limit for how long it will cache a negative response as the protocol
   supports caching for up to 68 years.  Such a limit should not be
   greater than that applied to positive answers and preferably be
   tunable.  Values of one to three hours have been found to work well
   and would make sensible a default.  Values exceeding one day have
   been found to be problematic.

I have personally _not_ found a value of three days to be problematic,
but will ponder the matter again -- because that might be too high.
Anyhow, defaulting to the RFC recommendation (1-3 hours) is a good place
to start.

Note the "$TTL 86400" at the top of my zonefile:  That's the _new_ 
place that "minimum TTL" gets specified.

Again, sorry about getting the name and purpose of that field wrong.