TTL for root NS and A records

Jan.Jirousek at chase.com Jan.Jirousek at chase.com
Thu Nov 4 14:08:03 UTC 1999




Hi,

Can someone give me an explanation how BIND (and perhaps various versions from
4.9.3 on) handles TTL expiry of root NS and A records ?

I run an internal DNS "universe" with no ties to external DNS whatsoever, no
forwarding through firewalls etc. I have four root DNS servers and the "dig .
NS" output looks like the following:

---------------------------------------------------------
.                       1D IN NS        dns1.chase.com.
.                       1D IN NS        dns2.chase.com.
.                       1D IN NS        dns3.chase.com.
.                       1D IN NS        dns4.chase.com.
dns1.chase.com.          1H IN A         1.2.3.4
dns2.chase.com.          1H IN A         5.6.7.8
dns3.chase.com.          1H IN A         9.1.2.3
dns4.chase.com.          1H IN A         4.5.6.7
---------------------------------------------------------

All root servers give the same answer for root NS query, all root nameservers
are also authoritative for chase.com (where A records for root nameservers
live). Nameservers through the enterprise have somethig lik ethe above in
db.cache/root.hint files, typically with either none or very high TTLs listed
for each record.

On some nameservers (only a few, typically caching-only BIND 4.9.4P1 servers) we
are getting repeated messages like the following. It is not on startup only, and
the servers seem to be responding to queries normally.

----------------------------------------------------------------------
Oct 24 06:31:37 s0001 named[20006]: sysquery: no addrs found for root NS
(dns1.chase.com)
Oct 24 06:31:37 s0001 named[20006]: sysquery: no addrs found for root NS
(dns2.chase.com)
Oct 24 06:31:37 s0001 named[20006]: sysquery: no addrs found for root NS
(dns3.chase.com)
Oct 24 06:31:37 s0001 named[20006]: sysquery: no addrs found for root NS
(dns4.chase.com)
Oct 24 06:31:37 s0001 named[20006]: ns_req: no address for root server
----------------------------------------------------------------------

It is going like this for quite some time, and the system as a whole appears to
be working fine, but I suspect there is something wrong with root nameserver
records, and the system keeps going mostly because the four root nameservers
records keep getting updated on all nameservers all the time (the same four
nameservers serve many internal domain, so the A records arrive in additional
data of every other request).

I don't have a good hold on the nameservers giving the error messages, but I
sort-of managed to replicate the problem in the lab, with a separate (single)
root server with NS record TTL of 15 minutes and A record TTL of 1 minute. I run
caching only nameserver with Lucent /QIP port of BIND 8.1 in the lab, with the
lab root server in db.cache, which gives me the same messages. It seems to be
unable to answer some queries after the A record expires, but only for a fairly
short period of time, then it refreshes. I will do more testing with it later.

I noticed the public Internet root server A records have higher TTL than
corresponding NS records, e.g.

---------------------------------------------------------
.                   256071  NS  A.ROOT-SERVERS.NET.
A.ROOT-SERVERS.NET.     342471  A   198.41.0.4
---------------------------------------------------------

What happens when the A records for the root nameservers expire, but the NS
records are still in cache. At what point is the hint information used again ?
Any timeouts there ? Is there any recommendation on root nameserver record TTLs
?

I was searching for the information in the list archive, but while these errors
came up several times, it was always due to some firewall/connectivity issue or
db.cache/root.hint misconfiguration. I think I know fairly well how the hint
information is handled on the startup and know a little bit about credibility of
cached records, so there is no need to reiterate that part.

Please cc me directly on replies, I'm only subscribed to the digest list.

Honza Jirousek






More information about the bind-users mailing list