Beta
×

Welcome to the Slashdot Beta site -- learn more here. Use the link in the footer or click here to return to the Classic version of Slashdot.

Thank you!

Before you choose to head back to the Classic look of the site, we'd appreciate it if you share your thoughts on the Beta; your feedback is what drives our ongoing development.

Beta is different and we value you taking the time to try it out. Please take a look at the changes we've made in Beta and  learn more about it. Thanks for reading, and for making the site better!

Verisign Speeds Up DNS Updates

michael posted more than 10 years ago | from the creating-throwaway-domains-now-much-faster dept.

The Internet 131

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

cancel ×

131 comments

Sorry! There are no comments related to the filter you selected.

I wonder what brought this on? (4, Insightful)

rkz (667993) | more than 10 years ago | (#9669185)

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

MOD PARENT DOWN, RKZ = GNAA TROLL (-1, Troll)

Anonymous Coward | more than 10 years ago | (#9669383)

That is all

Re:I wonder what brought this on? (-1, Troll)

Anonymous Coward | more than 10 years ago | (#9669433)

Mods might want to take into consideration that the google link RKZ is listing as his "home page" is a last measure link. (at least at the time of this posting; I'm sure as soon as I post this, he'll change it to something else. [google.com]

Thanks, Verisign... (5, Funny)

SamMichaels (213605) | more than 10 years ago | (#9669187)

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

Re:Thanks, Verisign... (2, Funny)

Tokerat (150341) | more than 10 years ago | (#9669209)


I second that.

Re:Thanks, Verisign... (1)

Neophytus (642863) | more than 10 years ago | (#9669398)

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

Re:Thanks, Verisign... (2)

bugmenot (788326) | more than 10 years ago | (#9669468)

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.

Re:Thanks, Verisign... (1)

Rei (128717) | more than 10 years ago | (#9669550)

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... (3, Insightful)

Neon Spiral Injector (21234) | more than 10 years ago | (#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.

Re:Thanks, Verisign... (3, Informative)

GoRK (10018) | more than 10 years ago | (#9670629)

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.

Die script kiddie (0, Offtopic)

0x54524F4C4C (712971) | more than 10 years ago | (#9669196)


Will this put an end of DDOS attacks?
Your guess is welcome, paint it in the wall.

Re:Die script kiddie (0)

Anonymous Coward | more than 10 years ago | (#9669310)

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

Actually, IP Addresses COULD be portable... (0)

Anonymous Coward | more than 10 years ago | (#9669339)

IP Address are now portable [broadbandreports.com]

Re:Actually, IP Addresses COULD be portable... (1, Insightful)

Anonymous Coward | more than 10 years ago | (#9669384)

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

Re:Actually, IP Addresses COULD be portable... (0)

Anonymous Coward | more than 10 years ago | (#9669703)

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

Re:Actually, IP Addresses COULD be portable... (0)

Anonymous Coward | more than 10 years ago | (#9669745)

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.

Re:Die script kiddie (4, Insightful)

NanoGator (522640) | more than 10 years ago | (#9669367)

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

Re:Die script kiddie (5, Funny)

Anonvmous Coward (589068) | more than 10 years ago | (#9669427)

"Will this put an end of DDOS attacks?"

We're under attack! Rotate DNS frequencies!

Re:Die script kiddie (1, Funny)

Anonymous Coward | more than 10 years ago | (#9669832)

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

Re:Die script kiddie (1)

Tuxedo Jack (648130) | more than 10 years ago | (#9670896)

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.

What about .cx domains? (-1, Offtopic)

Anonymous Coward | more than 10 years ago | (#9669201)

Clarke R L
543 Murray Rd
Christmas Island 6798
(08) 9164 8949

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

rritterson (588983) | more than 10 years ago | (#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... (5, Informative)

LostCluster (625375) | more than 10 years ago | (#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... (4, Informative)

AKnightCowboy (608632) | more than 10 years ago | (#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" (5, Informative)

jea6 (117959) | more than 10 years ago | (#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.

Re:"A little-known DNS behavior called credibility (0)

NanoGator (522640) | more than 10 years ago | (#9669389)

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

Re:"A little-known DNS behavior called credibility (1)

Lord Bitman (95493) | more than 10 years ago | (#9671365)

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

Re:"A little-known DNS behavior called credibility (0, Offtopic)

NanoGator (522640) | more than 10 years ago | (#9671517)

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

Re:"A little-known DNS behavior called credibility (4, Funny)

Landaras (159892) | more than 10 years ago | (#9669614)

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

Domain Name Portablity... (5, Insightful)

LostCluster (625375) | more than 10 years ago | (#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.

Re:Domain Name Portablity... (0)

Guspaz (556486) | more than 10 years ago | (#9669235)

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.

Re:Domain Name Portablity... (2, Insightful)

LostCluster (625375) | more than 10 years ago | (#9669341)

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

Re:Domain Name Portablity... (0)

Guspaz (556486) | more than 10 years ago | (#9670213)

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

Re:Domain Name Portablity... (5, Funny)

Anonymous Coward | more than 10 years ago | (#9670991)

I browse at +1. ACs need not reply.
Guess you won't read this, fuck face.

Re:Domain Name Portablity... (0, Troll)

Lord Bitman (95493) | more than 10 years ago | (#9671503)

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

Re:Domain Name Portablity... (0)

Anonymous Coward | more than 10 years ago | (#9669244)

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

/ Confused /. Reader

Re:Domain Name Portablity... (1, Redundant)

icebike (68054) | more than 10 years ago | (#9669498)

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.

Re:Domain Name Portablity... (0)

Anonymous Coward | more than 10 years ago | (#9669601)

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.

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

Anonymous Coward | more than 10 years ago | (#9669690)

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 (2, Insightful)

WebMasterP (642061) | more than 10 years ago | (#9669227)

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.

There are worse things. (-1, Offtopic)

James A. U. Joyce (795786) | more than 10 years ago | (#9669230)

Who can't wait a couple of days for DNS to propagate? There's something more important to worry about - I can't wait until Verisign lets go of its virtual monopoly on website certification. It's ridiculous to have something as important as that in the hands of one organisation.

Re:There are worse things. (-1, Offtopic)

Anonymous Coward | more than 10 years ago | (#9669382)

ya kook

Censorship? (4, Interesting)

phr2 (545169) | more than 10 years ago | (#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.

Re:Censorship? (1)

sploo22 (748838) | more than 10 years ago | (#9669348)

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

Re:Censorship? (2, Informative)

hunterx11 (778171) | more than 10 years ago | (#9669742)

Usually, but not always--case in point goatse.cx [goatse.cx] .

Now watch as I get modded down for goatse :)

WHOIS (1, Interesting)

Anonymous Coward | more than 10 years ago | (#9669815)

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.

Re:Censorship? (3, Interesting)

LostCluster (625375) | more than 10 years ago | (#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.

If there's an injunction (1)

phr2 (545169) | more than 10 years ago | (#9669414)

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.

Re:Censorship? (1)

toasted_calamari (670180) | more than 10 years ago | (#9669404)

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

Re:Censorship? (1)

NanoGator (522640) | more than 10 years ago | (#9669412)

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

Re:Censorship? (0)

Anonymous Coward | more than 10 years ago | (#9670275)

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

Re:Censorship? (0)

Anonymous Coward | more than 10 years ago | (#9671099)

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

Re:Censorship? (1)

Zeinfeld (263942) | more than 10 years ago | (#9670002)

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.

WTF (0, Flamebait)

Turn-X Alphonse (789240) | more than 10 years ago | (#9669250)

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

Re:WTF (0)

Anonymous Coward | more than 10 years ago | (#9669320)

You are a genius.

Re:WTF (1)

hypermike (680396) | more than 10 years ago | (#9669528)

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

Re:WTF (0)

Anonymous Coward | more than 10 years ago | (#9669756)

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.

Re:WTF (1)

mirror_dude (775745) | more than 10 years ago | (#9670952)

But you seem to be missing the point. The changes are submited to verisign by the registrars. It doesnt take a lot more CPU usage to make the changes as they come in than once every five minutes
Allow me to attempt to explain this a bit better
The update system is interupt based, when a change (in the form of new registration , transfer of registrars, or change of name servers) occurs the update is sent to verisign. Now their is no need for verisgn to scan/poll the individual registrars for when updates occur, because they tell verisign when the update occurs and what the exact changes are.

Re:WTF (1)

NanoGator (522640) | more than 10 years ago | (#9669562)

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

Then it goes nowhere, but does it really fast!

Re:WTF (0)

Anonymous Coward | more than 10 years ago | (#9669693)

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

Re:WTF (0)

Anonymous Coward | more than 10 years ago | (#9669887)

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.

On-Demand Update? (2, Insightful)

powerpuffgirls (758362) | more than 10 years ago | (#9669270)

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?

Re:On-Demand Update? (1)

LostCluster (625375) | more than 10 years ago | (#9669525)

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

Re:On-Demand Update? (1)

prog-guru (129751) | more than 10 years ago | (#9670053)

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... (5, Interesting)

LostCluster (625375) | more than 10 years ago | (#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.

Re:Spammer's Delight... (4, Informative)

Erik Hensema (12898) | more than 10 years ago | (#9669357)

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.

Re:Spammer's Delight... (0)

Anonymous Coward | more than 10 years ago | (#9669556)

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.

Good for spammers (-1, Redundant)

eadz (412417) | more than 10 years ago | (#9669276)

Isn't this good news for spammers? Now they can quicky shift their websites round before their hosting companies shut them down.

Glad to see Verisign coming up to the times (5, Insightful)

gonknet (594078) | more than 10 years ago | (#9669293)

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 (4, Informative)

Jayfar (630313) | more than 10 years ago | (#9669370)

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

Re:Yep, your org took less than 5 mins (4, Funny)

The Lord of Chaos (231000) | more than 10 years ago | (#9669559)

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

Re:Glad to see Verisign coming up to the times (1)

Tony Hoyle (11698) | more than 10 years ago | (#9669516)

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.

Re:Glad to see Verisign coming up to the times (0)

demon (1039) | more than 10 years ago | (#9669668)

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.

Re:Glad to see Verisign coming up to the times (0)

Anonymous Coward | more than 10 years ago | (#9669760)

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

Re:Glad to see Verisign coming up to the times (0)

Anonymous Coward | more than 10 years ago | (#9671112)

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

Err.. (1)

slimyrubber (791109) | more than 10 years ago | (#9669333)

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.. (2, Insightful)

BlueCup (753410) | more than 10 years ago | (#9669458)

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.

Re:Err.. (1)

Alan Hicks (660661) | more than 10 years ago | (#9671472)

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.

Yet another Y2038 problem (1, Funny)

Anonymous Coward | more than 10 years ago | (#9669421)

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

Re:Yet another Y2038 problem (0)

Anonymous Coward | more than 10 years ago | (#9669518)

Is the serial number format a MUST or a SHOULD?

Re:Yet another Y2038 problem (3, Interesting)

Anonymous Coward | more than 10 years ago | (#9669565)

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.

Re:Yet another Y2038 problem (1)

flonker (526111) | more than 10 years ago | (#9670350)

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

Re:Yet another Y2038 problem (0)

Anonymous Coward | more than 10 years ago | (#9670902)

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

Re:Yet another Y2038 problem (1)

prog-guru (129751) | more than 10 years ago | (#9669968)

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 (5, Informative)

rufey (683902) | more than 10 years ago | (#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.

Re:Only affects root's maps (0)

Anonymous Coward | more than 10 years ago | (#9670509)

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.

infor8ative dollDOLL (-1, Troll)

Anonymous Coward | more than 10 years ago | (#9669993)

hobby. It 3as all share. *BSD is

Don't understand DNS (1)

max born (739948) | more than 10 years ago | (#9670125)

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

Re:Don't understand DNS (1)

Sicnarf (529730) | more than 10 years ago | (#9670419)

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.

Re:Don't understand DNS (2, Informative)

Peridriga (308995) | more than 10 years ago | (#9671010)

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

What happens in 2038?! (3, Insightful)

Mercury2k (133466) | more than 10 years ago | (#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 ;)

Re:What happens in 2038?! (1)

TheSunborn (68004) | more than 10 years ago | (#9670427)

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

Re:What happens in 2038?! (1)

LoadWB (592248) | more than 10 years ago | (#9670973)

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?

Re:What happens in 2038?! (0)

Anonymous Coward | more than 10 years ago | (#9671513)

No. The serial in a SOA record is stored as a 32-bit integer. Please read section 3.3.13 of RFC 1035 [ietf.org] . 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.

Cool, .com dyn-dns (1)

Sicnarf (529730) | more than 10 years ago | (#9670435)

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 (2, Informative)

Anonymous Coward | more than 10 years ago | (#9671136)

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.

Re:Cool, .com dyn-dns (0)

Anonymous Coward | more than 10 years ago | (#9671318)

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

suxors (0, Redundant)

mklutz (788794) | more than 10 years ago | (#9671147)

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

Verisign doesn't do ANYTHING benevolently (2, Interesting)

mabu (178417) | more than 10 years ago | (#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?

Load More Comments
Slashdot Login

Need an Account?

Forgot your password?

Submission Text Formatting Tips

We support a small subset of HTML, namely these tags:

  • b
  • i
  • p
  • br
  • a
  • ol
  • ul
  • li
  • dl
  • dt
  • dd
  • em
  • strong
  • tt
  • blockquote
  • div
  • quote
  • ecode

"ecode" can be used for code snippets, for example:

<ecode>    while(1) { do_something(); } </ecode>