In a blog entry late last month, I briefly mentioned an issue with stub resolvers that naively send queries for AAAA records (the DNS record type for IPv6 addresses) but then pass the addresses to applications that can’t consume them, causing timeouts.  (I owe credit to Igor Gashinsky at Yahoo!, from whoseIETF presentation I learned about the issue.)  Here’s a little more on that subject.

Many popular web sites that support IPv6 today use separate domain names to point to their sites; witness www.v6.facebook.com and ipv6.google.com. That scheme won’t hold up over time, though.  As IPv6 becomes pervasive, companies won’t willingly slap protocol identifiers in front of their domain names:

-       “For IPv4 customers, go to www.facebook.com.

-       For IPv6 customers, go to www.v6.facebook.com.”

Read more...

With the imminent exhaustion of IPv4 address space and the U.S. government’s renewed push to implement IPv6, the protocol has been getting more press lately.  The government’s mandate requires Federal government agencies to implement IPv6 on external-facing resources by early next year.  That got me to thinking about what that means to DNS.

Clearly, the mandate—assuming I read it correctly, which may not be such a good assumption—would require Federal government agencies to set up name servers with IPv6 addresses (and the corresponding AAAA records), either by adding IPv6 addresses to existing name servers or by setting up wholly new IPv6 name servers.

Read more...

Our friends at The Measurement Factory just completed the 2010 DNS Survey, and we’ll release the complete results soon.  For those of you who just can’t wait, though, here’s a preview of some of the results.

One of our datasets was a large (i.e., millions of zones), random sample of subzones of .COM, .NET and .ORG.  Looking at the IP addresses of the authoritative name servers for these zones, we found that nearly 20% seem to have all of their authoritative name servers on the same network. (They’re on the same /24, at least—in some cases, of course, that might be multiple networks, but it’s relatively unlikely.)

This is an accident waiting to happen.  Some of you might remember the embarrassing DNS outage Microsoft suffered several years ago when a technician misconfigured a border router in Redmond:  Because all of their authoritative name servers were on a single network behind that router, users couldn’t resolve most Microsoft domain names for an extended period.  Don’t let that happen to you.

Read more...

Read more...

An hour or so ago, I tried to check a Wikipedia entry and my browser told me it couldn't find en.wikipedia.org.  Surely that's wrong, I thought, but pushed "Check Wikipedia" onto the stack and went on to something else.  Then, coincidentally, while searching for DNS-related news articles to inspire my next blog entry, I ran across this one from PC Magazine.  Turns out Wikipedia's European data center had an overheating problem that caused many of their servers to shut down in an act of self-preservation.  To shunt European traffic to their servers in Florida, they enacted their failure procedure, which modifies their DNS records.

Unfortunately, that failover mechanism was broken (they didn't specify how), and broken so badly that it interrupted DNS resolution for all Wikimedia sites globally.  While they quickly recognized and fixed the problem, it took as long as an hour for the corrected data to propagate because of TTLs.

Read more...