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