Slashdot Mirror

← Back to Stories (view on slashdot.org)

Faster Updates for DNS Root Servers Arrive

Posted by ryuzaki0 on from the quicker-name-picker-upper dept.

Tee Emm writes "VeriSign's DNS Rapid Update notice period (as announced on NANOG mailing list) expires today. Beginning September 9, 2004 the SOA records of the .com and .net zones will be updated every 5 minutes instead of twice a day. The format of the serial number is also changing from the current YYYYMMDDNN to a new one that depicts the UTC time." We first mentioned this back in July, but it's finally launching now.

13 of 150 comments (clear)

  1. hmm, but is this really a good thing? by The+Pi-Guy · · Score: 5, Insightful

    as I understand it, this would allow for propogation of new domains to be completed faster. this is *theoretically* a good thing, but it means that applications cannot cache DNS as effectively for nonexistant domains. this may end up causing a *lot* heavier load on the root DNS servers. much as we'd all love that functionality (who doesn't want to see their new domain a few minutes after they buy it?), there was a reason why they designed it the way they did.

    1. Re:hmm, but is this really a good thing? by fingon · · Score: 3, Insightful

      It's not very good thing. At least compliant DNS implementations will be doing 144x as much traffic with them as before (assuming infinite load; of course, in practise they will have bit less load).

      I don't see the point myself, domains are not supposed to change every minute anyway.

      --
      -- pending
    2. Re:hmm, but is this really a good thing? by ewithrow · · Score: 4, Insightful

      DNS was designed in the lat 70's, with RFC's appearing in the early 80's. The computational power today is vastly greater than what the routers of the 80's could contend with. I'm sure they would not implement this change if they had not thoroughly outweighed the costs and benefits.

      Oh wait, VeriSign? We're all doomed.

      --
      http://almostsmart.com
    3. Re:hmm, but is this really a good thing? by LostCluster · · Score: 3, Insightful

      This will be a Good Thing(TM) if the DNS root servers can handle the load. Of course, if they can't it'll have to go in the Bad Idea(TM) file.

      The key thing comes down to if we can trust VeriSign to be doing their homework correctly. VeriSign's a very funny company to think about because their entire product line is based on encryption and ID services that define VeriSign as a root of trust... if you don't trust VeriSign to be an honest actor, practically everything they do becomes worthless.

      It's so hard to get trust-based systems to work these days...

    4. Re:hmm, but is this really a good thing? by Gsus411 · · Score: 2, Insightful

      Geeze. Why is everyone talking about the "root servers?" This isn't . (root zone), this is com. and net.! The two are not the same thing!

  2. Why? by tuxter · · Score: 1, Insightful

    Is there any real need for this? Realistically it is going to have very little impact on the average user.

  3. Emergency use by pubjames · · Score: 1, Insightful


    This is great use for emergencies. You can have a backup web server configured identically to the main one. If the first web server goes down, just update the IP address in the domain record and your back on-line in five minutes.

    Good for those of us which host web sites for clients.

  4. Cool.... by Eggplant62 · · Score: 4, Insightful

    Now spammers can rotate through domains faster than ever before!!

  5. Fifteen minutes? by semaj · · Score: 4, Insightful
    From the linked NANOG posting:
    "At the same time, we will also change the "minimum" value in the .com and .net SOA records from its current value of 86400 seconds (one day) to 900 seconds (15 minutes). This change brings this value in line with the widely implemented negative caching semantics defined in Section 4 of RFC 2308."
    Doesn't that mean they're updating every fifteen minutes, not every five?
    --
    Meep meep
    1. Re:Fifteen minutes? by bfree · · Score: 2, Insightful

      It means that dns servers which act like bind4 and bind8 will set the default Time To Live (TTL) for resource records without explicit TTL to 15 minutes. Servers which behave like bind9 will use this as the negative caching value for the domain, meaning that if it requests an ip from a domain which doesn't exist it will cache the result for 15 minutes. In effect this should mean that the actual root dns servers will be updated every 5 minutes, but someone looking for the domain (by normal means as oppossed to manually querying the root servers) just before the update which brings the domain into existance will have to wait 15 minutes before they will see the domain has arrived.

      So they are updating every 5 minutes, but if you are adding a new domain, as opposed to changing the authoritative servers for a domain, you will have to wait 20 minutes (5 for update and 15 for everyone to have lost the negative cache) before you can say "we're up and running".

      --

      Never underestimate the dark side of the Source

  6. This has no effect by warrax_666 · · Score: 4, Insightful

    on how many domains a spammer can register over time -- for much the same reason that you can still have huge bandwidth even if your latency is crap. It's just a question of reducing the initial delay from registration to activation.

    --
    HAND.
  7. 2038 fun by martin · · Score: 2, Insightful

    Oh great so now DNS gets potential issues with 32 bit time-since-epoch problem

    Brilliant move...:-(

    What was wrong with sticking extra hour/minutes digits in the serial number - no y2k style problems at all....?!?

    ie YYYYMMDDHHmmNN ??

  8. Re:dynamic dns by RollingThunder · · Score: 2, Insightful

    Not quite - this would theoretically allow you to now also host your DNS zone on a system with a dynamic IP, as you can now get a change to the root-level NS records in short order.

    I sure wouldn't want to try that, though....