NS TTL Discrepancy??

[R. Scott Perry]

> I have a question regarding TTLs, we are seeing discrepancy between our
> NS TTL values (3600) and the parent server TTL values (172800).

This is what appears to be a recently discovered problem.  With .com
and .net domains, there is always a TTL of 172000 (48 hours) for all
NS records served by the parent servers.  Normally, the NS records for
a domain appear in both the zone parent's zone file as well as at the
primary DNS server for the domain.  So the NS records for example.com
may appear at bother X.gtld-servers.net (the .com parent servers) and
at nsX.example.com (the example.com DNS servers).

The problem occurs when the TTL varies between the two.  In theory,
the two records should be identical.  But if the TTL varies *and* is
returned by the domain's DNS servers, a DNS resolver will see both a
TTL of 172800 (from X.gtld-servers.net) and perhaps 3600 (from
nsX.example.com).  As a result, the DNS resolver is required to trust
the results from nsX.example.com.  Therefore, it is going to expire
the record in 3600 seconds.

The first problem is that it is rude.  The .com/.net parent servers
give out 48 hour TTLs for a reason.  Forcing DNS resolvers to go back
before 48 hours is up causes extra load on the .com/.net parent
servers.

The second problem is much bigger.  Let's say that you have an 1800
second TTL on the A records for ns1.example.com and ns2.example.com,
the 2 NS records for example.com.  Let's say you try to get the MX
record for example.com after the 1800 seconds has passed, but before
the 3600 second TTL you gave to your NS record.  If this happens, the
DNS resolver knows to go to ns1.example.com and ns2.example.com, but
it now can't get to them.  The problem is that to get the A record for
ns1.example.com and ns2.example.com, the DNS resolver must go to the
NS records for example.com -- but, it can't get to them without the A
record, and you're stuck in a loop.

This has been known to cause serious problems, specifically with
mailservers, that end up bouncing all E-mail destined to a domain.  I
do not yet know which DNS servers this applies to (although I do know
that at least one version of BIND will do this), and whether an
RFC-compliant DNS server will or will not do this.

It seems that the real problem is with NS A records that have a TTL
that differs from the NS records.  But, if there is a NS TTL
discrepancy, there is likely a TTL difference between the NS record
and the NS's A record.

Again, this appears to be a recently discovered issue, and delves into
the depths of DNS that few people venture into, so there isn't much
information about it yet.
                                   -Scott