Slashdot Mirror
Verisign Plans DNS Changes
NetWizard writes "According to a recent NANOG post and an InfoWorld story, 'Verisign will change the serial number format and "minimum" value in the .com and .net zones' SOA records on or shortly after 9 February 2004'. They seemed to have learned their lesson, from the post: '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.)'"
No-one cares what format the serial number is in, except those who have written software that relies on the current format (in disobedience of the RFCs...)
A serial number is just a 32-bit number, and is used to see if a domain has been updated. The specs. do not say anywhere that it should be in a specific format.
"Elmo knows where you live!" - The Simpsons
I'm not someone at Verisign, but I am willing to suggest possible logic in this change.
The previous format, YYYYMMDDNN (where NN is an arbitrary sequence number), conforms to no standard but its own. The UNIX timestamp format is recognised by any date/time manipulation tool worth using, as well as being a standard (de facto or otherwise, I don't know). While switching format now is a PITA for those who have already written tools that work with it, it will make future development fractionally easier, as well as allowing more accuracy than could practically be used.
Then again, they could just leave things alone.
RTFA...
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.
No, it isn't offtopic if you had RTFA. 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.)
The above isn't meant as an excuse, just an explanation as to why this will undoubtly break someone's something. Then you get back to the old 'change is good' but not if it causes trouble, then 'change is bad'[tm]. At some point we're going to have to make big changes to the infrastructure and things will break regardless of compatability. we might as well get used to it (though as always, having a decent explanation wouldn't be a bad thing[tm])
[Fuck Beta]
o0t!
They will be changing their serial number from about 2004020900 to something about 1075680000 which according to the DNS system will be an older serial number because the difference is only 928340900 which is much less than half the range of a 32 bit number. They can make the change that they are planning if they make two changes with at least their cache interval amount of time between the changes. See RFC-1034.
2038 is a valid concern. But if DNS servers compare serial numbers according to RFC 1982 it is not going to be a problem.
Do you care about the security of your wireless mouse?
I got your international standard right here.
YYYY-MM-DD and YYYYMMDD are both standards-compliant.
Seriously, if you've never heard of this standard, read up. Whenever I need to stick a date or a time on something in text form, I just do it the ISO 8601 way.
Thirty-two (32; I'm supposed to always write out numbers at the beginning of sentences according to an English style guide -- I'm trying to make Slashdot educational or something, heh) bit signed "seconds since 1/1/1970" break in 2038, yes. Sixty-four (64) bit signed "seconds since 1/1/1970" have a really really long time before they break. By 2038 we (define we to whatever you want) will have had ample time to switch to 64 bit values and/or platforms (if POSIX doesn't interfere, it can be done on native 32 bit platforms as well).
Part of an older meaning for hacker was someone who fixes things that aren't broken. Verisign has hackers working on this one. We don't use YYYYMMDDHHSS for serials, we use an increasing serial maintained by a script that does not contain an overloaded date meaning. If you want the serial to be the number of seconds since beginning of an epoch, then change the RFC through normal means, not by some corporate edict. Hackers they are, in the old sense.
Because if you weren't, you would be saying that if your ISP has 10,000 customers, and they all ran their own caching nameservers, and all of them decide to resolve "www.google.com", then the root nameservers wouldn't really be hit with 10,000 times as many queries as if all of your little servers were properly configured.
There are two reasons to query the root nameservers directly:
That's it. Hitting them directly for routine queries is wasteful, inconsiderate, and expensive. If you weren't joking: fix your configuration. Now.
Dewey, what part of this looks like authorities should be involved?
It appears that they are gearing up to start providing far more than two updates per day. This could mean that sometime in the future you could register a new domain name and have it up and running within 15-30 minutes.
Seems like a positive change to me.
Natural != (nontoxic || beneficial)
It does not matter how many bits your computer has, it matters if the DNS protocol is still in use by then.
If it is, it will break because of this change. The older timestamp format had a much longer lifetime.
Of course there will be major problems in 2038, probably much worse than in 2000. This small issue will not contribute too much.
Third reason:
now we need to go OSS in diesel cars
You clearly don't understand how DNS works. This change in no way requires a new zone 96 times a day. The TTL field is used by client accessing the zone to understand when they need to stop caching the retrieved data. Verisign could have a TTL of 15 minutes and never change the serial number, and nothing would break.
In a word: yes.
Since their upstreams are major Tier 1 providers like UUNet, Qwest and Sprint, presumably my ISPs nameservers are the cause of untold THOUSANDS of unncessary queries against the root nameservers that could easily be satisfied by the caches at UUNet, Qwest and Sprint.
If your ISP is well-managed, then they query their upstreams and not the root nameservers.
I don't plan on changing my config, thanks. I don't have reason to believe my ISPs DNS is more reliable or more secure against poisoning than my server is,
Don't thank me for your wasted resources. I have one reason to think that your ISP runs a better DNS service than you do: we don't know that they have mis-configured servers.
nor do I particularly buy into the idea this is wasteful or expensive; the root servers are THERE to provide NS records for finishing queries.
Wrong again. They are there to provide NS records to the highest tier of the DNS caching hierarchy, not every little personal system on the Internet.
Dewey, what part of this looks like authorities should be involved?
If your ISP is well-managed, then they query their upstreams and not the root nameservers.
.NET NS is cached from the root servers, it is cached the same for a Tier 1 ISP or a Tier 2, and it doesn't have to be done again. The root nameservers are able to handle the .NET, .COM, .US, etc. lookups just fine. Even the next-level .NET, .COM, .US nameservers are multi-homed and anycast globally and able to handle a huge load. There is no reason to risk problems with an upstream ISP vs. going right to the source for an NS record lookup. Once the NS info is cached for a TLD like msn.com, it's the msn.com NS servers (and the hundreds of thousands (?) of other TLD NS servers) that can each handle their own load just fine.
That's simply not true. Customers should use their ISP's DNS server, but I don't believe ISP's should ever be forwarding queries upstream. That's just asking for problems. ISP's buy wholesale bandwidth, not services like mail forwarding or DNS forwarding (not that one couldn't do it, but it is asking for an extra level of troubleshooting and delay).
Once a lookup to the
It's all meant to scale without having needless delay or problems introduced by forwarding queries to a DNS server you cannot control.
Perhaps you can point to an RFC that says Teir2/3 ISPs should forwad DNS queries to upstream providers? Nope, thought not, not even a best practice.