When you turn on IPv6 in your operating system, the web is going to get slower for you. There are several reasons for this, but today Iâ€™m talking about DNS. Every DNS lookup is 2-3x slower with IPv6.

What is the Problem?

The problem is that the current implementations of DNS will do both an IPv4 and an IPv6 lookup in serial rather than parallel. This is operating as-per the specification.

We can see this on Windows:

TIME EVENT

0 DNS Request A www.amazon.com

39 DNS Response www.amazon.com

39 DNS Request AAAA www.amazon.com

79 DNS Response www.amazon.com

<the browser cannot continue until here>

The â€œAâ€ request there was the IPv4 lookup, and it took 39ms. The â€œAAAAâ€ request is the IPv6 lookup, and it took 40ms. So, prior to turning IPv6 on, your DNS resolution finished in 39ms. Thanks to your IPv6 address, it will now take 79ms, even if the server does not support IPv6! Amazon does not advertise an IPv6 result, so this is purely wasted time.

Now you might think that 40ms doesnâ€™t seem too bad, right? But remember that this happens for every host you lookup. And of course, Amazonâ€™s webpage uses many sub-domain hosts. In the web page above, I saw more of these shenanigans, like this:

TIME EVENT

0 DNS Request A g-ecx.images-amazon.com

43 DNS Response g-ecx.images-amazon.com

43 DNS Request AAAA g-ecx.images-amazon.com

287 DNS Response g-ecx.images-amazon.com

Ouch â€“ that extra request cost us 244ms.

But thereâ€™s more. In this trace we also had a lookup for the OCSP server (an Amazonâ€™s behalf, for SSL):

TIME EVENT

0 DNS Request A ocsp.versign.com

116 DNS Response ocsp.versign.com

116 DNS Request AAAA ocsp.versign.com

203 DNS Response ocsp.versign.com

Ouch â€“ another 87ms down the drain.

The average website spans 8 domains. A few milliseconds here, and a few milliseconds there, and pretty soon weâ€™re talking about seconds.

The point is that DNS performance is key to web performance! And in these 3 examples, weâ€™ve slowed down DNS by 102%, 567%, and 75% respectively. Iâ€™m not picking out isolated cases. Try it yourself, this is â€œnormalâ€ with IPv6.

What About Linux?

Basically all of the operating systems do the same thing. The common API for doing these lookups is getaddrinfo(), and it is used by all major browsers. It does both the IPv4 and IPv6 lookups, sorts the results, and returns them to the application.

So on Linux, the behavior ends up being like this:

TIME EVENT

0 DNS Request AAAA www.calpoly.edu

75 DNS Response www.calpoly.edu

75 DNS Request A www.calpoly.edu

93 DNS Response www.calpoly.edu

In this particular case, we only wasted 75ms, when the actual request would have completed in 18ms (416% slower).

But Itâ€™s Even Worse

I wish I could say that DNS latencies were just twice as slow. But itâ€™s actually worse than that. Because IPv6 is not commonly used, the results of IPv6 lookups are not heavily cached at the DNS servers like IPv4 addresses are. This means that it is more likely that an IPv6 lookup will need to jump through multiple DNS hops to complete a resolution.

As a result, itâ€™s not just that weâ€™re doing two lookups instead of one. Itâ€™s that weâ€™re doing two lookups and the second lookup is fundamentally slower than the first.

Surely Someone Noticed This Before?

This has been noticed before. Unfortunately, with nobody using IPv6, the current slowness was an acceptable risk. Application vendors (namely browser vendors) have said, â€œthis isnâ€™t our problem, host resolution is the OSâ€™s jobâ€.

The net result is that everyone knows about this flaw. But nobody fixed it. (Thank goodness for DNS Prefetching!)

Just last year, the â€œHappy Eyeballsâ€ RFC was introduced which proposes a work around to this problem by racing connections against each other. This is an obvious idea, of course. I donâ€™t know of anyone implementing this yet, but it is certainly something weâ€™re talking about on the Chrome team.

What is The Operating Systemâ€™s Job?

All browsers, be it Chrome or Firefox or IE, use the operating system to do DNS lookups. Observers often ask, â€œwhy doesnâ€™t Chrome (or Firefox, or IE) have its own asynchronous DNS resolver?â€ The problem is that every operating system, from Windows to Linux to Mac has multiple name-resolution techniques, and resolving hostnames in the browser requires using them all, based on the userâ€™s operating configuration. Examples of non-DNS resolvers include: NetBIOS/WINS, /etc/hosts files, and Yellow Pages. If the browser simply bypassed all of these an exclusively used DNS, some users would be completely broken.

If these DNS problems had been fixed at the OS layer, I wouldnâ€™t be writing this blog post right now. But I donâ€™t really blame Windows or Linux â€“ nobody was turning this stuff on. Why should they shine a part of their product that nobody uses?

Lesson Learned: Only The Apps Can â€˜Pullâ€™ Protocol Changes

IPv6 deployment has been going on for over 10 years now, and there is no end in sight. The current plan (like IPv6â€™s break the internet day) is the same plan weâ€™ve been doing for 10 years. When do we admit that the current plan to deploy IPv6 is simply never going to work?

A lesson learned from SPDY is that only the applications can drive protocol changes. The OSâ€™s, bless their hearts, can only do so much and move too slowly to push new protocols. There is an inevitable chicken-and-egg problem where applications wonâ€™t use it because OS support is not there and OSes wonâ€™t optimize it because applications arenâ€™t there.

The only solution is at the Application Layer â€“ the browser. But that may be the best news of all, because it means that we can fix this! More to comeâ€¦