Verisign Speeds Up DNS Updates 131
Changeling writes "According to Matt Larson, a representative of VeriSign Naming and Directory Services, on September 8, 2004 Verisign will be switching from performing 2 updates per day of the .com and .net zones to performing updates every few seconds. According to Matt, 'After the rapid DNS update is implemented, the elapsed time from registrars' add or change operations to the visibility of those adds or changes in all 13 .com/.net authoritative name servers is expected to average less than five minutes." Full story can be found here."
"A little-known DNS behavior called credibility" (Score:5, Informative)
> 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
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
- - An iterative resolver chasing down, for example, A records for
www.foo.com queries a
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
and all.
In other words, for all the iterative resolvers out there that have this credibility mechanism, the 48-hour TTL on data in
Re:it's not clear to me... (Score:5, Informative)
Re:Spammer's Delight... (Score:5, Informative)
Yep, your org took less than 5 mins (Score:5, Informative)
Re:it's not clear to me... (Score:5, Informative)
No. Just because the .com and .net TLDs have a lower TTL should have nothing to do with the TTL on subdomains of that. You'd continue to cache a second level domain per the definition of whatever the administrators set in their zones.
Re:Censorship? (Score:3, Informative)
Now watch as I get modded down for goatse :)
Only affects root's maps (Score:5, Informative)
All that VeriSign is doing is making changes to domains (i.e, new domains, deleted domains, and changing DNS servers for a domain) become visible in the root maps sooner.
For example, if I wanted to move a DNS server for domain x.com, currently, I'd log into my registrar's on-line update program, change the DNS IP address, and wait up to 12 hours for the root map for .com to advertise the new IP address of my DNS server for domain x.com. With the changes, the .com root map will advertise the change within 5 minutes of me making the change. Any queries looking up my NS record after this will see the new IP address for my DNS server(s). Note, however, that DNS servers could have your NS info cached from a lookup that occured 10 minutes before you changed the info, so it could take those DNS servers a while to see the updated information in the root maps.
If I simply wanted to move a web server from IP address a.b.c.d to IP address w.x.y.z in the same domain, and I'm not moving the DNS server, VeriSign increasing the updating of root maps doesn't have anything to do with this.
For those who do make changes to domain information (i.e, IP addresses for DNS servers), or add new domains, this will be a definate plus.
Re:Thanks, Verisign... (Score:4, Informative)
Re:Don't understand DNS (Score:3, Informative)
-- http://computer.howstuffworks.com/dns.htm
Much, much more in-depth reading
-- http://www.dns.net/dnsrd/rfc/ (all relevent RFC's)
FAQ of BIND (The most common DNS server)
-- http://www.nominum.com/getOpenSourceResource.php?
Re:Cool, .com dyn-dns (Score:2, Informative)