Follow Slashdot stories on Twitter

 


Forgot your password?
Close
typodupeerror
×
The Internet

Verisign Speeds Up DNS Updates 131

Posted by michael 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."
This discussion has been archived. No new comments can be posted.

Verisign Speeds Up DNS Updates More

Verisign Speeds Up DNS Updates

Comments Filter:
  • Its not like it kills anyone to wait a few hours for their dns changes to propagate?

  • Thanks, Verisign... (Score:5, Funny)

    by SamMichaels ( 213605 ) on Sunday July 11, 2004 @04:31PM (#9669187)
    ...but kissing our asses won't make up for the fact you still want to deprecate NXDOMAIN for SiteFinder.

    • I second that.
    • I'll concur with that. It's a great move (and a birthday present for me) but sitefinder is a sin not worth forgiving.
    • I hate Verisign as much as the average /.er for their SiteFinder shannanigans, however we must recognize when they do the right thing.
      Anyone who ever need to migrate a major website to a new IP will benefit from this change.
    • I dunno... I'm pretty darn happy with this news. My ISP ends up changing my IP address every so often (as often as one a week, but on average once every two months, and occasionally as long as 6 months). I have having to wait for the DNS update for people to be able to get to my websites, for me to be able to stream my radio station, etc. Call me a sellout, but I'll forgive just about anything for fast DNS updates.

      • Re:Thanks, Verisign... (Score:4, Insightful)

        by Neon Spiral Injector ( 21234 ) on Sunday July 11, 2004 @05:46PM (#9669737)
        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.

  • it's not clear to me... (Score:5, Insightful)

    by rritterson ( 588983 ) * on Sunday July 11, 2004 @04:32PM (#9669204)
    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)

    • Re:it's not clear to me... (Score:5, Informative)

      by LostCluster ( 625375 ) * on Sunday July 11, 2004 @04:36PM (#9669249)
      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.

    • Re:it's not clear to me... (Score:5, Informative)

      by AKnightCowboy ( 608632 ) on Sunday July 11, 2004 @05:08PM (#9669471)
      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.

  • "A little-known DNS behavior called credibility" (Score:5, Informative)

    by jea6 ( 117959 ) on Sunday July 11, 2004 @04:32PM (#9669210)
    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.

  • Domain Name Portablity... (Score:5, Insightful)

    by LostCluster ( 625375 ) * on Sunday July 11, 2004 @04:33PM (#9669213)
    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.
    • Yes, except those people relying on old cached info will be... everybody, since the TTL is still 48 hours.

      As I read it, this changes nothing, because updates will still take days to get to users.
    • What this also means is more rapid moves for spammers.

      As new domains can be brought on line instantly, they can switch source names in both the mail headers and embedded URLs and thereby more nimbly evade DNS based spam detection methods such as the newer methods (such as SURBL: http://www.surbl.org )in the upcoming Spamassassin 3.0.

      There are others who are interested in quickly moving web sites from place to place, and most of them are up to no good, Such as warez, pirate, and terrorist sites etc.

      Legit

    • Re:Domain Name Portablity... (Score:1, Insightful)

      by Anonymous Coward
      can you explain exactly why we are going from a days to minutes improvement when switching ISPs?

      Dns. I don't think that word means what you think it means.

      hint: look at the real reason why it sometimes takes days when you make a change, and you'll realize that it has nothing to do with verisign or root servers.

  • As a consumer (Score:2, Insightful)

    by WebMasterP ( 642061 )
    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.

  • Censorship? (Score:5, Interesting)

    by phr2 ( 545169 ) on Sunday July 11, 2004 @04:36PM (#9669245)
    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.

    • Censors would probably be more likely to go for your hosting provider anyway, wouldn't they?

      • Re:Censorship? (Score:3, Informative)

        by hunterx11 ( 778171 )
        Usually, but not always--case in point goatse.cx [goatse.cx].

        Now watch as I get modded down for goatse :)

      • WHOIS (Score:1, Interesting)

        by Anonymous Coward
        Unpopular websites often get attacked via fradulent WHOIS claims. Basically, ICANN in their stupid and aribitrary opinion says that you must have valid information in your whois.

        All it takes is one or two people to file a claim with ICANN or your registrar that your whois info is wrong and many registrars such as GoDaddy and Dotster will pull the domain away no questions asked and then point to ICANN rules as a scapegoat.

        I've heard of times where people got their domain yanked because the phone line was b

    • Re:Censorship? (Score:4, Interesting)

      by LostCluster ( 625375 ) * on Sunday July 11, 2004 @04:52PM (#9669381)
      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.
      • it came at the end of a long legal process, and an extra day or so won't make any real difference.

        I'm more concerned about a situation where your site gets shut down by surprise. You might have it hosted in some a country where ISP's aren't so quick to censor as they are in the US (you might even be a citizen of that country publishing stuff that's legal there), but the DNS system creates another point of attack.

    • If you're running a site that might get killed, wouldn't it be a good idea to mirror it ahead of time?
    • "The bad part: if someone gets Verisign to shut off your DNS, your site goes dark before anyone knows what happened."

      Uh, wouldn't you not notice until the site is dark, whether it takes 24 hours or 2 minutes? It's not like websites perform a slow fadeout.
    • The good part: when you register a new domain, you can publish it immediately and people can start using it right away.

      More importantly, if someone makes a mistake in the configuration it takes far less time to debug if you only have 5 minutes to wait for the info to propagate.

      The fact the info might have been cached is not relevant when you are testing a config, you just flush your cache out.

    • It's just DNS isn't it? Use the IP address directly should be enough I think.

      Given it's web data (from the word "site"), browsers usually cache the ipaddress anyway.
  • 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?
    • Oh, sure... there's a lot of things that could be done to the domain name system to be faster and more secure and all we'd have to trade away is legacy compatiblity. :)
    • That doesn't sound practical, what are you going to do, keep a list on all the root servers of all the servers that pulled your record and get them to honor an update?

      Use $TTLs so it expires faster around the time you are making changes.

      And if you want to point fingers at DNS for being hard to keep in sync, take a look at LNP :/

  • Spammer's Delight... (Score:5, Interesting)

    by LostCluster ( 625375 ) * on Sunday July 11, 2004 @04:39PM (#9669274)
    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.
  • 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.

    • Yep, your org took less than 5 mins (Score:5, Informative)

      by Jayfar ( 630313 ) on Sunday July 11, 2004 @04:51PM (#9669370)
      Public Interest Registry has been doing this since last September. Less than 5 minutes, according to their announcement [pir.org].
    • It doesn't even speed up that in practical terms. It still takes 24-48 hours for a domain change to propogate once the root nameservers are updated (especially since some larger ISPs seem to ignore TTL and just update a few times a day).

      I'm still getting hits on my old website 2 months after changing the DNS... there are some ISPs that are just plain broken - luckily the monotiry.
      • That's because BIND's caching mechanism is, and has for some time now been, painfully broken. BIND will cache records until way, way after their TTL is up, even though it's really not supposed to. I know some people will say "no, it's not, you're full of shit!", but I've experienced it firsthand, so I can tell you for sure - it's broken. Therefore I continue to suggest using other DNS server software - there are a lot of alternatives, so take advantage of them.
  • Rapid DNS when running enterprise zone with dynamic updates or when running dynamic-dns service for those who use dynamic IP's makes more sense then for .com and .net. Registration time is 1-2 year, 5 minutes vs 1/2 day doesnt seems to make any difference :-/

    Someone please explain.

    • Re:Err.. (Score:2, Insightful)

      by BlueCup ( 753410 )
      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
      • That's not exactly how it works. In fact, this has absolutely no baring unless you are changing DNS servers, or changing DNS names. These are the only changes they are now synching every five minutes. Any additional DNS servers you add can point at your new co-loc's IP addresses, and gently migrate over to the new location, same as always before.

        • In fact, this has absolutely no baring unless you are changing DNS servers

          Which often happens when changing web hosting providers.

  • Yet another Y2038 problem (Score:1, Funny)

    by Anonymous Coward
    Yet another Y2038 problem waiting to happen. The serial number in the SOA record is a 32-bit number; by making this the UNIX timestamp, they'll run out of numbers in January 2038.

    They should have made it what I made it when I had to program an automatically generated serial number: (Unix timestamp - some other number (414500033 to be exact)) / 60

    This timestamp won't expire...for a while. :)
    • That's what I was thinking, and it makes it hard to tell at a glance when the last update was. Though I guess with a domain like com., you knew it was today anyway, so epoch time is a bit better than some number between 1 and 99.

      For anyone that's interested, you can see the last update like this:

      $ dig @A.GTLD-SERVERS.NET com soa
      ~ ;; ANSWER SECTION:
      com. 172800 IN SOA a.gtld-servers.net. nstld.verisign-grs.com. 1089520605 1800 900 604800 900

      so the last update was at 1089520605

  • Only affects root's maps (Score:5, Informative)

    by rufey ( 683902 ) on Sunday July 11, 2004 @05:52PM (#9669787)
    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.

  • Pardon my ignorance but why are not all DNS updates instantaneous?
    • As far as I understood: To save bandwidth, a zone file can be dozens of megabytes and passing them down to their subnodes is alot of traffic.
    • Pretty decent reference
      -- 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?i d=6
    • They are - but not to all the caching name servers that have local cached information. DNS records have a time to live that tells other nameservers how long to hold on before requerying.
      Verisign clearly didnt update their name servers more than twice a day - they didnt load new changes as and when - just did a bulk load instead.
      Bind allows updates without downing the name server using nsupdate - perhaps they've figured out how to use it.

  • What happens in 2038?! (Score:3, Insightful)

    by Mercury2k ( 133466 ) on Sunday July 11, 2004 @07:14PM (#9670333)
    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 ;)
    • Yes but the number is stored as ascii, so there is no reason to belive it is limited to 32bit integers.
      • In that case, then it should be the responsibility of the DNS daemon to use numbers larger than 32-bit as comparisons?

        I was under the impression that the standard for serial numbering was YYYYMMDDrr where rr is the current "revision" number. I see that used in Bind systems, though I see MS-DNS using incremental numbers from 1.

        So, extend the serial numbering scheme to allow YYYYMMDDxx, where xx is an actual recognizable number, perhaps 32-bit singed or unsigned. Then that would allow that many revisions
      • It may be stored in ascii, but that still doesnt mean that the number isnt stored internally as a 32bit unsigned integer and processed accordingly to do a comparison check against the old value.

      • Yes but the number is stored as ascii, so there is no reason to belive it is limited to 32bit integers.

        No, it's not, from rfc1035.txt...

        3.3.13. SOA RDATA format

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

    • 1089692844 is a valid 64-bit number.

      Yes, today's RFC limits it to 31 bits. Yes, bind stores it as 32 bits.

      So by 2038 we need a new RFC and a new bind. But if you don't update your config files for the next 24 years you'll be OK.

      Assuming DNS is still around in 24 years.
  • Cool, now I can run my homelinux box with a dynamic-dns service on a TLD instead of the flaky yourname.dyndns.org Will this mean alot more people resort to home brew web servers?

    • Re:Cool, .com dyn-dns (Score:2, Informative)

      by Anonymous Coward
      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.

  • Verisign doesn't do ANYTHING benevolently (Score:3, Interesting)

    by mabu ( 178417 ) * on Sunday July 11, 2004 @10:00PM (#9671251)
    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?

    • VeriSign doesn't own a registrar so your conspiracy theory makes no sense.
      • Isn't Network Solutions a Verisign company?

      • um (Score:2)

        by mabu ( 178417 ) *
        VeriSign Re-Launches Network Solutions Brand

        Customers to Gain from Enhanced Web Services and Increased Benefits

        HERNDON, VA - January 6, 2003 - VeriSign, Inc. (Nasdaq:VRSN), the leading provider of digital trust services, announced today that it has re-launched the Network Solutions brand under its wholly owned subsidiary Network Solutions, Inc. to conduct its domain name, Web site and e-mail service business. Network Solutions will provide a full range of professional, customized Web services for business

        • Re:um (Score:2)

          by kimba ( 12893 )
          VeriSign Completes Sale of Network Solutions Unit to Pivotal Private Equity

          MOUNTAIN VIEW, CA. November 25, 2003 - VeriSign Inc., a leading provider of critical infrastructure services for Internet and telecommunications networks, today announced the completion of the sale of its Network Solutions domain name registrar business to Pivotal Private Equity. The customer-facing registrar business is the world's leading provider of domain name registration services, and an industry leader in value added services
    • 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.

      Hmmm. Seems like having things reroute better around DDOS attacks *is* in their own self interest.

      Also, other have mentioned that competitors already have this. So it's in Verisign's self interest to have it as well, so they don't lose customers (maybe even gain

  • This only makes sense. This shouldn't be the end though, why does DNS take so long to propogate? Can't we fix this?

Slashdot Top Deals

Talent does what it can. Genius does what it must. You do what you get paid to do.

Close