> One thing I'd be interested to know, but can't find the answer to on
> VeriSign's FAQ page about this change[1], is whether the TTL value will
> still be 48 hours. If it is, that will mean that although new domains
Verisign Registry's Matt Larson answered this on the NANOG list
late Friday:
One other issue: a few people have sent me private email asking if
we're planning on changing the 48-hour TTL for NS records and A
records in .com/.net. At this point we're not and the reason has a
lot to do with a little-known DNS behavior called credibility. It's
described in RFC 2181 ("Clarifications to the DNS Specification"),
Section 5.4.1, although the concept pre-dates that RFC and has been in
the BIND iterative resolver, for example, since version 4.9 (if memory
serves).
In a nutshell, DNS data has different levels of credibility or
trustworthiness depending on where it's learned from. That's relevant
here because the version of a zone's NS records from the zone's
authoritative servers is more trustworthy than the version obtained
from the zone's parent name servers. For example, the foo.com NS
records received from a foo.com authoritative server are believed over
the foo.com NS records received from a .com name server. Most
"positive" responses include the zone's NS records along with the
specific data requested (such as an A record). So in practice, here's
what happens:
- - An iterative resolver chasing down, for example, A records for
www.foo.com queries a .com name server and caches the foo.com NS
records (with a 48-hour TTL) it receives.
- - The resolver then queries one of the foo.com name servers for the
www.foo.com A records.
- - In the response the resolver receives the www.foo.com A records,
along with foo.com's own version of the foo.com NS records--and this
is the important part--which have the TTL set by the foo.com zone
owner.
- - According to the credibility scale, the just-received foo.com NS
records are more credible than the cached foo.com NS records from
.com, so the just-received records displace the cached ones, new TTL
and all.
In other words, for all the iterative resolvers out there that have
this credibility mechanism, the 48-hour TTL on data in .com/.net isn't
particularly relevant.