Many versions of bind have a parameter that caps TTLs to some rational
maximum value -- by default in bind9, 3 hours. Unfortunately, the
documentation suggests that the purpose of the max-ncache-ttl parameter
is to let you increase the cap, in order to improve performance and
decrease network traffic.
The suggestion that someone made the other day -- that the TTL on zones
be ramped up gradually by the registries after creation or transfer --
is, I think, a good one.
--Prof. Steven M. Bellovin, http://www.cs.columbia.edu/~smb
Records in the control of the registry are the NS records in the parent zone (the "com" zone in this case). Those are non-authoritative and are going to get replaced in caches with data from the authority servers for the delegated zones (ns[12].access.net, in this case), once those servers are reached.
So the TTLs of records in the registry-operated zones will likely have no impact on how long NS records for delegated zones remain in caches.
If panix (or anybody else) wants to increase the time that their NS records stay in caches, the way to do it is to increase the TTLs on the authoritative NS records in their own zones. For panix.com, these appear to be set to 72 hours (the non-authoritative NS records for PANIX.COM in the COM zone have 48-hour TTLs).
I will now sit back wait for Mark Andrews to appear and flame me to death for my inadequate understanding of the DNS. This is, of course, a subtle ploy to help reduce my Ontario winter heating costs, and to avoid having to spend the rest of the afternoon chipping ice off the driveway with a shovel.
Joe
That's provided that the panix.com authoritative NS's are seen in the cache. Not all name servers return the authoritative NS's in an answer. (BIND has an option 'minimal-responses yes_or_no;' that control this. The default is no, but I know of one "yes" user.)
The registrant's copy of the NS set is more credible (RFC 2181 speak) than the registry's copy, so if a cache sees both, the cache tosses the registry copy. But there's no guarantee that the cache will see both. Usually it does though.
Steven M. Bellovin wrote:
Thus justifying those who load their NS and corresponding NS's A records with nice long TTL
Although this wasn't a problem in this case (hijacker did not appear to have been interested in controlling dns since it points to default domain
registration and under construction page), but long TTL trick could be used by hijackers - i.e. he gets some very popular domain, changes dns to the one he controls and purposely sets long TTL. Now even if registrars are able to act quickly and change registration back, those who cached new
dns data would keep it for quite long in their cache.
Many versions of bind have a parameter that caps TTLs to some rational maximum value -- by default in bind9, 3 hours. Unfortunately, the documentation suggests that the purpose of the max-ncache-ttl parameter is to let you increase the cap, in order to improve performance and decrease network traffic.
The suggestion that someone made the other day -- that the TTL on zones be ramped up gradually by the registries after creation or transfer -- is, I think, a good one.
--Prof. Steven M. Bellovin, http://www.cs.columbia.edu/~smb
From bv9ARM
*max-ncache-ttl*
To reduce network traffic and increase performance the server stores
negative answers. *max-ncache-ttl* is used to set a maximum
retention time for these answers in the server in seconds. The
default *max-ncache-ttl* is 10800 seconds (3 hours).
*max-ncache-ttl* cannot exceed 7 days and will be silently truncated
to 7 days if set to a greater value.
*max-cache-ttl*
*max-cache-ttl* sets the maximum time for which the server will
cache ordinary (positive) answers. The default is one week (7 days).
So loading TTL's to longer than 7 days will have diminishing returns.
Is this really such a good thing?
Joe