November will be an eventful month for the DNS and the Internet as a whole.
As storefront operators and infrastructure providers are preparing capacity for the holiday shopping season, low-level changes are occurring. This shift is partially due to adjustments to how Apple’s iOS and OSx interact with the DNS. Simply put, Apple is helping to push IPv6 to the forefront and the change will be felt by consumers and infrastructure providers alike.
The signal that things are going to change in the DNS was issued on on July 6, 2015. Apple announced on an IETF mailing list that they were going to explore the impact on their platform of implementing an IPv6 preference. David Schinazi described how they included an improved version of their implementation of “Happy Eyeballs” in iOS 9 and OSx El Capitan. After Apple’s announcement, we started to explore what this might mean for our customers—and their customers.
For our customers the first question was, “What will this do to query volumes?” To answer this, we need to dig into the implementation details of Happy Eyeballs.
Happy Eyeballs sounds either pleasant or creepy, but it’s actually just a technique designed to make the IPv4 to IPv6 transition easier. In the early days of IPv6, people noticed that some IPv6-capable systems made things much worse than just turning off IPv6. That meant that the transition to IPv6 would take longer and since the world was running out of IPv4, it was a bad thing to turn off IPv6. The poor experience was really evident to humans—“eyeballs” at screens—and the goal was to make them happy. Happy Eyeballs tries to prefer IPv6 connections to IPv4 connections, but will use an IPv4 connection if IPv6 isn’t working fast enough.
Let’s look at the steps in the name resolution process provided by Apple in the IETF post detailing their Happy Eyeballs implementation:
Step 1: The device will query its local DNS stub resolver for A (IPv4) and AAAA (IPv6) records. If the records are not in cache, then requests will be sent to a recursive resolver in succession starting with the AAAA record.
Step 2: If the first reply the device receives is a AAAA, then it will send out a v6 SYN immediately. If the first reply the device receives is an A record a 25ms timer is started, the device is essentially waiting for the AAAA. If the AAAA response is received before the 25ms timer finishes, the device advances to address selection (for details on address selection, refer back to this IETF link).
For recursive resolvers, the process as described means they will see twice as many queries from Apple devices if no records are cached on the device. For application developers and operations teams, this has implications for how TTLs (time to live) should be set to minimize latency and DNS query volume. For authoritative providers, such as Dyn, this means an increase in volume for both A and AAAA queries for customers relative to the TTL configured for their records. It also highlights the importance of recursive resolvers being able to properly cache NO DATA responses.
On September 16th, the new version of iOS started to roll out to the masses and on September 30, 2015, El Capitan was released. Sandwiched between these two dates on Thursday September 24, ARIN announced that the pool of free IPv4 addresses had run dry; further increasing the perceived need to implement IPv6. The number of AAAA queries we receive has been steadily increasing over time, especially in Europe. Over the past year our platform has seen a 41% increase in AAAA requests. There was approximately a 5% increase between the end of September 2015 and the beginning of October alone.
One thing we noticed during our exploration of the differences between IPv4 and IPv6 was the variation in traffic engineering between the two protocols. To test this difference we made use of Dyn’s global anycast network. We used probes from fixed points try to talk to the IPv4 and IPv6 addresses which are all announced from the same places. Testing in Australia showed that the IPv4 probe would be routed to our Australian data center, whereas the IPv6 probes were being routed to Los Angeles and Sunnyvale, California. These differences in how the traffic crosses the Internet showed up all around the world from South America and Asia Pacific to the Europe and North America.
If you didn’t immediately stop reading and rush off to check the TTLs on your key resource records and verify your IPv6 deployment, here are a few clarifying questions to help you do so.
- How often do you need to change the records in your zone?
- Does your current TTL setting reflect this?
- Do you currently support IPv6?
- If so, do you understand how changes in IPv6 routing might impact where your traffic is going?
- Do you have AAAA records configured and are their TTLs in line with those of your A records?
- If you aren’t using IPv6, have you thought about the negative caching semantics and the impact on your end users and authoritative DNS query volume?
- If you aren’t using IPv6, have you thought about what will happen when customers wait longer for your website than for your competitor’s? What about when people only have IPv6 and can’t reach you?
The change in default behavior pushed forward by Apple gives everyone operating Internet services reason to review their current IPv6 readiness. This change impacts not only your outward facing infrastructure but your internal infrastructure. Deploy 360 and RIPE have drafted some IPv6 readiness documents for HelpDesk personnel and there are also tools like http://test-ipv6.com/ to help you along your way. Just remember, it’s usually easier to embrace the change and evolve with it than to catch up later.