Faster Updates for DNS Root Servers Arrive

dynamic dns by Anonymous Coward · 2004-09-09 00:11 · Score: 5, Interesting

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

Re:dynamic dns by numbski · 2004-09-09 00:28 · Score: 5, Informative

It's already there.

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

--
Karma: Chameleon (mostly due to the fact that you come and go).
Re:dynamic dns by Anonymous Coward · 2004-09-09 00:42 · Score: 0

dyndns.org Not a job for the root servers...
Re:dynamic dns by two-tail · 2004-09-09 00:44 · Score: 5, Informative

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

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

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

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

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

I sure wouldn't want to try that, though....
Re:dynamic dns by Delphis · 2004-09-09 02:11 · Score: 1

Ah hell, I have a few spare domains that it might be fun to try it with.

The problem is the registrars though, are they going to accept/allow people to change their information that quickly? Also, there's the process of actually performing the change. Sounds like lots of crap with CURL to get that to work - and then they'll change their site and break your DNS :>

The update process for most registrars is log in, enter/click on domain, change options, save. Depending on THEIR processes then on the registrars side it could be a while before they even send the update to the name servers, it could take an unfeasible amount of time to get your new IP usable on the internet again. Updating the root-level SOA records is the last piece of the puzzle.

--
Delphis
Re:dynamic dns by BenFranske · 2004-09-09 02:29 · Score: 2, Interesting

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

Might I recommend using IPCop on an old PC as a firewall/NAT device for your home network? It contains the ability to automatically update your IP address to dyndns and several other dynamic services. Its also a nice firewall product, which is free (as in beer and speech).
Re:dynamic dns by robertjw · 2004-09-09 02:50 · Score: 4, Funny

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

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

--
Find coupons in Greeley
Re:dynamic dns by drinkypoo · 2004-09-09 02:56 · Score: 1

To be fair, you don't need to be running BIND locally. You can also be using Windows 2000 for a DHCP and DNS server and get local dynamic DNS updates. It helps to use Active Directory as well. While for most people this isn't going to end up being all that much easier than rolling it up with Linux, it IS easier, and it IS a possibility. Of course, paying for 2k Server is kind of a stumbling block for most people, even those who have a second machine upon which they could be running BIND. And of course, you can run BIND on a lot less machine.

--
"You're right," Fisheye says. "I should have set it on 'whip' or 'chop.'"
Re:dynamic dns by numbski · 2004-09-09 03:34 · Score: 1

That, or on your windows workstation load cygwin and bind.

The part that sucks is that last time I tried installing cygwin, it was incredibly difficult, this coming from someone that manages many FreeBSD text-only servers, and uses many different flavors of linux. Perhaps cygwin has improved?

--
Karma: Chameleon (mostly due to the fact that you come and go).
Re:dynamic dns by drinkypoo · 2004-09-09 03:48 · Score: 1

Cygwin is stunningly easy to install now. The only caveat is remembering to shut off all cygwin services and shells when updating cygwin, or you'll have DLL problems. However, this doesn't solve the problem that BIND is the hard part. Hell, IMO setting up a whole base linux system is easier than setting up BIND and ISC DHCP, even if that system is running gentoo, and especially if you're trying to get ddns working. Mind you, I have all that stuff working on my gentoo system, but I had to piece it together from about six different documents. Not exactly intuitive, eh? Nor well-documented.

--
"You're right," Fisheye says. "I should have set it on 'whip' or 'chop.'"
Re:dynamic dns by MrNemesis · 2004-09-09 03:53 · Score: 1

I don't know about the Linksys, but all of the DrayTek DSL routers I've used have an inbuilt dyndns client (they also have clients for no-ip and all the other popular DNS providers). It grabs your dynamic IP address as soon as a connection is made, and pings it up to your DynDNS account. Works like a charm.

I wouldn't be surprised if this is included in pretty much every router these days.

--
Moderation Total: -1 Troll, +3 Goat
Re:dynamic dns by shufler · 2004-09-09 04:32 · Score: 1

The joke is that is exactly what happened the first time I tried installing qmail. It wouldn't work for hours upon hours, and then all of a sudden, mail was flowing through as if it was destined to.

And then, one day, qmail stopped, and would never start again.

Coincidentally, the Gmail beta became available that very day.
Re:dynamic dns by shufler · 2004-09-09 04:34 · Score: 1

I know D-Link makes routers that have this support as well, and in fact, I own one. I have yet to test it out, because for whatever reason, it could not maintain the PPPoE connection with my ISP.

So I turned off all the routing features, and now it's but a lonely switch off on the fringe of my LAN.
Re:dynamic dns by Zaiff+Urgulbunger · 2004-09-09 04:37 · Score: 1

My Netgear DG384G has it... I've not tried it though.
Re:dynamic dns by binaryspiral · 2004-09-09 05:01 · Score: 1

Why not just install a DynDNS client on your server? I have one that checks my public IP every 5 minutes and updates DynDNS automagically.

It just works.

And don't use the client built into your cheap resi grade broadband routers - they force too many updates and will automatically close your account. Netgear is horrible about that... well, that and many other things.
Re:dynamic dns by tigress · 2004-09-09 05:36 · Score: 2, Informative

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

I really don't think you would want to put much on a DynDNS network. After all, everything related to SMTP is automatically /dev/nulled by just about everyone in the world.

And to think, since they've done that, spam and viral infections on the internet have pretty much continue at pace.

I'm a disgruntled DynDNS user who can't send any email from my servers, even though they are legit.
Re:dynamic dns by gr8fulnded · 2004-09-09 07:04 · Score: 1

I say the same thing about Sendmail during interviews.

"So, Mr. Smith, it says here that you know Sendmail?"

"Well, I'm not virgin to it. I'm comfortable with Sendmail, but anything that requires a 1200 page book is a topic nobody REALLY knows."
Re:dynamic dns by jandrese · 2004-09-09 07:39 · Score: 1

DHCP isn't really that hard, but the documentation that comes with the release is not very good for mere mortals. I've had a lot better luck going online and finding an example config file and just editing that to do what I need. Especially if you aren't trying to be really fancy with your DHCP, this works great.

--

I read the internet for the articles.
Re:dynamic dns by drinkypoo · 2004-09-09 07:56 · Score: 1

Really it's more about BIND than DHCP. DHCP was easy to set up, as you say, by hacking someone else's config file. BIND, on the other hand, is hard to grok that way. I've been using it for a long while so I don't have too much trouble, but I set it up so infrequently that I still have to RTFM every time.

--
"You're right," Fisheye says. "I should have set it on 'whip' or 'chop.'"
Re:dynamic dns by rs79 · 2004-09-09 08:16 · Score: 1

I don't think anyone actually knows how to work dns./I.

I do.

The root servers serve up the root zone, which is pointers to tld servers. I don't really think you want them doing dynamic dyn-dns. You were thinking of the com/net servers perhaps?

--
Need Mercedes parts ?
Re:dynamic dns by jdkane · 2004-09-09 12:49 · Score: 1

I'm using my D-LINK 604 built-in DynDns update service. Works like a charm. It's smart and doesn't force too many updates. I've been using it for about two years -- always connected to the Internet over PPOE.
The best hint I can give from my experience is upgrade the firmware on your D-Link if an update is available. If you have the latest firmware then try resetting the device to factory settings and upgrade to the latest firmware again. I once had a successful firmware update to my D-LINK (at least no reported failure) and then no end of trouble for it to maintain a connection to the ISP ... and it kept freezing. So I ended up resetting it and re-updating the firmware and it has worked like a charm ever since. Odd but true.
Re:dynamic dns by AKnightCowboy · 2004-09-09 13:00 · Score: 1

And then, one day, qmail stopped, and would never start again.
Try using a mailer that doesn't suck, like Postfix.
Re:dynamic dns by Anonymous Coward · 2004-09-09 16:56 · Score: 0

Yes, some of us *DO* know how to work DNS. And laugh everytime we see some moron creating a 'localhost.theirdomain.com' in every zonefile.

And qmail is a horrific pile of shit.

HAND HTH PTD
Re:dynamic dns by ePhil_One · 2004-09-10 03:54 · Score: 1

I say the same thing about Sendmail during interviews.
I use a similar process when interviewing. Our company hands prospects one of those "Rate yourself from 1 to 10 forms on these 20 topics" forms. Anyone who rates themselves a 10 on ANYTHING gets a mental 7, because clearly they don't even know what they don't know. Somebody with the brains to rate themselves a 9 is very likely an expert, though some quizzing is needed to make sure, though a cross check on the number of 8-10's can usually tell you; nobody is an expert at everything. Problem is, HR departments often don't get this, and tend to forward the idiots who rate themselves a 10 on 90% of the topics.
Which is why I hate those things.

--
You are in a maze of twisted little posts, all alike.
Re:dynamic dns by MrNemesis · 2004-09-10 11:33 · Score: 1

The DrayTek only polls dyndns when it is issued with a new IP address and when the connection goes and comes back. Typically, I last for about a month before I get issued with a new IP, and my dyndns acount shows that my IP gets polled... about once a month ;)

I didn't want to bother installing a client on my server(s) because a) I don't want to run any more services than are neccesary and b) the DrayTek seems to handle it perfectly. And DrayTek are most definitely aimed at businesses, not consumers.

--
Moderation Total: -1 Troll, +3 Goat

For all registrars, or just some? by two-tail · 2004-09-09 00:12 · Score: 3, Interesting

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

Re:For all registrars, or just some? by numbski · 2004-09-09 00:30 · Score: 2, Informative

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

Anyone have further input?

--
Karma: Chameleon (mostly due to the fact that you come and go).
Re:For all registrars, or just some? by WhiteDeath · 2004-09-09 00:58 · Score: 3, Interesting

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

Changing to a UTC timestamp in seconds is no big issue, but for conformity, it's nice if everyone does the same thing, or at least knows what everyone else is doing, especially if you have some software trying to make sense of it all.
Re:For all registrars, or just some? by frozen_crow · 2004-09-09 01:15 · Score: 1

this is a change to the com and net nameservers. It has nothing to do with the domain name registration process, other than that such registrations (or changes to existing domains) will make it into the com and net nameservers faster. Assuming that your registrar doesn't dawdle, that is...
Re:For all registrars, or just some? by Lizard_King · 2004-09-09 01:20 · Score: 1

$ perl -e 'print scalar localtime '

While it may suck b/c you might have to change some workflow stuff at your ISP, it shouldn't be too difficult to write a script that produces a readable log of DNS changes.

--
"My mother never saw the irony in calling me a son-of-a-bitch." - Jack Nicholson
Re:For all registrars, or just some? by iamcadaver · 2004-09-09 02:21 · Score: 1

perl -e 'print scalar localtime '
returns:
Thu Sep 9 10:19:44 2004
whereas
date +%s
returns:
1094739487

--
Before I part with'em: two pennies weigh ~4.996+/-0.014g, have a zinc core, and the face of Lincoln. You can keep 'em.
Re:For all registrars, or just some? by 7x7 · 2004-09-09 06:48 · Score: 1

Actually this requires absolutly no change on the part of any ISP hosting any domain names. The serial numbers referenced are only used by the root servers to allow them to propagate changes within the 5 minute window to other root servers. All you gotta do is tell your new customers that you can have their .com and .net domains on your service in 5 minutes, no hassel.

It ain't a bad thing.

hmm, but is this really a good thing? by The+Pi-Guy · 2004-09-09 00:12 · Score: 5, Insightful

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

Re:hmm, but is this really a good thing? by fingon · 2004-09-09 00:15 · Score: 3, Insightful

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

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

--
-- pending
Re:hmm, but is this really a good thing? by BurritoWarrior · 2004-09-09 00:17 · Score: 1

Why can they not cache it same as always? You do a lookup on a domain at X, you can keep it cached for X + however long you wish.
Re:hmm, but is this really a good thing? by Anonymous Coward · 2004-09-09 00:17 · Score: 0

And there is also a reason why THEY are changing it to the NEW way they are doing it.
Re:hmm, but is this really a good thing? by ewithrow · 2004-09-09 00:19 · Score: 4, Insightful

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

Oh wait, VeriSign? We're all doomed.

--
http://almostsmart.com
Re:hmm, but is this really a good thing? by leperkuhn · 2004-09-09 00:22 · Score: 0, Redundant

yes, because 20 years ago computeres were slow pieces of shit.

--
http://www.rustyrazorblade.com
Re:hmm, but is this really a good thing? by LostCluster · 2004-09-09 00:24 · Score: 3, Insightful

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

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

It's so hard to get trust-based systems to work these days...
Re:hmm, but is this really a good thing? by Mordac+the+Preventer · 2004-09-09 00:27 · Score: 5, Informative

This is *theoretically* a good thing, but it means that applications cannot cache DNS as effectively for nonexistant domains. this may end up causing a *lot* heavier load on the root DNS servers.
No, it's the TTL that determines how long a record can be cached for. Updating the zone more frequently just means that the information will be available sooner. It will not increase the load on the root nameservers.

--
SteveB.
Re:hmm, but is this really a good thing? by multipartmixed · 2004-09-09 00:29 · Score: 0

> > it means that applications cannot cache DNS as effectively for nonexistant domains

> No, it's the TTL that determines how long a record can be cached for.

Out of idle curiosity, in which zone file do you set the TTL for the non-existant domain you're about to search for?

--

Do daemons dream of electric sleep()?
Re:hmm, but is this really a good thing? by LiquidCoooled · 2004-09-09 00:34 · Score: 5, Informative

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

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

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

--
liqbase :: faster than paper
Re:hmm, but is this really a good thing? by Coppit · 2004-09-09 00:36 · Score: 1

Nobody said the applications have to update every five minutes. They can still update infrequently, for the same quality of service (and cost) as before. Or am I missing something?
Re:hmm, but is this really a good thing? by swordboy · 2004-09-09 00:42 · Score: 1

this may end up causing a *lot* heavier load on the root DNS servers.

Maybe the guys at bittorrent should start a rogue P2P DNS serving system. If it worked well enough, it would become a defacto standard.

--

Life is the leading cause of death in America.
Re:hmm, but is this really a good thing? by Entrope · 2004-09-09 00:42 · Score: 5, Informative

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

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

Your comment that domains are not supposed to change every minute is correct for some domains; but the particular domains in question (TLDs) do change every minute as new domains are registered or expire. (Other things, like DHCP-driven dynamic DNS, can also legitimately cause frequent zone updates.)
Re:hmm, but is this really a good thing? by cortana · 2004-09-09 01:18 · Score: 1

I think you set it in the SOA record of the parent domain.
target ttl IN SOA domain "responsible person" serial refresh retry expire "nxdomain cache time"
Re:hmm, but is this really a good thing? by sw155kn1f3 · 2004-09-09 01:22 · Score: 2, Informative

It's simple:

# dig a alksasdasdqweqwehqwe.com

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

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

Let me clarify a few misconceptions.

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

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

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

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

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

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

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

--
FreeBSD: The Power to Serve!
Re:hmm, but is this really a good thing? by Gsus411 · 2004-09-09 01:27 · Score: 2, Insightful

Geeze. Why is everyone talking about the "root servers?" This isn't . (root zone), this is com. and net.! The two are not the same thing!
Re:hmm, but is this really a good thing? by Anonymous Coward · 2004-09-09 01:54 · Score: 0

You're quite correct.
Sadly most moronic system administrators & hosting companies forget this rather often, obviously resulting in excessive downtime.
Re:hmm, but is this really a good thing? by Kishar · 2004-09-09 02:18 · Score: 5, Informative

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

You're correct on all counts except this one.

From RFC1035:

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

The YYYYMMDDxx way can't be used past 2148, the UTC way can't be used past 2038. (neither way breaks it, because the serial number wraps to 0)
Re:hmm, but is this really a good thing? by surprise_audit · 2004-09-09 03:20 · Score: 1

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

Doesn't Unix time wrap around some time in 2035? I think the kernel stores time since the Epoch at least in milliseconds, if not nanoseconds...
Re:hmm, but is this really a good thing? by Anonymous Coward · 2004-09-09 04:06 · Score: 0

Of course, this is if your TTL is less than 24 hours.

If you TTL is currently at 24 hours or more, changing the TTL on the day of the move is too late. You need to take your current TTL and make the change at least that many seconds BEFORE the planned move.

I have seen TTLs set up to 30 days and then folks complain that their website isn't working for some folks. DUH.

Also, many Microsoft DNS servers corupt the TTL and give it a huge value (Years) so until the DNS service is restarted, your entrys will not update on these servers. I deal with this every time we update our DNS such as for Mail.

I am still seeing some folks hit our old DNS records years after I have changed them - such as MX records and customers (not spammers) trying to send in e-mail. (MX never pointed to A IN for .)

Fun fun.
Re:hmm, but is this really a good thing? by CmdrTHAC0 · 2004-09-09 04:12 · Score: 1

Doesn't Unix time wrap around some time in 2035? I think the kernel stores time since the Epoch at least in milliseconds, if not nanoseconds...

No. For one, keeping 1,000 times the precision would cost a tad more than 4.4% of the time period. Also, the higher-precision timers keep a pair of ints with Unix times (whole seconds) in one and the nanoseconds in the other, thus managing to use 64 bits and still be limited to the 31-bit (since time_t is signed) Unix epoch.

--
__CmdrTHAC0__
In Soviet Russia, Spanish Inquisition doesn't expect YOU!!
Re:hmm, but is this really a good thing? by LiquidCoooled · 2004-09-09 04:18 · Score: 1

Specific cases as you have mentioned need considering, but on the whole, the assertions I make are valid. :)

--
liqbase :: faster than paper
Re:hmm, but is this really a good thing? by Anonymous Coward · 2004-09-09 04:42 · Score: 0

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

DNS transmits SOA serial numbers as 32-bit integers, so yes, it does "suffer the 32-bit problem". YYYYMMDDNN as used currently results in numbers slightly less than 2^31. Implementations are explicitly required to compare serial numbers in a manner that compensates for the serial number wrapping at 2^32, so as long as you update your record every 2000 years you're fine.
Re:hmm, but is this really a good thing? by Feyr · 2004-09-09 05:01 · Score: 2, Informative

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

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

also, verisign pointed out the TTL will stay to 24 (or 48?) hours, so this really only affects NEW domains, unless you set your zone ttl to much lower in the first place (your zone has a higher trust than verisign's, so the ttl from that zone gets cached instead of theirs)
Re:hmm, but is this really a good thing? by surprise_audit · 2004-09-09 05:17 · Score: 1

I was wrong - as this extract from Wired shows:
In 2038, according to Ritchie and other experts, that 32-bit signed integer that Unix uses to count time will finally reach its last digit, and the change could conceivably cause problems.
That "Ritchie" as in "Bell Labs' Ritchie", who presumably has a clue...
Re:hmm, but is this really a good thing? by Anonymous Coward · 2004-09-09 05:22 · Score: 0

From experience with TTL I've notice that many people tend to ignore and warp the number if you set it to low.... Setting to less than 1 hour for example causes a lot of system to ignore the TTL and test it to a much higher false value.

Due to this, I normally set my TTLs to 3 hours when I am planning a change.
Re:hmm, but is this really a good thing? by Anonymous Coward · 2004-09-09 06:35 · Score: 0

I haven't met a router yet that had to deal with DNS.
Re:hmm, but is this really a good thing? by Anonymous Coward · 2004-09-09 18:03 · Score: 0

YYYYMMDDxx is good till 4294123199.

Using time_t as the serial is good forever provided you make atleast one update every 68 years. This will ensure that the new serial is always greater than the old serial using serial number arithmetic.

serial = ((seconds since epoch) % 0x100000000)

Given I fixed the serial number handling in the most popular nameserver on the planet I should know.

Great! by Anonymous Coward · 2004-09-09 00:14 · Score: 0, Funny

The spammers will love it.

Fantastic. by John_Allen_Mohammed · 2004-09-09 00:15 · Score: 4, Funny

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

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

--

Skype Me! username: john_allen_mohammed

Why? by tuxter · 2004-09-09 00:16 · Score: 1, Insightful

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

Re:Why? by mr_z_beeblebrox · 2004-09-09 00:54 · Score: 3, Informative

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

This will affect DNS customers not consumers. DNS is a purchased service (not a product) Businesses are its customers, users are its' consumers. Verisign wants to make a positive impact on its' customers to turn more revenue.
Re:Why? by MikeFM · 2004-09-09 09:28 · Score: 1

It certainly will make my life easier. It'll save me a lot of hassle waiting for a new domain to come up so my clients can be happy. I register a lot of domain names and overall people like to see their domain as soon as they've registered it. Registering and waiting is annoying and a hassle when you're trying to jump right in. It's especially important in cases where an existing website needs to change, or add, a domain name. It might seem a moot issue but I see it as a frequent annoyance.

For the average user it'll be reflected by fewer 'domain not found' errors. It's annoying to go to a site and try to follow a link only to find out that the domain name isn't valid for you yet. That seems to happen to me fairly often. I guess web designers get in a hurry to use their new domains.

Now.. if only I could keep people from setting their TTL to stupid values. I had one employer that had all their thousands of domains set to something like a week and then someone hacked into the domain register and changed all the IP addresses to point to a hacker site. That was lovely fun trying to explain why it took more than a week to fix. Good thing I didn't register all those domains and set their TTL. Likewise, you always have the nitwits that set their TTL for like 2 minutes. I generally set mine for like 15 minutes when I first register the domain and then after I work out any wrinkles I bump it up to something more reasonable. Usually 3 or 6 hours depending on the case.

--
At what price learning? At what cost wisdom? The price is a man's peace of mind, and the cost is his life.

In other news by Anonymous Coward · 2004-09-09 00:16 · Score: 4, Funny

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

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

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

Re:In other news by tuxter · 2004-09-09 00:33 · Score: 0

Bring on the next slow news day! Now we can ./ 300% more sites... w00t!

Root Servers... by jmcmunn · 2004-09-09 00:16 · Score: 5, Interesting

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

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

Re:Root Servers... by Guitar+Wizard · 2004-09-09 00:32 · Score: 0

"I mean, if my registrar (or dns service or whatever) still only send in their updates once every day, this won't really help me as much right?"

That's exactly my line of thought...even still though, this should (hopefully) allow for quicker DNS updates across the board. I know that when I first learned about DNS related stuff I was hesitant to experiment with things because of how long it would take for the changes to propogate (it was usually about 12 hours+ before my changes completed throughout DNS parent servers and their children).

--
Two freaks, no foes. It takes absolutely nothing to make some people angry.
Re:Root Servers... by frozen_crow · 2004-09-09 01:20 · Score: 1

you are correct. if your registrar only sends in changes once a day, then your changes won't make it into the dns very quickly. most registrars who operate in such a batch mode timed it so that they'd hit the update window, so you probably won't really see your changes any faster than they already are. This move may encourage registrars of all stripes to move to more of a dynamic model of updating, however.
Re:Root Servers... by Guanix · 2004-09-09 01:59 · Score: 1

Yes, but most registrars update live.
Re:Root Servers... by jabley · 2004-09-09 02:22 · Score: 5, Informative

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

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

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

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

Speed up attacks? by two-tail · 2004-09-09 00:16 · Score: 3, Interesting

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

Re:Speed up attacks? by LostCluster · 2004-09-09 00:27 · Score: 1

True, but I don't see how the DNS system's delay-created waiting period protected much from fraudulent transfers of domains. Afterall, you wouldn't know a false transfer took place until your DNS server got the bad news too...

increase of (mostly useless) traffic exptected? by Anonymous Coward · 2004-09-09 00:28 · Score: 0, Interesting

how about all those bazillion other nameservers, that would always reask for data every 5 minutes, as the dns records expire much more frequently now. is verisign and the other dns-rootservers able to cope with the load, or the internet in general?

Re:increase of (mostly useless) traffic exptected? by Tenareth · 2004-09-09 00:46 · Score: 3, Informative

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

--
This sig is the express property of someone.

Emergency use by pubjames · 2004-09-09 00:30 · Score: 1, Insightful

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

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

Re:Emergency use by Anonymous Coward · 2004-09-09 00:36 · Score: 2, Informative

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

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

on top of that if you have a standby box bring it online with the old ip
Re:Emergency use by autocracy · 2004-09-09 00:37 · Score: 4, Informative

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

--
SIG: HUP
Re:Emergency use by pubjames · 2004-09-09 00:37 · Score: 1

Not only that, but you can have them with completely different hosts, even in different countries.

I've seen big businesses who have lost their web sites for days because of the hurricane...
Re:Emergency use by Eggplant62 · 2004-09-09 00:38 · Score: 2, Informative

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

Happened to me with my vanity domain when afraid.org was cut off for about 8 hours due to abuse issues. His upstream provider cut him off due to spammers hosting DNS there and he had to take steps to get back online. Meanwhile, my domain was unresolvable. I ended up putting up secondaries to prevent this from happening again.
Re:Emergency use by LostCluster · 2004-09-09 00:38 · Score: 5, Informative

What's the point in that?

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

So, if you want fallover if your main web server goes down, you just need to update your local DNS record, not the one at the root servers. It's when your DNS servers explode that the five-minute updates would be helpful.
Re:Emergency use by pubjames · 2004-09-09 00:42 · Score: 1

What's the point in that?

Yep, my bad. I hope someone with a clue mods me down again!
Re:Emergency use by ostiguy · 2004-09-09 00:47 · Score: 4, Informative

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

ostiguy
Re:Emergency use by Anonymous Coward · 2004-09-09 00:53 · Score: 0

Even if you did switch the record, most chaching nameservers will probably screw you anyway. Probably half of the people who visit a site regularly will end up pointing in the wrong spot until the cache is updated. I've seen it take days for some caching nameservers to update themselves. I've seen one mail server that was still getting mail WEEKS after a DNS change that pointed mail to a new server.
Re:Emergency use by gtoomey · 2004-09-09 01:22 · Score: 1

No, the way to do that is to have a DNS server with small TTL (time to live) to switch IPs. Some cheap DNS Services allow you so set TTL, or you can run your own.
Re:Emergency use by frozen_crow · 2004-09-09 01:25 · Score: 1

OBPedant: You're correct in saying that this is the wrong way to go about it, but incorrect in suggesting that the com/net nameservers only hand out NS records. If an NS record points to a name that is inside the zone you're looking up, the com/net nameserver *also* has to hand out a glue (A) record for that name. It generally only happens in the case of a misconfiguration, but people have in the past put web and mail server A records into the com/net zones. Such a record will trump whatever's in the authoritative nameserver's zone file.

Cool.... by Eggplant62 · 2004-09-09 00:33 · Score: 4, Insightful

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

Misuse? by superhoe · 2004-09-09 00:36 · Score: 1

What effect will this have on DNS hijacking and similar hacking methods which utilize DNS? Will it be easier as things get more 'rapid'?

--

-el

Re:Misuse? by FooAtWFU · 2004-09-09 01:42 · Score: 1

If it does, I would imagine that it would also make it easier to change *back* rapidly. You'd likely also notice sooner- the servers would change within 5 minutes instead of half a day later. Good luck getting the bureaucracy to recognize your complaint, however...

--
The World Wide Web is dying. Soon, we shall have only the Internet.

In case of slashdot effect... by bruceg · 2004-09-09 00:39 · Score: 5, Informative

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

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

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

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

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

$ perl -e 'print scalar localtime 1076370400'

At the same time, we will also change the "minimum" value in the .com
and .net SOA records from its current value of 86400 seconds (one day)
to 900 seconds (15 minutes). This change brings this value in line
with the widely implemented negative caching semantics defined in
Section 4 of RFC 2308.

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

Matt
--
Matt Larson
VeriSign Naming and Directory Servic

Fifteen minutes? by semaj · 2004-09-09 00:44 · Score: 4, Insightful

From the linked NANOG posting:

"At the same time, we will also change the "minimum" value in the .com and .net SOA records from its current value of 86400 seconds (one day) to 900 seconds (15 minutes). This change brings this value in line with the widely implemented negative caching semantics defined in Section 4 of RFC 2308."

Doesn't that mean they're updating every fifteen minutes, not every five?

--
Meep meep

Re:Fifteen minutes? by frozen_crow · 2004-09-09 01:09 · Score: 3, Informative

no, it does not. it just means that if a resolver receives a "no such name" response from one of the com or net nameservers, that "no such name" response will only be cached for 15 minutes instead of a day.
Re:Fifteen minutes? by bfree · 2004-09-09 02:19 · Score: 2, Insightful

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

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

--
Never underestimate the dark side of the Source
Re:Fifteen minutes? by bfree · 2004-09-09 02:23 · Score: 2, Informative

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

--
Never underestimate the dark side of the Source

Way to go on the reading, sherlock! by Galadhrim · 2004-09-09 00:45 · Score: 0

Quote from VeriSign's website:

"VNDS is scheduled to deploy on September 8, 2004 a new feature that will enable VNDS to update the .com/.net zones more frequently to reflect the registration activity of the .com/.net registrars in near real time."

Quote from /.:

"Beginning September 9, 2004 the SOA records of the .com and .net zones will be updated every 5 minutes instead of twice a day."

Seems that someone got excited and got sloppy!

International Date Format by Compact+Dick · 2004-09-09 00:46 · Score: 5, Interesting

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

--
Use ISO 8601 dates [YYYY-MM-DD]

Re:International Date Format by Anonymous Coward · 2004-09-09 00:57 · Score: 0, Funny

I'm a geek so I can't get dates, you insensitive clod!
Re:International Date Format by danharan · 2004-09-09 02:39 · Score: 1

As noted in the first article you linked to, it's quite bizarre that the ISO asks you to pay money to get a copy of the standard. When shit like this happens, couldn't one of the internet standards organizations publish their own (compatible) standard?

--
Information: "I want to be anthropomorphized"
Re:International Date Format by jschrod · 2004-09-09 04:48 · Score: 1

Who modded that interesting?
The switch goes away from a format that is rougly ISO 6801, minus the punctionation, to UTC. Interestingly, the new format will wrap earlier now. (In 2038, instead of 2148.)

--
Joachim

People don't write Manifestos any more -- what's going on in this world? [Frank Zappa]

worx for me.. by Anonymous Coward · 2004-09-09 00:53 · Score: 0

'net evolution just made a nth power jump..

if a bag of glass falls in the desert, does it make a sound?

This has no effect by warrax_666 · 2004-09-09 00:54 · Score: 4, Insightful

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

--
HAND.

Re:This has no effect by Eggplant62 · 2004-09-09 01:44 · Score: 1

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

No, but it certainly allows them to now rotate nameservers for their domains quickly. Imagine where they've got a number of nameservers for their domains setup, and in order to make it more difficult to determine where the nameservers are hosted, they bounce them around every five minutes from one machine to the next, possibly rotating through as many as 600 different machines in a day!
Re:This has no effect by Doppleganger · 2004-09-09 04:01 · Score: 1

It does allow a spammer to change their nameserver real fast, however.

I've seen one spammer who liked to set up a redirector on an innocent-looking account on a server, then set the DNS that was under his control to point to it for short periods of time while sending out loads of spam. The redirector would remove itself after the time was up. Took months to get SPEWS to remove the listing for one server that he pointed the domain to for 15 minutes, even though the server was shut down minutes after complaints came rolling in and not brought back up until the reason was figured out.

Now, since SPEWS will sometimes blacklist nameserver IPs as well...
Re:This has no effect by Anonymous Coward · 2004-09-09 08:33 · Score: 0

Actually, this will allow registrars to remove spammer domains from the zone much more quickly.

Root servers? by bartjan · 2004-09-09 00:55 · Score: 4, Informative

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

2038 fun by martin · 2004-09-09 00:57 · Score: 2, Insightful

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

Brilliant move...:-(

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

ie YYYYMMDDHHmmNN ??

Re:2038 fun by frozen_crow · 2004-09-09 01:12 · Score: 1

that would make the digit string too long.

it doesn't really matter anyway, since zone serial numbers are allowed to wrap. secondaries understand how to handle this event as well, so there's no need for admins to step in and do anything in such cases, either.
Re:2038 fun by Anonymous Coward · 2004-09-09 01:21 · Score: 0

True, the DNS will handle whatever you put in the 32-bit SOA version number field. If there is any problem, it's that Verisign's formal specification (number of seconds since 1 Jan 1970) can't be adhered to after the year 2106, when that will require more than 32 bits. Ok, so they have a century to learn modulo arithmetic...
Re:2038 fun by gclef · 2004-09-09 01:26 · Score: 2, Interesting

They just said they were encoding the serial number as the seconds since epoch. They never said anywhere how many *bits* they're using to measure that. In fact, since the serial number is a free-form text field, there's not really any way to overflow that. The epoch overflow shouldn't affect this.
Re:2038 fun by aboyko · 2004-09-09 01:33 · Score: 1

What was wrong with it? RFC1035 is what was wrong with it. The serial field in the SOA is 32 bits, sparky.

But it's good that you pointed it out to them, because it otherwise might not occur to anyone.
Re:2038 fun by gclef · 2004-09-09 02:00 · Score: 1

I know it's bad form to reply to my own post, but I was semi-wrong, so I should fess up to it. RFC1035 states that the serial number field is 32 bits, but can wrap. The exact text is:
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.
So, there still isn't an epoch problem, but for a different reason.
Re:2038 fun by martin · 2004-09-09 02:13 · Score: 1

Ok I mean there is the potential for 32 bit issues, depending on how well the DNS servers (bind, tinyDNS etc) handle the serial number once its converted from a text string to a number..

just means one more risk/piece we have to check for when the epoch time rolls over the 32nd bit...
Re:2038 fun by amorsen · 2004-09-09 02:42 · Score: 4, Informative

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

--
Finally! A year of moderation! Ready for 2019?
Re:2038 fun by aboyko · 2004-09-09 02:43 · Score: 1

How do you mean, serial number is a free-form text field? BIND zone files are not the same thing as DNS. See RFC 1035 -- serial is 32 bits.
Re:2038 fun by Cecil · 2004-09-09 03:03 · Score: 1

Right, because YYYYMMDDHHmmNN can fit in a 32 bit integer with no problems at all.

4294967295 (max unsigned 32-bit number)
20040909090201 (sample of YYYYMMDDHHmmNN)

--
Random and weird software I've written.
Re:2038 fun by martin · 2004-09-09 03:21 · Score: 1

fair enough...that'll be the reason why they didn't use that method then!

My point is that the 2038 issue now has the *potential* to effect DNS more than it did before..

Of course in the next 34 years we'll be using 128 bit (or larger) numbers anyhow :-)
Re:2038 fun by Skapare · 2004-09-09 04:32 · Score: 1

There still can be an epoch problem, but only with external code not following RFC1035 to the letter. Given the lack of tools to make the wrapping comparison correctly, there are probably a lot of bad programs around. What I did on my DNS servers to eliminate the year 2038 (or 2106 for unsigned) impact is define the SOA as the system time divided by 4. So my servers won't have this impact until 2242-03-16 12:56:28 (or 2514-05-30 01:53:00 for unsigned), as long as there is a better source of system time from which to derive that number after 2038.

--
now we need to go OSS in diesel cars
Re:2038 fun by Cecil · 2004-09-09 06:50 · Score: 1

True, but even 64 bits will be able to count seconds until well after Sol has become a red giant and Earth has been incinerated.

Besides, we all know what a big deal Y2K turned out to be after all. Y2.038K will be an even smaller problem, since a) there is no user-interface for entering those numbers and b) except on the integer-size level, they are perfectly backwards compatable, ie sending you a string "1058382094" is a valid time, 32-bit or 64-bit or 4096-bit.

And the integer size issue needs to be dealt with for *every* integer a program uses, not just time. We'll still have problems with people who insist on using their old 32-bit computers 30 years from now because "it just works and we can't afford to port all our software over!" but that's their fault, and their problem.

Anyway, should be fun regardless. I look forward to the media hype. :)

--
Random and weird software I've written.

Re:International Date Format -- typo by Compact+Dick · 2004-09-09 01:12 · Score: 1

Pointing out the obvious -- that's ISO 8601, not ISO 6601.

--
Use ISO 8601 dates [YYYY-MM-DD]

Lucky me by IKEA-Boy · 2004-09-09 01:19 · Score: 1

My IP address just got changed 2 hours ago because I switched to a different ISP. I have a nameserver based on my own domain that is registered in the root servers and I expected the IP change to take a couple of days. But when I changed the IP of my nameserver (in the godaddy web interface) I was surprised to see it reflected after only a few minutes:

$ dig @a.gtld-servers.net a ns.XXXXX.net ;; ANSWER SECTION:
ns.XXXXX.net. 172800 IN A 62.216.XXX.XXX new IP

Very nice indeed! Now if I could only get zoneedit to accept the notifies my DNS server sends them...

Re:Lucky me by Anonymous Coward · 2004-09-09 02:10 · Score: 0

I think you will find the root servers updated quickly, but other DNSes on the net will cache old entries for up to a day.

This feature should not be used for an excuse to avoid planing and testing that is all too common in the click-kiddy generation.
Re:Lucky me by IKEA-Boy · 2004-09-09 03:54 · Score: 1

Although I find the click-kiddy label amuzing it doesn't apply. I know how to properly manage my DNS setup and I know how caching works, that's why I had modified the TTL and negative cache settings well in advance.

See this page if you need some more info about TTL's and IP migration:
http://www.netadmintools.com/art232.html

This IP migration was well-planned but for some reason zoneedit (my secondary) started refusing notifies from my primary DNS.

What about spammers? by thewalled · 2004-09-09 01:24 · Score: 0

Doesn't that also mean that spammers running their own DNS servers will now be able to change nameservers at will :-(, also beating spf in the process.

Just my point of view. maybe I'm wrong.

- dhawal

Hell Yeah! by CptTripps · 2004-09-09 01:39 · Score: 3, Interesting

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

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

--

My .sig can beat up your honor student.

Wow, netsol moves into the 80's by Trailer+Trash · 2004-09-09 01:48 · Score: 1

Do they have a web site yet?

--
Do you have ESP?

Re:Wow, netsol moves into the 80's by Phroggy · 2004-09-09 09:48 · Score: 1

They sold off Network Solutions quite awhile ago.

--
$x='S24;r)>63/* h@<5+oZ)32"5cz';$me='phroggy'x$];
$x=~y+ -xz+\0-Tx+;print$_^chop$me for split'',$x;

Things that are Certain by Mixel · 2004-09-09 02:30 · Score: 2, Funny

Death, Taxes and DNS Propagation Delay.

Sooner? by boatboy · 2004-09-09 03:17 · Score: 1

I registered a domain last week w/ godaddy.com, and was quite suprised when it was available within about 10 minutes. The domain went to the correct host from a variety of ISPs and PCs -meaning it wasn't just my ISP or my PC. Any chance this system could already be in place?

Re:Sooner? by Anonymous Coward · 2004-09-09 04:24 · Score: 0

Well, the linked mailing does claim it will go into effect 9 February 2004.

This is UNIX format, NOT International Date Format by dananderson · 2004-09-09 06:18 · Score: 1

The International Date Format, ISO 8601 is NOT being used. What's being used is the UNIX date, which wraps around in 2038 or so. They went from a semi-good YYYYMMDDNN to a less robust 7-digit number (seconds since 1970) that wraps around in 2038.

Re:"Emergency" use by SpaceLifeForm · 2004-09-09 06:33 · Score: 1

"We will be bringing most of the web down for maintenance starting in about 5 minutes."

--
You are being MICROattacked, from various angles, in a SOFT manner.

Good service. Awful UI. by solprovider · 2004-09-09 07:05 · Score: 1

Wow. I changed an MX record using Verisign's (NetworkSolutions.com) website about 30 minutes ago. I received an email through the new server 10 minutes later. I received email from the sender yesterday, so the MX record should have been cached at their company, and the MX record was changed from one ISP to another. I did not expect any results until sometime tomorrow.

---
I still use Verisign for my domains. It was inertia; I had my domains there, so I continued adding domains there.

I almost switched when they stole one of my domains. (I tried paying for it 5 times, starting several months before it expired; they insisted that the records would be updated "in a few days" each time. Three weeks after the expiration date, someone else owned it. So renew early! Like a year in advance.)

Setting DNS entries was a hassle. My ISP takes forever to make updates, and often set them wrong. I used Verio while waiting for my ISP to get it right. (I paid Verio for 6 months, and cancelled the service at 4 months. Verio stole money from me for the next 2 years. I complained each time. They stated they would stop. I finally changed the credit card number. Then Verio sent me another bill for a service I had not used in 2 years.)

I set up a BIND server just as Verisign offered to handle the DNS for free. I never used the BIND server; when I went to change my DNS servers, I noticed the new Verisign offering and just used that. It works great, but the interface is awful.

Verisign's interface for editing DNS for multiple domains is atrocious. To make a change:
0. Sign in.
1. Check next to one domain and click "Edit DNS".
2. Click "Continue" that you still want to use Verisign for your DNS.
3. Choose to edit your A records, or your MX records, or your CNAME records. Pick one and only one.
4. Edit the records, click Continue.
5. Click Continue again to confirm the changes.
6. Returned to screen #3 to choose the type of records. Choose a different type, or go back to the domain list (screen #1) and start over.

I would like a page that has all of my domains and DNS settings. They might need to have previous/next page buttons if you have more than 10 domains. Let me change several of the domains at one time. And remember that I am keeping my DNS settings there; why do I have to confirm (step #2) every time I look at the settings?

The Verisign DNS system works great if you are willing to use the poor interface. Can anybody report if other domain registrars have free DNS? How good are their interfaces?

--
I spend my life entertaining my brain.

Borked some DNS servers by Anne_Nonymous · 2004-09-09 11:55 · Score: 1

Interestingly, this borked some DNS servers at Qworst today.

Re:Borked some DNS servers by Anonymous Coward · 2004-09-09 17:43 · Score: 0

Qworst DNS servers are fundamentally borked anyway. Want proof? Set one of your domain's A records to a 5 minute TTL. Or heck, set the whole domain to a 5 minute TTL. Then query that A record via a Qworst resolver. Now go change your A record. Now wait 48 hours for Qworst to figure out that in spite of whatever TTL you use, they are smarter than you and you really don't want your A DNS changes to show up for two days.

Every time we do a DNS change our Qwest-DNS dependent customers pitch a fit over how "somebody broke something". We remind them that we would be happy to get them on an ISP that doesn't think little RFC-enshrined details like TTL values are irrelevant.

"US Worst is now Qworst!"

Oops by rs79 · 2004-09-09 13:19 · Score: 1

I responded to the title of this thread, which is incorrect, instead of the article. com and net servers are TLD servers, not ROOT servers.

I still claim to understand DNS even though at times I simply cannot read.

--
Need Mercedes parts ?

How Long to Setup a Website? by KidSock · 2004-09-09 13:33 · Score: 1

When I setup my little sister's website the registrar was pretty quick with their side. I think I had the domain and DNS records setup in ~2 hours. And it was a weekend. But of course those entries didn't propogate up and down to my ISP for ~48 hours. So that's a total of ~50 hours to conceive a site and have it running for the world to see. So will this be any different now?

Yikes by Compact+Dick · 2004-09-09 14:04 · Score: 1

Thanks, dananderson and jschrod for the correction. Much appreciated.

--
Use ISO 8601 dates [YYYY-MM-DD]

Wow, it only took them 3 years to catch up... by Anonymous Coward · 2004-09-09 15:15 · Score: 0

And they're still running thin registries. Afilias has been doing this with .info since 2001, and with .org since they got it in 2003. The news here is not that Verisign is doing it, but that it took them so long to get around to doing it.

Post didnt RTFA by Anonymous Coward · 2004-09-09 16:58 · Score: 0

Actually they arent going to update the zone more frequently - all they are doing is shifting the format of the SOA serial, and reducing the MINIMUM.

These changes are made in *preparation of* more frequent com and net updates.

Doesn't work at all by Anonymous Coward · 2004-09-12 08:50 · Score: 0

Just changed a domain. It's the 12th. It's been 2 hours. As usual, Slashdot reports some bit of technical tidbit type stuff without confirming. No wonder Windows continues to kick your arses.

Slashdot Mirror

Faster Updates for DNS Root Servers Arrive

150 comments