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

131 comments

  1. I wonder what brought this on? by rkz · · Score: 2, Insightful

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

    --
    There is no god
  2. 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 Tokerat · · Score: 2, Funny


      I second that.

      --
      CAn'T CompreHend SARcaSm?
    2. Re:Thanks, Verisign... by Neophytus · · Score: 1

      I'll concur with that. It's a great move (and a birthday present for me) but sitefinder is a sin not worth forgiving.

    3. Re:Thanks, Verisign... by bugmenot · · Score: 1

      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.

      --
      This account has been seized by the GNAA. That is all.
    4. Re:Thanks, Verisign... by Rei · · Score: 1

      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.

      --
      "If there was an antonym to 'Elon Musk', it would be 'Richard Branson'."
    5. 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.

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

    7. Re:Thanks, Verisign... by Ryosen · · Score: 1

      > good, cheap, and even free alternatives to hosting your own DNS

      And just in case you are looking for a good, cheap, and even free alternative, check out ZoneEdit. Highly recommended.

      --

      Ryosen
      One man's "Troll, +1" is another man's "Insightful, +1".
  3. 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.

  4. "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.
  5. 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 Guspaz · · Score: 0

      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.

    2. Re:Domain Name Portablity... by Anonymous Coward · · Score: 0

      But... Verisign is bad, right??!

      / Confused /. Reader

    3. Re:Domain Name Portablity... by LostCluster · · Score: 2, Insightful

      Just because a TTL is marked 48 hours doesn't mean all ISP DNS servers keep the cached information for 48 hours. Besides, those plainning a change could now lower their TTLs and actually have it mean something...

    4. Re:Domain Name Portablity... by icebike · · Score: 1, Redundant

      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 moves of a company's website are rare, and usually accomplished with prior planning, leaving the old site it place till the new site is established, and the transition is smooth and no mail is lost.

      Sometimes a little inerta is a good thing.

      --
      Sig Battery depleted. Reverting to safe mode.
    5. Re:Domain Name Portablity... by Anonymous Coward · · Score: 0

      Why only spammers?

      I know very little about DNS, but it seems that small businesses and individuals whose sites are getting hammered could move quickly as well to handle unexpected increases in loads, unresponsive ISPs, certain stupid denial of service attacks, etc.

      As to illegal content moving, such as the warez, pirate, and terrorist sites, the same could be said of political action sites. (And I'd probably want terrorist sites to move, since the more they move, the more chance that they'll make a mistake and be traceable.) Everything cuts both ways; don't be so quick to chalk this up as catering to illegit activities.

    6. Re:Domain Name Portablity... by Anonymous Coward · · Score: 1, Insightful

      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.

    7. Re:Domain Name Portablity... by Guspaz · · Score: 0

      That's true. Makes me wish that one could modify the TTL for domains hosted at GoDaddy. Their "total control" interface doesn't seem to list it, last I checked. If you want your GoDaddy domain to have a custom TTL, you have to host it yourself :(

    8. 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.
    9. Re:Domain Name Portablity... by Lord+Bitman · · Score: 0, Troll

      somebody mod that up. It'll be fun :)

      --
      -- 'The' Lord and Master Bitman On High, Master Of All
  6. As a consumer by WebMasterP · · Score: 2, Insightful

    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.

  7. 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 sploo22 · · Score: 1

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

      --
      Karma: Segmentation fault (tried to dereference a null post)
    2. 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.

    3. Re:Censorship? by toasted_calamari · · Score: 1

      If you're running a site that might get killed, wouldn't it be a good idea to mirror it ahead of time?

      --
      Let's make a difference
    4. Re:Censorship? by NanoGator · · Score: 1

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

      --
      "Derp de derp."
    5. Re:Censorship? by hunterx11 · · Score: 2, Informative
      Usually, but not always--case in point goatse.cx.

      Now watch as I get modded down for goatse :)

      --
      English is easier said than done.
    6. Re:Censorship? by Zeinfeld · · Score: 1
      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.

      --
      Looking for an Information Security student project suggestion?
      Try http://dotcrimeManifesto.com/
    7. Re:Censorship? by Anonymous Coward · · Score: 0

      They do when it's a discussion forum (Slashdot/Fark/etc) and some people say they get DNS errors and some still get the page because their DNS hasn't updated yet

    8. Re:Censorship? by Anonymous Coward · · Score: 0

      Right, except the only difference is that no one would care if Fark faded out.

    9. Re:Censorship? by johnnliu · · Score: 1

      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.

  8. WTF by Turn-X+Alphonse · · Score: 0, Flamebait

    every 5 minutes? and what if nothing happens in said 5 minutes? Why not just when something needs to be updated instead?

    --
    I like muppets.
    1. Re:WTF by Anonymous Coward · · Score: 0

      You are a genius.

    2. Re:WTF by hypermike · · Score: 1

      Because.... Every Five minutes is A LOT less CPU then Constantly Scanning for changes.

      --
    3. Re:WTF by NanoGator · · Score: 1

      "every 5 minutes? and what if nothing happens in said 5 minutes?"

      Then it goes nowhere, but does it really fast!

      --
      "Derp de derp."
    4. Re:WTF by Anonymous Coward · · Score: 0

      RTFA, DA. They're pretty much doing just that.

    5. Re:WTF by Anonymous Coward · · Score: 0

      ehrm, can't a "dirty bit" on the zones be set as the change is requested? E.g. user submits a change, this marks the zone as "dirty" and in need of an update when the time of the next periodic update slot comes around.

    6. Re:WTF by Anonymous Coward · · Score: 0

      I'm pretty sure they recieve hundreds if not thousands of changes in a five minute span. Updating every time something changed would be ALOT more stressful than every five minutes.

    7. Re:WTF by Anonymous Coward · · Score: 0

      goddamn, I know. WTF!

  9. On-Demand Update? by powerpuffgirls · · Score: 2, Insightful

    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?

    1. Re:On-Demand Update? by LostCluster · · Score: 1

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

    2. Re:On-Demand Update? by prog-guru · · Score: 1

      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 :/

      --

      chris@xanadu:~$ whatis /.
      /.: nothing appropriate.

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

    2. Re:Spammer's Delight... by Anonymous Coward · · Score: 0

      You can do this anyway. Host the DNS for your domains somewhere reliable and just set the TTL for your domain to something like 5 minutes. If your site gets shut down, you can change the IP and the changes will propagate very quickly.

    3. Re:Spammer's Delight... by DavidTC · · Score: 1

      ...which is why spamfighters go after whoever's hosting the domain name, too.

      --
      If corporations are people, aren't stockholders guilty of slavery?
  11. 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.

    1. Re:Glad to see Verisign coming up to the times by Tony+Hoyle · · Score: 1

      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.

    2. Re:Glad to see Verisign coming up to the times by demon · · Score: 0

      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.

      --

      Sam: "That was needlessly cryptic."
      Max: "I'd be peeing my pants if I wore any!"
    3. Re:Glad to see Verisign coming up to the times by Anonymous Coward · · Score: 0

      . 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

      Um, have you ever thought that the fact that everyone else is telling you you are full of shit could be an indication that you are doing something wrong? I've been running BIND at our mid-sized regional ISP and this has NEVER been a problem.

      So yes I will say it. You are full of shit.

    4. Re:Glad to see Verisign coming up to the times by Anonymous Coward · · Score: 0

      No, it's not, you're full of shit!

    5. Re:Glad to see Verisign coming up to the times by demon · · Score: 1

      I work for a service provider. As I've said, I've seen BIND cache records for days, even weeks - way after DNS has changed for a domain, even after changing the master servers at the root. Any non-broken DNS server would have _expired_ the records, as it's supposed to do. I've since replaced BIND with PowerDNS on my employer's primary DNS servers (not just for this reason - also because it affords some very nice functionaily as far as allowing customers to host their DNS with us, and still manage it on their own schedule). We still run it at the office because it supports dynamic DNS, but I've considered adding dynamic DNS functionality to PowerDNS just to have the ability to get rid of BIND once and for all. It's a mess, and it needs to be replaced.

      As I said, I would not say this if it weren't for the fact that I had _first hand_ encounters with BIND's brokenness. Hence why I expected someone to say I'm full of crap. But in this case, I know I'm right about this.

      --

      Sam: "That was needlessly cryptic."
      Max: "I'd be peeing my pants if I wore any!"
    6. Re:Glad to see Verisign coming up to the times by Anonymous Coward · · Score: 0

      As I just found out though with my first home webserver, not all .org's are quick to propogate as I am going on day 3 now without dns resolution. They tell me to be patient though.

  12. Re:Die script kiddie by Anonymous Coward · · Score: 0

    IP addresses are still not portable and customers may not like microsoft.com resolving to 127.0.0.1 so my brick reads "NO!"

  13. Err.. by slimyrubber · · Score: 1

    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.

    --
    [ I can not bring myself to believe that if knowledge presents danger, the solution is ignorance ] -- Isaac Asimov
    1. Re:Err.. by BlueCup · · Score: 2, Insightful

      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!
    2. Re:Err.. by Alan+Hicks · · Score: 1

      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.

      --
      Slackware, what else when it must be secure, stable, and easy?
    3. Re:Err.. by tepples · · Score: 1

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

      Which often happens when changing web hosting providers.

  14. Actually, IP Addresses COULD be portable... by Anonymous Coward · · Score: 0

    IP Address are now portable

    1. Re:Actually, IP Addresses COULD be portable... by Anonymous Coward · · Score: 1, Insightful

      Fortunately one fuckwitted judge will not be permitted to single handedly bring down the internet.

    2. Re:Actually, IP Addresses COULD be portable... by Anonymous Coward · · Score: 0

      The problem with portable IPs is that it makes routing more and more of a headache, and take up more memory in routers.

    3. Re:Actually, IP Addresses COULD be portable... by Anonymous Coward · · Score: 0

      IPs used to be portable, but they changed this about five years ago, when keeping track of all the IPs that moved around became a royal pain.

    4. Re:Actually, IP Addresses COULD be portable... by DarthBart · · Score: 1

      1GB of ram just to hold a BGP table.

      Great.

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

  17. Re:"A little-known DNS behavior called credibility by NanoGator · · Score: 0

    "Verisign Registry's Matt Larson answered this on the NANOG list late Friday:"

    Well, I don't remember Matt Larson being on me Friday, but I do remember being puzzled as to why I fouond a traffic cone in my bed.

    --
    "Derp de derp."
  18. If there's an injunction by phr2 · · Score: 1
    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.

  19. Yet another Y2038 problem by Anonymous Coward · · Score: 1, Funny

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

    1. Re:Yet another Y2038 problem by Anonymous Coward · · Score: 0

      Is the serial number format a MUST or a SHOULD?

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

    3. Re:Yet another Y2038 problem by prog-guru · · Score: 1

      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

      --

      chris@xanadu:~$ whatis /.
      /.: nothing appropriate.

    4. Re:Yet another Y2038 problem by flonker · · Score: 1

      Except it won't. The arithmatic is a little tricky, and I don't know it off the top of my head. Suffice it to say, (maxint 0) && (minint 0). (They redefined greater than and less than.)

    5. Re:Yet another Y2038 problem by Anonymous Coward · · Score: 0

      Easily solved by using the Unix timestamp modulo 2^31. Serial numbers naturally wrap back around so it won't be an issue.

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

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

    1. Re:Only affects root's maps by Anonymous Coward · · Score: 0

      finally, in this whole discussion, someone with a bit of sense.

      can you expand upon this to describe how this works(or doesn't) in terms of "root servers" vs "gTLD servers"

      your use of "root maps" doesn't tell me what server/level this affects.

      the root map could exist anywhere. are you referring to the "root servers"

      if so. i thought verisign only had control over "A"

      please explain, as if I'm a 5 year old.

  23. WHOIS by Anonymous Coward · · Score: 1, Interesting

    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 being disconnected for like a day during a phone company outage and that was enough for the domain to be taken.

    So yes, censorship is very alive and well and it doesn't have to target your hosting provider.

    The best way to combat this problem is to get a domain registrar that actually respects the customer and gives them a chance to update information that they might have forgotten to update or to simply explain is valid but that there are circumstances such as you not being home 24/7 to answer your phone and what not. GoDaddy and DOTSTER are definitely not companies you want to do business with if you don't want your domain to be yanked unjustly at random.

  24. Re:Die script kiddie by Anonymous Coward · · Score: 1, Funny

    No, no, no... you always reverse the DNS polarity first, THEN start rotating frequencies. Sheesh...

  25. Don't understand DNS by max+born · · Score: 1

    Pardon my ignorance but why are not all DNS updates instantaneous?

    1. Re:Don't understand DNS by Sicnarf · · Score: 1

      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.

    2. Re:Don't understand DNS by Peridriga · · Score: 2, Informative

      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

    3. Re:Don't understand DNS by Anonymous Coward · · Score: 0

      Because we lazy DNS implementors are too lazy to implement a real database for DNS. Anyway, they don't pay us enough to do so.

    4. Re:Don't understand DNS by defsdoor · · Score: 1

      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.

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

    1. Re:What happens in 2038?! by TheSunborn · · Score: 1

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

    2. Re:What happens in 2038?! by LoadWB · · Score: 1

      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 in a single day, rather than overall. Comparisons would hinge on the year, month, day, then revision. If the serial number is not in this format, then a straight value comparison.

      Or am I missing something here?

    3. Re:What happens in 2038?! by Anonymous Coward · · Score: 0

      No. The serial in a SOA record is stored as a 32-bit integer. Please read section 3.3.13 of RFC 1035. We can only use 31 bits of the integer, as specified in another RFC, as it turns out, so, yes, this method has a Y2038 problem.

    4. Re:What happens in 2038?! by Anonymous Coward · · Score: 0

      The only thing you're missing is that you cant fit a 32 bit number into two characters. :)

    5. Re:What happens in 2038?! by Anonymous Coward · · Score: 0

      Except that since the serial number can wrap around it's not likely to be an issue.

    6. Re:What happens in 2038?! by Anonymous Coward · · Score: 0
      Ah, the number can wrap but what about the logic that compares the serial of the copy the slave already has with the copy on the master?
      if (myserial < masterserial) {
      do get "zone"
      }
      How does the number wrapping help?

      ecode sucks...
    7. Re:What happens in 2038?! by Anonymous Coward · · Score: 0

      The way DJB handles this in his axfr client is to have the psudocode look like this:

      if (myserial != masterserial) { get zone }

      Another solution is to simply always get the zone.

    8. Re:What happens in 2038?! by Mercury2k · · Score: 1

      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.

    9. Re:What happens in 2038?! by Nevyn · · Score: 1
      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.
      --
      ustr: Managed string API with ave. 44% overhead over strdup(), for 0-20B
    10. Re:What happens in 2038?! by LoadWB · · Score: 1

      I actually had not meant the xx to be limited to two characters. xx can be of any length, including the necessary length to accomodate a 32-bit signed (or unsigned) number.

      Even so, that does not answer my question.

  27. Cool, .com dyn-dns by Sicnarf · · Score: 1

    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?

    1. Re:Cool, .com dyn-dns by Anonymous Coward · · Score: 2, Informative

      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.

    2. Re:Cool, .com dyn-dns by Anonymous Coward · · Score: 0

      ...and have www.yourdomain.com as a CNAME record to yourname.dyndns.org.

      First off, to set www.yourdomain.com to ANYTHING, you have to have an authorative DNS server. If you run it yourself, you have to set the IP address with your registar. If your IP changes, you have to do a zone update to the TLD to change the IP, which is one of the things that is speeded up in the new Verisign Plan.
      Second, I could be wrong on this, but I believe you can't set yourdomain.com as a cname.

    3. Re:Cool, .com dyn-dns by DaCool42 · · Score: 1

      My registrar provides the option of running the authoritative DNS server for you.

      --

      ----
      All of whose base are belong to the what-now?
  28. Re:Die script kiddie by Tuxedo+Jack · · Score: 1

    It won't do jack if the attack is by domain name, a la the one a certain bastard search company targeted at spywareinfo.com and merijn.org a while back. Target by domain name, and under this new system, you're guaranteed to be off the net permanently.

    --

    Striking fear in the authors of godawful fanfiction, I am here, appearing in darkness, Tuxedo Jack!
  29. suxors by mklutz · · Score: 0, Redundant

    Yeah, too bad Verisign sucks, especially in comparison to other, more user and wallet-friendly DNS services...

  30. Verisign doesn't do ANYTHING benevolently by mabu · · Score: 2, Interesting

    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?

    1. Re:Verisign doesn't do ANYTHING benevolently by kimba · · Score: 1

      VeriSign doesn't own a registrar so your conspiracy theory makes no sense.

    2. Re:Verisign doesn't do ANYTHING benevolently by mabu · · Score: 1

      Isn't Network Solutions a Verisign company?

    3. Re:Verisign doesn't do ANYTHING benevolently by kimba · · Score: 1

      No, they sold it 6 months ago.

    4. Re:Verisign doesn't do ANYTHING benevolently by Roadkills-R-Us · · Score: 1
      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 some).


      The first point is obviously good for all of us, the second certainly doesn't hurt us.

  31. Re:"A little-known DNS behavior called credibility by Lord+Bitman · · Score: 1

    You again! Don't you ever stop? :)

    --
    -- 'The' Lord and Master Bitman On High, Master Of All
  32. Re:"A little-known DNS behavior called credibility by NanoGator · · Score: 0, Offtopic

    Aww bummer. Well either I was modded overrated because the joke wasn't funny, or because nobody got the joke.

    The 'NANOG' bit should be obvious. The traffic cone comment was a Red Dwarf reference. That should have gotten me an instant +4 Funny. :P

    --
    "Derp de derp."
  33. With everything else as instant as it is... by clifgriffin · · Score: 1, Insightful

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

    --
    clifgriffin > blog
  34. And the spammers rejoice by Anonymous Coward · · Score: 0

    Now they can register a fake domain in minutes, and get past SPF. Then destroy the domain w/o a trace.. Thanks verisign..

  35. "Vhost" on IRC by Anonymous Coward · · Score: 0

    My oh my, will those kids like this new feature, yes? I'm afraid they will. In 2 seconds they can change their DNS to something more l33t now :(

  36. Re:"A little-known DNS behavior called credibility by mattbee · · Score: 2, Interesting

    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
  37. Re:Die script kiddie by dave420 · · Score: 1

    They've adapted!! Arrrgh!! :-P

  38. um by mabu · · Score: 1

    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 businesses, organizations and individuals.

    1. Re:um by kimba · · Score: 1

      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 such as business email, website hosting and other web presence services.

  39. Re:"A little-known DNS behavior called credibility by qtp · · Score: 1

    the reason has a lot to do with a little-known DNS behavior called credibility.

    Wow, it sounds like he's talking about a well-known DNS attribute called "AUTHORITY".

    --
    Read, L
  40. The Sky is Intact by bill_mcgonigle · · Score: 1

    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.

    --
    My God, it's Full of Source!
    OUTSIDE_IP=$(dig +short my.ip @outsideip.net)