VeriSign's rapid DNS updates in .com/.net

Sat Jul 10 04:03:03 UTC 2004

On Fri, 09 Jul 2004, Robert Boyle wrote:
> Does this also apply to domains with other registrars?

I'm not sure what you mean by "other registrars".  VeriSign sold the
Network Solutions registrar in November 2003 (although it retains a
15% ownership).

The rapid updates apply to all changes from all registrars.

> Does this apply to authoritative name server changes as well?

Do you mean, does it apply to glue records (i.e., A records for name
servers) in the .com/.net zones?  Yes, it does: a change to a name
server's IP address will be reflected just as fast as a change to a
domain's (er, zone's) NS records.

> Also, does this apply to customers who have had their domains
> suspended due to non-payment?

I'm not sure what you mean here, but I think you're referring to
something that's ultimately a registrar issue.  A domain can be placed
on hold status in the registry and its NS records will not appear in
the .com/.net zones.  There are several different hold statuses and
they all prevent a domain's NS records from being published.  It's
possible a registrar could put a domain on hold for non-payment.  Any
changes to its name servers while it's on hold would be propagated
quickly under this new system, as would changes to its hold status, so
if it it was removed from hold, whatever changes that occurred while
it was on hold would be visible quickly.

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.

Matt