Slashdot Mirror
Verisign Speeds Up DNS Updates
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."
From an OpenSRS discussion list last week:
.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).
.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:
.com name server and caches the foo.com NS
.com, so the just-received records displace the cached ones, new TTL
.com/.net isn't particularly relevant.
> 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
sarchasm: The gulf between the author of sarcastic wit and the person who doesn't get it.
However, doesn't that mean they will have to adjust the TTL value of the domains all the way down to 5 minutes, which will raise the number of queries skyhigh compared to what they are at now? (Thanks to caching) You can keep the TTL high if you don't intend on changing your nameservers any time soon. It's just if you want to make a change, the new information will start being spread immediately rather than having an extra day's delay in there for Verisign to do whatever was taking them so long. It really just means that a short TTL now actually has meaning... that the new info will be appearing shortly, rather than have needless checking for the new info to be out while waiting for it to spread.
Except that .com isn't the first TLD to perform rapid updates. AFAIK .info already does this. So spammers can move sites quickly today. No change in that.
This is your sig. There are thousands more, but this one is yours.
Public Interest Registry has been doing this since last September. Less than 5 minutes, according to their announcement.
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.
Now watch as I get modded down for goatse :)
English is easier said than done.
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.
I thought about this also and then concluded that the only way that this makes sense is if he is running a DNS server on a dynamic IP, which is a pretty crappy idea when there are good, cheap, and even free alternatives to hosting your own DNS, especially if you need dynamic dns.
Pretty decent reference
i d=6
-- 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?
People have been running TLDs on home brew webservers for years. Just set up yourname.dyndns.org for your dynamic IP and have www.yourdomain.com as a CNAME record to yourname.dyndns.org.