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 and Jason Fesler at Yahoo!, from whose IETF 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 holdup 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.
No, over the long term, both IPv4 and IPv6 addresses will be attached to the same domain name, and the client web browser, VoIP client,whatever will work out which one it wants.
In the near term, though, attaching both A and AAAA records to a single domain name can cause problems. Google estimates that about .078% of their visitors use stub resolvers that request AAAA records even though they cant actually reach the IPv6 addresses returned. .078% doesnt sound like much (unless you’re talking about adoption of DNSSEC — just kidding!), but to a Google or a Yahoo! its hundreds of thousands of users. And those users experience a timeout that Gashinsky and Fesler say can be between 21 and 186 seconds.
On World IPv6 Day, some of those big web properties are going to tickle this bug deliberately by attaching a AAAA record to their main domain name. And we’ll see just how big a problem this is.
As I said in my earlier blog posting, BIND now offers a mechanism that helps address this problem, though it can cause problems of its own. Two new named.conf substatements, filter-aaaa and filter-aaaa-on-v4, give administrators the ability to configure their name servers not to return AAAA records to queriers who send their queries over IPv4 — effectively, to lie to those queriers. This avoids the timeouts, of course, but what if the zone that contains the AAAA record is signed and the querier attempts to validate the answer? The legitimate NSEC record that covers the query says there is a AAAA record for the domain name. It’s easy enough to change the NSEC record, but what about generating a signature for that modified record?
Consequently, the filter-aaaa-on-v4 mechanism doesn’t rewrite answers that include DNSSEC records, such as RRSIG records. BIND lets you override even that sensible precaution, though.
Hopefully, World IPv6 Day will highlight the problem these stub resolvers cause and induce vendors to change their behavior quickly, so we won’t have to cope with the issue on a much larger scale as IPv6 takes off.
