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."
Its not like it kills anyone to wait a few hours for their dns changes to propagate?
There is no god
...but kissing our asses won't make up for the fact you still want to deprecate NXDOMAIN for SiteFinder.
I read the attached link. So, now, when you buy a domain it can take 12-18 hours for it to show up in Verisign's DNS servers. But in the future, it will show up in 5 minutes.
The same seems to be true with making DNS changes (new IP address, etc). 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)
-Ryan
AUWYHSTOT (Acronyms are Useless When You Have to Spell Them Out Too)
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.
What this means on a business level is that it'll be much easier to move websites and mail servers from one provider to another because it'll take minutes rather than days to update the DNS pointers on the root servers. The only people who will be pointed to the old server after a few minutes will be those relying on old cached info.
So... the main barrier for switching web hosting providers has just fallen away.
I'm not sure of the technical implications of this, but as a consumer of domain name registrations (usually consuming for clients who are too dumb to register their domains) this is very helpful.
Glad to see Verisign can do something right for a change.
The bad part: if someone gets Verisign to shut off your DNS, your site goes dark before anyone knows what happened. It's a lot harder for anyone to mirror it when the news starts breaking.
Is it not possible to have a On-Demand update, so if a domain name's DNS has been changed, the owner can trigger an update request.
This might save unnecessary traffics, similar to a hub vs a switch?
Verisign's Spin... .com/.net zone files. Rapid updates to .com/.net are consistent with processes in place at other large domain registries today.
Will rapid DNS updates impact SPAM?
Verisign anticipates negligible increases in SPAM as a result of more frequent updates to the
Translation: When a spamvertized site is unpluged by hosting company X, the spammers can quickly redirect their domain to point at their new server at hosting company Y...
In the cat and mouse game that is spamming, the mice have just gotten an ability to flee faster.
The same thing happened with .org domains a while ago. I was suprised a few weeks ago when I created a .org domain name, and within minutes I could use it.
This DOES NOT speed up DNS changes, but it speeds up the initial creation and modification of domain records - a new domain, or change of a primary/secondary DNS server.
"Will this put an end of DDOS attacks?"
I doubt it. If an ordinary web browser can find the site, then a zombie could too.
"Derp de derp."
Public Interest Registry has been doing this since last September. Less than 5 minutes, according to their announcement.
"Will this put an end of DDOS attacks?"
We're under attack! Rotate DNS frequencies!
Say you have a website that recieves a lot of traffic, and you have banner ads on your website that generate revenue. For some of the people in this position a half a day can be a lot of money. Because of this, it causes a hinderance to switching hosts, and the company hosting has the ability to jack up prices unfairly, because you really don't have much of a choice in leaving.
Now, however, you can leave, it will mean lower hosting prices for everyone. Not to mention, having a process be more efficient is always a good thing, even if to the average person it seems to make no difference.
WANNAWIKI Wannawiki WannaWiki WANNAWIKI!
RFC1035 was written before RFCs had the MUST/SHOULD syntax. That said, a 32-bit serial number in the SOA record is pretty much a MUST.
The solution is to have zone transfer clients transfer the zone regardless of whether the serial number has increased or decreased; this is why DJB's axfr (zone transfer) client does.
Overview for people who don't know DNS: The serial number is used in automated transfers of DNS information to determine whether the information has been updated. If the integer has been increased since the last update, the client knows to to transfer all of the information again. The number is a 31-bit unsigned integer, which means the use of a Unix timestamp for this number will expire in 2038.
the reason has a lot to do with a little-known DNS behavior called credibility
Which became even less well-known after Verisign hijacked DNS with SiteFinder
</sarcasm>
- Neil Wehneman
My legal education, in nifty podcast format
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.
A quote from their site:
;)
"these serial numbers are now based on UTC time encoded as the number of seconds since the UNIX epoch (00:00:00 GMT, 1 January 1970)"
Uhh, call me stupid, but isnt this the kind of moronic thinking thats gonna nail us AGAIN in 2038 when 32bit epoch dates roll over?! Does anyone know if bind can handle 64bit numbers for serials? Or is this just another screwup waiting to be discovered in 2037 just before the internet stops working cause all the DNS servers cant handle > 32bit
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.
In theory this seems reasonable as long as the update requirements don't put undue pressure on the TLD system. I can't imagine they would since technology has far surpassed what was available when these standards were introduced.
There are some obvious, immediate benefits with issues like this. Systems can more quickly route around outages and DDOS attacks.
However, I'm highly suspect that Verisign came up with this idea without some self-interest at the heart of it.
Why do I have this feeling that, any non-Verisign registrar won't get their updates reflected in the root servers as quickly as Verisign's own customers?
This is not agreed-on "DNS behaviour", it's a flawed feature of BIND designed to try to prevent cache poisoning. See Dan Berstein's notes on BIND's credibility mechanism . We don't need any encouragement to make DNS less secure!
So for all secure DNS resolvers, TTL will still be 48 hours until Verisign works out a way to let people update it themselves.
Matthew @ Bytemark Hosting