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.

49 of 150 comments (clear)

  1. dynamic dns by Anonymous Coward · · Score: 5, Interesting

    So when will they be added support for dynamic IP addresses a la dyndns etc. That would be great.

    1. Re:dynamic dns by numbski · · Score: 5, Informative

      It's already there.

      The catch of course is that you have to be running bind locally to make it work. Which is fine if you're a unix-head and know how to work dns, but for the average joe, it's far from simple. I have a perl script that checks my Linksys firewall's IP every half hour, and if it's changed, updates the dns file, then runs nsupdate.

      --

      Karma: Chameleon (mostly due to the fact that you come and go).

    2. Re:dynamic dns by two-tail · · Score: 5, Informative

      Services provided by the likes of DynDNS are not affected by this. The changes mentioned in this article affect top-level servers, which maintain lists of registered domains and their name servers. Providing an actual IP address is provided in the next level down. For example, here is the complete path that you would go through to get an IP address for www.slashdot.org:

      1: a.root-servers.net (refers request to tld2.ultradns.net)
      2: tld2.ultradns.net (refers request to ns1.osdn.com)
      3: ns1.osdn.com (returns 66.35.250.150)

      Adding and deleting domains causes changes at #1 and #2. Changing the name servers assigned to a domain also happens at #1 and #2. Changes to an IP address (like the IP address for www.slashdot.org), which is what DynDNS and the like covers, would take place at #3.

      One last note: If you have a domain already in place, and you want to change its nameservers over to DynDNS (possibly to take advantage of their dynamic update service), then #1 and #2 would get involved (since you're changing a nameserver). Under the system being phased out, that would have given you a day-long delay.

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

    4. Re:dynamic dns by BenFranske · · Score: 2, Interesting

      That solution is not really as nice as DynDNS. I for one would really like to see a piece of OSS that lets you operate using the (documented) DynDNS protocol so that the standard update scripts widely availible for that would work. Running a nameserver on a system that doesn't require one seems counterproductive. Plus, you could use existing software to keep Windows boxes up to date as well. The DynDNS update protocol is availible here

    5. Re:dynamic dns by JJahn · · Score: 2, Funny

      Might I recommend using IPCop on an old PC as a firewall/NAT device for your home network? It contains the ability to automatically update your IP address to dyndns and several other dynamic services. Its also a nice firewall product, which is free (as in beer and speech).

    6. Re:dynamic dns by robertjw · · Score: 4, Funny

      Which is fine if you're a unix-head and know how to work dns

      I don't think anyone actually knows how to work dns. It's one of those magic things that you hack for a couple hundred hours and it finally does what you want it to - like qmail.

      --
      Find coupons in Greeley
    7. Re:dynamic dns by tigress · · Score: 2, Informative

      Actually, adding, deleting and changing domains causes changes at #2 and #3. The root-servers are never affected unless there is a change in the TLD delegations. Changing a Second level domain requires changes in the TLD nameservers (#2) and the nameservers responsible for the SLD (#3). Changes within the domain only affects #3. Unless, of course, the change is on an authorative nameserver, in which case #2 is also affected. This article describes how the changes in #2 will take effect faster.

  2. For all registrars, or just some? by two-tail · · Score: 3, Interesting

    I remember hearing about this, but I don't remember exactly: Is this available to all registrars, or is there something that needed to be done on their end to get their updates in quickly?

    1. Re:For all registrars, or just some? by numbski · · Score: 2, Informative

      Looks to me like it requires a conformity to the new serial number spec (which, if I might say BLOWS...I run an ISP and I appreciate being able to look at a DB file and know when the last time I changed it was by simply looking at the serial...ugh), otherwise it will just sort of 'happen'. So long as your dns server is authoritative for a domain and your root-hints file is correct.

      Anyone have further input?

      --

      Karma: Chameleon (mostly due to the fact that you come and go).

    2. Re:For all registrars, or just some? by WhiteDeath · · Score: 3, Interesting


      AFAIK the serial number has only ever been in the format of YYYYMMDDNN as a reccomendation. There is nothing in the spec preventing you from numbering versions from 1.

      Changing to a UTC timestamp in seconds is no big issue, but for conformity, it's nice if everyone does the same thing, or at least knows what everyone else is doing, especially if you have some software trying to make sense of it all.

  3. 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 Mordac+the+Preventer · · Score: 5, Informative
      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.
      No, it's the TTL that determines how long a record can be cached for. Updating the zone more frequently just means that the information will be available sooner. It will not increase the load on the root nameservers.
      --
      SteveB.
    5. Re:hmm, but is this really a good thing? by LiquidCoooled · · Score: 5, Informative

      If I remember rightly, the new system does not change the TTL, it is still down to the domain administrator to pre plan domain moves.

      On the day before you move, your TTL can be dropped to this 5 minutes so your address can be changes with minimal disruption. After the move, once your stable, your TTL can be increased once again, and network congestion is minimalised.

      Of course, I could be talking out of my arse, one of you lot will put me right if this is the case.

      --
      liqbase :: faster than paper
    6. Re:hmm, but is this really a good thing? by Entrope · · Score: 5, Informative

      Your claim of "144x as much traffic" exhibits an ignorance of how DNS caching works -- not that I should be surprised by the ignorance of anything I read on Slashdot. Specifically, caching is controllable independently of zone revision. It is easy to instruct clients to cache negative replies for a longer time than that revision of the zone is current. The only way to increase the frequency of lame requests is to reduce the TTL or SOA MINIMUM values.

      On top of that, maximum-frequency error responses are only a problem when you have enough headstrong or automated users to see requests for the SAME misspelled domain name just past the SOA MINIMUM (or TTL, if appropriate) time. It is not a problem for valid name requests, since they have separate TTLs. While that frequency of lame requests is indeed a valid assumption with infinite load, in practice, only the largest ISPs will see anything that approximates that traffic.

      Your comment that domains are not supposed to change every minute is correct for some domains; but the particular domains in question (TLDs) do change every minute as new domains are registered or expire. (Other things, like DHCP-driven dynamic DNS, can also legitimately cause frequent zone updates.)

    7. Re:hmm, but is this really a good thing? by sw155kn1f3 · · Score: 2, Informative

      It's simple:

      # dig a alksasdasdqweqwehqwe.com

      com. 10793 IN SOA a.gtld-servers.net.
      nstld.verisign-grs.com.
      1094 735719 --- serial
      1800 --- refresh
      900 --- retry
      604800 --- expiry
      900 --- minimum aka "default" for this domain.. it's the time for NXDOMAIN responses too

      --
      - Arwen, I'm your father, Agent Smith.
      - Well, you're just Smith, but my father is Aerosmith!
    8. Re:hmm, but is this really a good thing? by SirCyn · · Score: 5, Informative

      Let me clarify a few misconceptions.

      1. The "minimum time" set to 15 minutes means the servers will not check for an update on a record until it is at least 15 minutes old.

      2. The 5 minute transfers. This is how often the root servers check with each other. This has nothing to do with any other server. Not the registars, not your ISP's DNS server; only the root servers.

      3a. The serial change from yyyymmddnn to Unix epoch time makes perfect senese. And no, it does not suffer the 32-bit problem. Serial numbers can be much more than 32 bits. Heck the yyyymmddnn takes 8 bits per character now, so 80 bits just for that. Dare I guess how far into the future an 80-bit Unix time would go (if it was stored that way)?

      3b. If this serial change screws up your DNS Cache server simply flush the cache, problem solved. If you have some application (as suggested in the memo) that relies on the serial you need to update your software, now.

      4. Whoever suggested this as a backup plan for having only one server run your whole opperation: You are dumb. Now go away or I shall taunt you a second time.

      5. The TTL for a standard DNS entry is not going to change. So if your ISP's DNS server caches an entry it will (probably) keep it the same amount of time as it did before. (I say probably because most DNS severs can update records before their TTL expires).

      Would the people who do not know how DNS works please stop posting your misinformation and speculations. Thanky you!

      --
      FreeBSD: The Power to Serve!
    9. 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!

    10. Re:hmm, but is this really a good thing? by Kishar · · Score: 5, Informative
      3a. The serial change from yyyymmddnn to Unix epoch time makes perfect senese. And no, it does not suffer the 32-bit problem. Serial numbers can be much more than 32 bits. Heck the yyyymmddnn takes 8 bits per character now, so 80 bits just for that. Dare I guess how far into the future an 80-bit Unix time would go (if it was stored that way)?


      You're correct on all counts except this one.

      From RFC1035:

      SERIAL The unsigned 32 bit version number of the original copy of the zone. Zone transfers preserve this value. This value wraps and should be compared using sequence space arithmetic.


      The YYYYMMDDxx way can't be used past 2148, the UTC way can't be used past 2038. (neither way breaks it, because the serial number wraps to 0)
    11. Re:hmm, but is this really a good thing? by Feyr · · Score: 2, Informative

      you're correct. this is .com and .net

      as a side note. for everyone that doesn't pay attention to dns and have been spouting random crap (eg, not you). .org has been doing the exact same time since ultradns bought the rights to host it. in short, no it won't cause much problems

      also, verisign pointed out the TTL will stay to 24 (or 48?) hours, so this really only affects NEW domains, unless you set your zone ttl to much lower in the first place (your zone has a higher trust than verisign's, so the ttl from that zone gets cached instead of theirs)

  4. Fantastic. by John_Allen_Mohammed · · Score: 4, Funny

    This will probably help speed things up on the ogg-streams-over-dns p2p radio stations. Some complain that DNS wasn't designed for these purposes but generally, the same people complaining are the ones raising kids now, using viagra and getting ready to wear diapers again.

    Technology adapts to changing circumstances and trends, old folks do not.

    --

    Skype Me! username: john_allen_mohammed
  5. In other news by Anonymous Coward · · Score: 4, Funny

    Slashdot has announced they will begin posting stories every twenty seconds, instead of every hour.

    Says CowBoy Neil, "Well, we figured at the increased rate, we could dupe stories at twice the usual rate. And also... uh... we could use my name in twice as many polls."

    Reached for comment in his mother`s basement, Commander Taco said only, "DNS, smenesh, I think we all want to see GNNA update their trolls!"

  6. Root Servers... by jmcmunn · · Score: 5, Interesting


    So I don't exactly get it, but is this just the root servers that are going to be updating every five minutes? I read the links, but it still doesn't seem clear to me. I mean, if my registrar (or dns service or whatever) still only send in their updates once every day, this won't really help me as much right?

    Of course, once they do send it in I will still get it updated an average of 6 hours faster I guess. Just curious, since the details were a little vague to us non-dns folks.

    1. Re:Root Servers... by jabley · · Score: 5, Informative

      This has nothing to do with the root servers. The slashdot article is inaccurate.

      Verisign are publishing delegations in the DNS from their registry for the COM and NET domains much more frequently than they were before. The TTL on records in the COM and NET zones is not changed.

      The affected nameservers are a.gtld-servers.net through m.gtld-servers.net. These are not root servers. They are authority servers for the COM and NET zones.

      Verisign also runs two root servers (a.root-servers.net and j.root-servers.net). There has been no announced change in the way A and J are being run.

  7. Speed up attacks? by two-tail · · Score: 3, Interesting

    Would this make it easier to slip false transfers through whatever nets may exist to catch them (as in this news byte)? I guess false transfers such as this would be noticed by the public at large sooner, so that's not too bad.

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

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

  9. Re:Emergency use by Anonymous Coward · · Score: 2, Informative

    you can already do this, the root servers basically just know the address of a nameserver designated to a domain.

    this just helps if you want to switch nameservers within 5 mins

    on top of that if you have a standby box bring it online with the old ip

  10. Re:Emergency use by autocracy · · Score: 4, Informative

    Wrong way about it. Your DNS records in the [.com .net .org .whatever] domain only point to your NS records. You should have multiple name servers up anyway (peering agreements for DNS are usually pretty easy to get). It is your A records that point to the web server, and the update for that takes place upon your own servers.

    --
    SIG: HUP
  11. Re:Emergency use by Eggplant62 · · Score: 2, Informative

    I think you mean that this would be more handy for sites who lose a DNS server. Note that if the machine in an NS record for a domain goes dead, the domain can be left unresolvable until the root servers update. Now with every five second updates on the root servers, change the NS records and yer back up and running.

    Happened to me with my vanity domain when afraid.org was cut off for about 8 hours due to abuse issues. His upstream provider cut him off due to spammers hosting DNS there and he had to take steps to get back online. Meanwhile, my domain was unresolvable. I ended up putting up secondaries to prevent this from happening again.

  12. Re:Emergency use by LostCluster · · Score: 5, Informative

    What's the point in that?

    The record in a DNS root server never is meant to identify your web server, it's meant to indentify your primary and secondary DNS server, and it's those servers that work for you (or at least the ISP you work with) to identify your web server.

    So, if you want fallover if your main web server goes down, you just need to update your local DNS record, not the one at the root servers. It's when your DNS servers explode that the five-minute updates would be helpful.

  13. In case of slashdot effect... by bruceg · · Score: 5, Informative

    Upcoming change to SOA values in .com and .net zones

    * From: Matt Larson
    * Date: Wed Jan 07 17:49:43 2004

    VeriSign Naming and Directory Services will change the serial number
    format and "minimum" value in the .com and .net zones' SOA records on
    or shortly after 9 February 2004.

    The current serial number format is YYYYMMDDNN. (The zones are
    generated twice per day, so NN is usually either 00 or 01.) The new
    format will be the UTC time at the moment of zone generation encoded
    as the number of seconds since the UNIX epoch. (00:00:00 GMT, 1
    January 1970.) For example, a zone published on 9 February 2004 might
    have serial number "1076370400". The .com and .net zones will still
    be generated twice per day, but this serial number format change is in
    preparation for potentially more frequent updates to these zones.

    This Perl invocation converts a new-format serial number into a
    meaningful date:

    $ perl -e 'print scalar localtime 1076370400'

    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.

    There should be no end-user impact resulting from these changes
    (though it's conceivable that some people have processes that rely on
    the semantics of the .com/.net serial number.) But because these
    zones are widely used and closely watched, we want to let the Internet
    community know about the changes in advance.

    Matt
    --
    Matt Larson
    VeriSign Naming and Directory Servic

  14. 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 frozen_crow · · Score: 3, Informative

      no, it does not. it just means that if a resolver receives a "no such name" response from one of the com or net nameservers, that "no such name" response will only be cached for 15 minutes instead of a day.

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

    3. Re:Fifteen minutes? by bfree · · Score: 2, Informative

      Ooops, it's not quite as described above! The root servers aren't being updated any quicker, it's just the .com and .net servers. It doesn't impact on the above though as the root servers just hand out the ip addresses of the authoritative servers for the top level domains, so for a non existant domain name the root servers will behave just the same as an existing domain name in the same tld.

      --

      Never underestimate the dark side of the Source

  15. International Date Format by Compact+Dick · · Score: 5, Interesting

    It's about time the switch was made -- here's why ISO 6601 is the way to go.

    --
    Use ISO 8601 dates [YYYY-MM-DD]
  16. Re:increase of (mostly useless) traffic exptected? by Tenareth · · Score: 3, Informative

    Just because they are refreshing the roots every 5 minutes doesn't mean they dropped the TTL to 5 minutes. Since most DNS servers do not cache bad domains, this just means that new domains become available faster, and propogate within 10 minutes or so.

    --
    This sig is the express property of someone.
  17. Re:Emergency use by ostiguy · · Score: 4, Informative

    This isn't that. You are talking about regular DNS A record changes on your dns server. You could have done what you sought a year ago, or 10. This is about what DNS servers are responsible for your domain, among other domain level changes (responsibility, etc) - if Chicago burns to the ground, Schlotsky's House of Bacon, having lost their headquarters with its server room, could then outsource its DNS, enter records, and make a root change to indicate that schlotskyshouseofbacon.com's dns servers have changed within 5 minutes (ideally).

    ostiguy

  18. 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.
  19. Re:Why? by mr_z_beeblebrox · · Score: 3, Informative

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

    This will affect DNS customers not consumers. DNS is a purchased service (not a product) Businesses are its customers, users are its' consumers. Verisign wants to make a positive impact on its' customers to turn more revenue.

  20. Root servers? by bartjan · · Score: 4, Informative

    These faster updates are not for the root servers, but for the .com/.net gTLD servers.

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

    1. Re:2038 fun by gclef · · Score: 2, Interesting

      They just said they were encoding the serial number as the seconds since epoch. They never said anywhere how many *bits* they're using to measure that. In fact, since the serial number is a free-form text field, there's not really any way to overflow that. The epoch overflow shouldn't affect this.

    2. Re:2038 fun by amorsen · · Score: 4, Informative

      I have no idea where people got the idea that the serial number is a text field. It is a simple 32 bit integer. However, it is supposed to be compared using "sequence space arithmetic". This has been defined in RFC 1982. Basically it means that overflows are fine, as long as no secondary nameserver keeps really old revisions around. So if you make a secondary for the .com zone now, unplug it for 40 years, and plug it in again, it may fail to get the latest zone.

      --
      Finally! A year of moderation! Ready for 2019?
  22. Hell Yeah! by CptTripps · · Score: 3, Interesting

    This is something that should have been taken care of YEARS ago. It'll make it a LOT easier to switch people over to new servers/change IP addresses and such.

    Can't wait to go......switch some IP addresses.... ::: not neerly as exciting when you type it out like that :::

    --


    My .sig can beat up your honor student.
  23. Things that are Certain by Mixel · · Score: 2, Funny

    Death, Taxes and DNS Propagation Delay.