Slashdot Mirror

← Back to Stories (view on slashdot.org)

Verisign Speeds Up DNS Updates

Posted by ryuzaki0 on from the creating-throwaway-domains-now-much-faster dept.

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."

22 of 131 comments (clear)

  1. Thanks, Verisign... by SamMichaels · · Score: 5, Funny

    ...but kissing our asses won't make up for the fact you still want to deprecate NXDOMAIN for SiteFinder.

    1. Re:Thanks, Verisign... by Neon+Spiral+Injector · · Score: 3, Insightful

      Do they change the IP of your DNS server? That's the only case where this would matter. Verisign doesn't control the data served from your DNS server. This change only covers the registration of new domains (they will become active in 5 minutes instead the next day). Or changes to your registration (like DNS servers).

      You can lower the recommened caching timeouts on your own DNS server. So if your ISP changes the IP of your web server other's DNS servers will request the data from your's again sooner. But of course this can place a higher load on your DNS server.

    2. Re:Thanks, Verisign... by GoRK · · Score: 3, Informative

      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.

  2. it's not clear to me... by rritterson · · Score: 5, Insightful

    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)
    1. Re:it's not clear to me... by LostCluster · · Score: 5, Informative

      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.

    2. Re:it's not clear to me... by AKnightCowboy · · Score: 4, Informative
      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?

      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.

  3. "A little-known DNS behavior called credibility" by jea6 · · Score: 5, Informative

    From an OpenSRS discussion list last week:

    > 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 .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.

    --

    sarchasm: The gulf between the author of sarcastic wit and the person who doesn't get it.
  4. Domain Name Portablity... by LostCluster · · Score: 5, Insightful

    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.

    1. Re:Domain Name Portablity... by Anonymous Coward · · Score: 5, Funny
      I browse at +1. ACs need not reply.
      Guess you won't read this, fuck face.
  5. Censorship? by phr2 · · Score: 4, Interesting
    The good part: when you register a new domain, you can publish it immediately and people can start using it right away.

    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.

    1. Re:Censorship? by LostCluster · · Score: 3, Interesting

      Then again, it cuts both ways. If somebody were to get an injunction awarding the domain back to them, it'd be back up right away as well.

      Censorship concerns usually go at the ISP to pull down the content altogheter, as afterall it most likely would still be available by IP address anyway.

      It's in a trademark case that the owner of the trademark might seek to overtake a domain from somebody they don't like. In that case, the publisher can simply repost their content under another domain, or direct people to the IP address and forget about DNS.

  6. Spammer's Delight... by LostCluster · · Score: 5, Interesting

    Verisign's Spin...
    Will rapid DNS updates impact SPAM?
    Verisign anticipates negligible increases in SPAM as a result of more frequent updates to the .com/.net zone files. Rapid updates to .com/.net are consistent with processes in place at other large domain registries today.

    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.

    1. Re:Spammer's Delight... by Erik+Hensema · · Score: 4, Informative

      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.

  7. Glad to see Verisign coming up to the times by gonknet · · Score: 5, Insightful

    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.

  8. Re:Die script kiddie by NanoGator · · Score: 4, Insightful

    "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."
  9. Yep, your org took less than 5 mins by Jayfar · · Score: 4, Informative

    Public Interest Registry has been doing this since last September. Less than 5 minutes, according to their announcement.

    1. Re:Yep, your org took less than 5 mins by The+Lord+of+Chaos · · Score: 4, Funny

      Gee, I wish my wife's orgs would take less than 5 minutes.

  10. Re:Die script kiddie by Anonvmous+Coward · · Score: 5, Funny

    "Will this put an end of DDOS attacks?"

    We're under attack! Rotate DNS frequencies!

  11. Re:Yet another Y2038 problem by Anonymous Coward · · Score: 3, Interesting

    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.

  12. Re:"A little-known DNS behavior called credibility by Landaras · · Score: 4, Funny

    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
  13. Only affects root's maps by rufey · · Score: 5, Informative
    This change doesn't affect anything but the root maps for .com/.net, which contain nothing but NS records for domains.

    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.

  14. What happens in 2038?! by Mercury2k · · Score: 3, Insightful

    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 ;)