> 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.

Reply via email to