Faster Updates for DNS Root Servers Arrive

Tee Emm writes "VeriSign's DNS Rapid Update notice period (as announced on NANOG mailing list) expires today. Beginning September 9, 2004 the SOA records of the .com and .net zones will be updated every 5 minutes instead of twice a day. The format of the serial number is also changing from the current YYYYMMDDNN to a new one that depicts the UTC time." We first mentioned this back in July, but it's finally launching now.

Comments

dynamic dns

[Anonymous Coward]

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

Re:dynamic dns

[numbski]

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.

Re:dynamic dns

[two-tail]

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.

hmm, but is this really a good thing?

[The Pi-Guy]

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?

[Mordac the Preventer]

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.

Re:hmm, but is this really a good thing?

[LiquidCoooled]

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.

Re:hmm, but is this really a good thing?

[Entrope]

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?

[SirCyn]

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!

Re:hmm, but is this really a good thing?

[Kishar]

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)

Root Servers...

[jmcmunn]

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

[jabley]

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.

Re:Emergency use

[LostCluster]

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.

In case of slashdot effect...

[bruceg]

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

International Date Format

[Compact Dick]

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