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…