Introduction
The Internet has largely allocated all of the IPv4 addresses it has traditionally relied on, but because of clever work-arounds meant to “stretch” the currently available IPv4 address space, many people may not have been aware of that fact. Nonetheless, we all should be getting ready for the future of IPv6. Many people may already be using IPv6, they just may not know it.
In fact, you may already be using IPv6:
- Your home ISP may be offering you IPv6 connectivity by default
- Your home networking equipment may be automatically configuring itself to use that IPv6 connectivity, and
- Your computer’s operating system and applications may just use that IPv6 with no manual configuration required.
Let’s Test for IPv6 Connectivity
Given all that, IPv6 often “just works.” One easy way to check is by visiting a test site with your web browser. As shown in Figure 1, if you’re fully IPv6 enabled you’ll probably get a 10/10 score (addresses partially masked here for privacy):
On the other hand, if you’re NOT IPv6 enabled, you may see a 0/10 score like in Figure 2 (again, address and provider masked for privacy):
These examples were from two home Internet connections located in the USA. IPv6 is also becoming more common on mobile carriers, so you may also want to check your smart phone’s cellular/LTE/5G connectivity. For example, checking https://test-ipv6.com/ from an iPhone connected via T-Mobile’s 5G network in the USA, Figure 3 will show show us another perfect score:
Your connectivity may also vary if you’re running a VPN. For example, let’s test Opera’s free integrated VPN. Using an Opera VPN node from Europe, we saw 10/10 IPv6 connectivity (Figure 4):
On the other hand, using an Opera VPN node from Asia, we saw 0/10 connectivity (Figure 5):
“What About the Rest of the Internet? Can I ‘Go Everywhere’ If I’m On IPv6? What If a Website I Want to Visit Isn’t Doing IPv6 yet?”
Many of the most important parts of the Internet are already IPv6-enabled. Some other parts may not (yet) have IPv6 connectivity. The good news is that devices and/or your network service provider will generally automatically handle cases where there may be a “mismatch” – YOU WON’T NEED TO figure out whether a site is (or isn’t) IPv6-enabled.
In some instances, you will actually be “dual-homed,” with both IPv6 AND IPv4 connectivity. In other cases, there may be a network address translation device that’s transparently working on your behalf to bridge the two address families. Either way, it will work.
Investigating a Domain’s IPv6 Usage in Farsight DNSDB
Sites with IPv6 will have a “quad A” (“AAAA”) DNS record. Sometimes it’s easy to find them; other times you may need to work your way through a little indirection in order to get to the bottom of them. A straightforward example:
$ dnsdbq -r www.ietf.org/aaaa -S -k count
;; record times: 2011-08-06 22:26:24 .. 2013-11-18 18:29:30 (~2y ~104d)
;; count: 1024631; bailiwick: ietf.org.
www.ietf.org. AAAA 2001:1890:123a::1:1e
;; record times: 2023-06-12 20:21:47 .. 2023-11-01 17:30:43 (~141d 21h 8m)
;; count: 760677; bailiwick: ietf.org.
www.ietf.org. AAAA 2606:4700::6810:2c63
www.ietf.org. AAAA 2606:4700::6810:2d63
[etc]
The above example shows that the IETF has a quad A record directly defined for their home page.
What about other companies or brands that people interact with frequently? How about Apple, Inc.? Do they use IPv6? Let’s try using dnsdbq to find out (see https://github.com/dnsdb/dnsdbq):
$ dnsdbq -r www.apple.com/aaaa -S -k count
dnsdbq [2023-11-02 00:14:09]: API status: NOERROR (no results found for query.)
The reason why you don’t get any results in this case is not because Apple doesn’t use IPv6. Appearances notwithstanding, they actually do use IPv6, and we do see them doing so. Let’s go back to the “live” DNS for a second and use the dig command as a way to help see what’s going on. dig is a tool that reports on what’s happening in the “live” DNS:
$ dig www.apple.com aaaa
[...]
www.apple.com. 440 IN CNAME www.apple.com.edgekey.net.
www.apple.com.edgekey.net. 11437 IN CNAME www.apple.com.edgekey.net.globalredir.akadns.net.
www.apple.com.edgekey.net.globalredir.akadns.net. 858 IN CNAME e6858.dscx.akamaiedge.net.
e6858.dscx.akamaiedge.net. 20 IN AAAA 2600:1409:9800:987::1aca
e6858.dscx.akamaiedge.net. 20 IN AAAA 2600:1409:9800:992::1aca
[...]
So, in this case:
www.apple.com -->
www.apple.com.edgekey.net -->
www.apple.com.edgekey.net.globalredir.akadns.net -->
e6858.dscx.akamaiedge.net -->
[2600:1409:9800:987::1aca, 2600:1409:9800:992::1aca]
We can replicate chasing those CNAMEs in DNSDB, we just need to avoid explicitly asking for quad A records “right off the bat.”
We’ll limit our analysis time horizon to the last 90 days to avoid making the following example even longer and more complex than it already may appear to be:
$ dnsdbq -r www.apple.com -A90d
;; record times: 2015-11-09 22:35:31 .. 2023-11-01 22:20:23 (~7y ~358d)
;; count: 840222872; bailiwick: apple.com.
www.apple.com. CNAME www.apple.com.edgekey.net.Now we’ll “chase” the value we found for that CNAME. Unfortunately, we need to do that manually via another dnsdbq query:
$ dnsdbq -r www.apple.com.edgekey.net -A90d
;; record times: 2015-11-11 23:44:05 .. 2023-11-01 23:27:29 (~7y ~356d)
;; count: 854361512; bailiwick: edgekey.net.
www.apple.com.edgekey.net. CNAME www.apple.com.edgekey.net.globalredir.akadns.net.Now we’ll manually “chase” the value of THAT CNAME with another dnsdbq query:
$ dnsdbq -r www.apple.com.edgekey.net.globalredir.akadns.net -A90d
;; record times: 2021-02-23 22:38:12 .. 2023-11-01 23:27:57 (~2y ~251d)
;; count: 1570879352; bailiwick: akadns.net.
www.apple.com.edgekey.net.globalredir.akadns.net. CNAME e6858.dscx.akamaiedge.net.And finally, we’ll chase the value of yet one MORE CNAME via dnsdbq:
$ dnsdbq -r e6858.dscx.akamaiedge.net/AAAA -A90d -l0 -S -k last
;; record times: 2023-11-02 00:36:43 .. 2023-11-02 00:36:43 (1s)
;; count: 1; bailiwick: dscx.akamaiedge.net.
e6858.dscx.akamaiedge.net. AAAA 2600:1400:9000:282::1aca
e6858.dscx.akamaiedge.net. AAAA 2600:1400:9000:287::1aca
e6858.dscx.akamaiedge.net. AAAA 2600:1400:9000:296::1aca
e6858.dscx.akamaiedge.net. AAAA 2600:1400:9000:299::1aca
e6858.dscx.akamaiedge.net. AAAA 2600:1400:9000:29c::1aca
;; record times: 2021-06-29 15:53:06 .. 2023-11-02 00:36:42 (~2y ~125d)
;; count: 9; bailiwick: dscx.akamaiedge.net.
e6858.dscx.akamaiedge.net. AAAA 2600:1400:9000:296::1aca
e6858.dscx.akamaiedge.net. AAAA 2600:1400:9000:299::1aca
e6858.dscx.akamaiedge.net. AAAA 2600:1400:9000:29c::1aca
e6858.dscx.akamaiedge.net. AAAA 2600:1400:9000:29d::1aca
e6858.dscx.akamaiedge.net. AAAA 2600:1400:9000:29e::1aca
[etc]
It may have taken us a few more steps, but we were able to get to the final AAAA record for Apple.
Things to note:
- In an ideal world, DNSDB would automatically chase CNAMEs for you, just as
digautomatically does for “live” DNS queries - Unless/until that happens, we’ll need to chase CNAMEs manually via multiple DNSDB queries
- The color highlighting shown above is just meant to show how the output from one query becomes input for the next query
- In the final query we explicitly ask just for AAAA records. We normally will not KNOW we’re at the last query in a CNAME chain until we begin seeing “A” or “AAAA” records in our output; this time we “cheated” a little based on what
digshowed. - In the final query, there might be MANY different results, so we asked for up to a million results (dash lowercase ell zero),
and to see the results sorted in descending order by time (dash capitalSspace dash lowercasekspacelast)
Conclusion
The Internet Protocol version 6 (IPv6) was first introduced in 1995. Since the first World IPv6 Day in 2012, many large content providers and ISPs have steadily enabled IPv6 functionality across the Internet. It is entirely possible that you currently use IPv6 already, either on your home computers, at your work or school, or on your mobile devices when connected to a cellular data network.
We have shown that it is possible to look up live IPv6 addresses for domains using dig, as well as look up passively collected AAAA records inside of Farsight DNSDB. Readers with Farsight DNSDB access who want a little practice finding AAAA records (or chasing CNAMES) for some other domains in DNSDB could try evaluating:
microsoft.comnanog.orgyoutube.comdnsdb.infowww.bbc.co.ukwww.foxnews.comwww.cnn.comwww.umn.edu vs www.cs.umn.eduwww.amazon.com
Happy AAAA hunting!
