A couple of weeks ago, I posted an article about slow IPv6 DNS query performance. Several readers suggested in the comments that my observations were isolated to a few bad implementations and that perhaps Mac and Linux systems were not prone to this. I hoped they were right, but I now have data to show theyâ€™re wrong.
Measuring performance is routine in Chrome, so a couple of days ago I was able to add a simple test to measure the speed of pure IPv4 lookups (A record) vs IPv6 lookups (A + AAAA records). Today, with hundreds of millions of measurements in hand, we know the impact of IPv6 on DNS.
Windows users face a ~43% DNS latency increase and Mac users face a 146% DNS latency increase when they install an IPv6 client-side address on their machines.
Today, there are two basic approaches to the IPv6 lookup problem: you can issues the requests in serial or in parallel. Obviously, issuing in serial will be more latency impacting than doing them in parallel. But, even issuing them in parallel will be slower, as the maximum latency of two samples along a normal curve will be lower than the average latency of a single sample along the same curve.
Some readers may argue that these are dominated by older implementations. Further investigation into the data does not confirm this. Even comparing the fastest 10% of Mac or Windows users (which should hopefully be using the best DNS resolver algorithms available) are seeing greater than 100% DNS lookup latency increases with IPv6. Of course, we have conflation here, as DNS server response times may be slower in addition to the DNS client double-lookup being slower. A deeper study about why these results are so bad is warranted.
Performance-sensitive users should be cautious about assigning a global IPv6 address on their clients. As soon as they do, the browser will switch into IPv6 lookup mode, and take on a 40-100% increase in DNS latency.