On DNS and IPv6
Recently I’ve been repaying some tech debt I had built up at home. I’ve been sorting out old files, arranging automated off-site backups, committing uncommitted files to git (including finally getting myself some private git hosting), simplifying config, upgrading Debian, upgrading my Internet connection, and adding IPv6 support to my home network. It’s been a fun few weeks, actually.
The last one is interesting: adding IPv6. What does “add IPv6” really mean, and why should we do it?
Say “AAAA”
Assuming you’ve already got a working IPv4 setup, then adding IPv6, at its simplest level, is:
- ensure each host or service has an IPv6 address;
- ensure those IPv6 addresses are discoverable via DNS, by adding “AAAA” records.
Back in January 2011, there was “World IPv6 Day”: some big names (Google, Facebook, and quite a few others) temporarily added IPv6 addresses to their systems, and added “AAAA” records to DNS: just for a day, to see what happened. In essence, it was successful: some of their visitor traffic was carried over IPv6, and nothing broke. Then, in June 2012, there was “World IPv6 Launch Day”: basically the same again, but with more participants (e.g. Wikipedia), and this time the configuration wasn’t removed afterwards: it was left in for good.
Because I’ve recently been adding IPv6 to my little part of the Internet, I’ve been repeating the exercise myself. Once I’d got myself an IPv6 allocation, and my home network was handing out IPv6 addresses, I could “ping6 google.com”, for example. I’d solved the first part: adding addresses. Now for the second: discoverability in DNS.
Servers and Nameservers
First, the easy part: each of my servers has an “A” (IPv4) record in my DNS records, so that the server can be found without having to remember IPv4 addresses. So all I had to do was add corresponding “AAAA” (IPv6) records. One quick visit to my provider’s DNS control panel later, and that’s that job done: I can now resolve my server name to an IPv6 address, and thus connect to it. So, for example, “ssh -6 myserver.rachelevans.org.uk.” now works.
This is where things start to go downhill a bit.
What did we just do here? I allowed my server to be addressed via IPv6, and I added its IPv6 address to DNS.
Does that mean that, if had an IPv6 Internet connection and didn’t have an IPv4 connection, I could connect to my server? No, it doesn’t. At this point, I’m still dependent on IPv4.
To understand why, we need to understand a little more about how DNS works.
Zones and Referrals
To resolve a computer name to an IP address, we use DNS. It’s a distributed system, whereby lookups start at the “root” zone, and each zone can delegate authority to sub-zones. For example, “.com” is a sub-zone of the root, and “example.com” is a sub-zone of “.com”. Each zone has a set of nameservers.
Fundamentally, the problem is this: for DNS lookups over IPv6 to be successful, each zone has to provide at least one nameserver with an IPv6 address, and those IPv6 addresses have to be in DNS — otherwise that zone will be inaccessible to the IPv6 Internet.
(Exactly the same thing is true of IPv4, by the way: if none of a zone’s nameservers have IPv4 addresses, that zone won’t be accessible to the IPv4 Internet. However, so far everyone seems to get it right for IPv4, so it’s less interesting).
So for our web site to be reachable to clients purely via IPv6, what do we have to do?
Say our web site is www.example.com, and our DNS zone is example.com. So we have to:
- give our server an IPv6 address;
- add an entry mapping its name to its IPv6 address as an “AAAA” record, in our DNS zone;
- ensure our nameservers are reachable via IPv6.
How exactly do we do the last step? Simple: we repeat the whole process again. Say for example the nameservers of the example.com zone are ns1.big.hosting.co and ns2.big.hosting.co — we repeat the process for those two servers (or, more typically, we have to talk to the bighosting.co in question to check that they have already done this).
And then, in turn, bighosting.co itself has nameservers, and the whole process repeats.
An example
Back to what I was doing over Christmas: I was adding IPv6 support to my network, and then adding the IPv6 “AAAA” records to DNS. But, there’s no point doing that unless the nameservers are also reachable via IPv6, which got me to thinking about this whole area.
So I wrote a tool I called “dns-dependency-walker”: it analyses the DNS hosting of a given domain, and finds its dependencies, and analyses, them, and so forth. It then draws a directed acyclic graph illustrating the relationships between the various zones and nameservers involved.
For example, here’s the picture for rachelevans.org.uk:
(Nameservers or zones that are not reachable by IPv6 are shaded in grey. See my note to the side of the diagram for a detailed explanation.)
My domain is rachelevans.org.uk, so I depend upon the parent zones, org.uk, uk, and the root. The nameservers of my zone are in the domain buddyns.com, so I’m dependent upon that zone too. In turn, buddyns.com is dependent upon the .com zone. And so forth.
The moral of the story is: the success of your IPv6 support could depend on more than you might expect.
Let’s do this!
So back to World IPv6 Launch Day. Their web site lists the companies that participated, adding support for IPv6.
Let’s pick a few of the big names and see how they’re doing.
Akamai
Not all of akamai.com’s nameservers support IPv6, but overall, it’s reachable. So far so good.
Microsoft
Slightly better for microsoft.com: all of that zone’s nameservers support IPv6. It doesn’t matter that some of the zones that they depend on have some IPv4-only nameservers, because they also have IPv6-capable nameservers. So again, the result is: it’s reachable.
Here’s where it starts to go wrong. Although www.facebook.com does indeed have an IPv6 address, the facebook.com zone’s nameservers don’t. So if you, or more specifically your DNS resolver, don’t have an an IPv4 address, then you can’t find out what www.facebook.com’s IPv6 address is — therefore you can’t connect.
Exactly the same situation at Google: www.google.com does indeed have an IPv6 address, but you can’t find it without an IPv4 address, because none of the google.com nameservers have IPv6 addresses.
Cisco
At first glance, Cisco appears to have the same problem as Facebook and Google — lack of IPv6 addresses on the nameservers. But actually, it’s a bit more complicated.
The nameservers do have IPv6 addresses, as we can see from this query:
rachel@dudley ~$ dig +short aaaa ns1.cisco.com
2001:420:1101:6::a
rachel@dudley ~$ dig +short aaaa ns2.cisco.com
2001:420:2041:5000::a
So what have Cisco got wrong, exactly?
The answer lies in DNS “glue” records: whenever the name of a DNS server (“ns1.cisco.com”) lies within the zone that that same server is trying to serve (“cisco.com”), you have to add the nameserver’s IP addresses — the “A” and “AAAA” records — to the parent zone. These are called “glue” records.
Here’s microsoft, getting it right (for the domain where their nameservers live, msft.net):
rachel@dudley ~$ dig @a.gtld-servers.net. a www.msft.net.
;; QUESTION SECTION:
;www.msft.net. IN A;; AUTHORITY SECTION:
msft.net. 172800 IN NS ns3.msft.net.
msft.net. 172800 IN NS ns1.msft.net.
msft.net. 172800 IN NS ns2.msft.net.
msft.net. 172800 IN NS ns4.msft.net.;; ADDITIONAL SECTION:
ns3.msft.net. 172800 IN A 193.221.113.53
ns3.msft.net. 172800 IN AAAA 2620:0:34::53
ns1.msft.net. 172800 IN A 208.84.0.53
ns1.msft.net. 172800 IN AAAA 2620:0:30::53
ns2.msft.net. 172800 IN A 208.84.2.53
ns2.msft.net. 172800 IN AAAA 2620:0:32::53
ns4.msft.net. 172800 IN A 208.76.45.53
ns4.msft.net. 172800 IN AAAA 2620:0:37::53
The response tells us which servers handle the zone msft.net, and then also tells us their IPv4 and IPv6 addresses.
By way of contrast, here’s Cisco getting it wrong:
rachel@dudley ~$ dig @a.gtld-servers.net. a www.cisco.com.
;; QUESTION SECTION:
;www.cisco.com. IN A;; AUTHORITY SECTION:
cisco.com. 172800 IN NS ns1.cisco.com.
cisco.com. 172800 IN NS ns2.cisco.com.;; ADDITIONAL SECTION:
ns1.cisco.com. 172800 IN A 72.163.5.201
ns2.cisco.com. 172800 IN A 64.102.255.44
The response includes the IPv4 addresses of the nameservers, but not the IPv6 addresses. (The cisco.com zone does contain the nameservers’ IPv6 addresses, but that’s no use unless you can find the nameservers in the first place).
Why have these big companies not got it right yet?
So with all of this — multiple dependencies between zones and nameservers, referrals, glue records — does that mean that adding IPv6 support in DNS is somehow hard? That is, harder than IPv4?
Not at all —when it comes to DNS, the rules for IPv6 are exactly the same as they are for IPv4.
So why do so many companies — even the ones who promoted World IPv6 Launch Day, back in 2012 — get it wrong? What exactly was the point of it all?
To answer that, let’s consider the following scenarios:
If everyone on the Internet has an IPv4 address already, is there any benefit to me if I add IPv6? Well, a little: addressability without NAT, for example.
But, what if not everyone on the Internet has an IPv4 address — what if some only have an IPv6 address? Is the result just that they can’t find a lot of sites (including Google, Facebook, etc) because they can’t get the DNS lookups to work?
Maybe. But there is a mitigating factor.
Often, if your computer (PC/laptop/phone) needs to do a DNS lookup, it won’t do the full lookup itself — rather, it’ll ask another computer to do it. Internet Service Providers will often provide such a service, technically called a Recursive Resolver or Full Resolver (but often lazily, and confusingly, called just a DNS Server). As long as your computer can reach that one using IPv6, and as long the Resolver does have an IPv4 address, then that also works. In other words: your computer might be able to manage without an IPv4 address, as long as it can reach a Resolver that does have one. But that’s a hack.
But what if even the DNS Resolver doesn’t have an IPv4 address? Well, then you’re out of luck: you’ll only be able to find those servers whose DNS zones are reachable via IPv6; and additionally, you’ll only be able to see those web sites where the web site itself also has IPv6.
If either piece of the puzzle is missing, you miss out.
Why IPv6?
So back to my original questions: What does “add IPv6” really mean, and why should we do it?
Adding IPv6 isn’t just assigning an IPv6 address, then bunging that it DNS.
It is ensuring that you support IPv6 at least to parity with IPv4, and ensuring that all the services that you depend on (usually provided by other companies and vendors) do the same.
Adding IPv6 in parallel with IPv4 does add some value in and of itself; but as you’ll probably have heard, one of the big selling points behind IPv6 is that IPv4 addresses have run out (or “will soon run out”, depending on your definition), and when we’re out of IPv4 address, newcomers to the Internet will only get IPv6.
The key reason therefore to add IPv6 support is for the benefit of people in the future. Increasingly, the IPv6 Internet will be the Internet, and as more and more of the people that you want to talk to are on IPv6, you’ll be cutting yourself out of the picture if you haven’t joined the party yet.
Some of the efforts so far to encourage IPv6 adoption have, perhaps necessarily, omitted some of the technical details. Companies have declared “We’re on IPv6,” without really telling us what they mean — perhaps because they themselves didn’t know.
Testing, Testing, IP 6
As you add IPv6 support to your Internet presence — your web site, email systems, and so forth — it’s highly advisable to check that it’s reachable even to people without IPv4.
Set yourself up a test area, on its own Internet connection, only with IPv6. Make sure you don’t use your ISP’s (or corporate) DNS Resolver service – because if you do, you might accidentally be depending on IPv4 without realising it. Reboot all the devices in the test area, to clear any DNS caches.
Congratulations: you’ve weaned yourself off of IPv4. Now, can you still access your web site? Can you still communicate with your company via email?
If you can, you’re way ahead of the curve. Welcome to the future.
