Introduction
In this lab, you will learn the essential skills to perform and verify IPv6 DNS lookups on a Linux system. You will explore how Linux systems resolve domain names to IPv6 addresses, a critical function for modern networking. This hands-on experience will guide you through using standard command-line utilities to query for IPv6 address records and test network connectivity.
You will begin by inspecting the /etc/resolv.conf file to identify the configured DNS servers. Next, you will use two powerful tools, dig and nslookup, to specifically query for AAAA records, which map domain names to IPv6 addresses. Finally, you will use the ping6 command to confirm that your system can establish a direct connection to a target using its IPv6 address, completing the full cycle of resolution and connectivity.
Inspect DNS Server Configuration in /etc/resolv.conf
In this step, you will locate and inspect the DNS server configuration on your Ubuntu system. This is the foundational step to understanding how your machine resolves domain names into IP addresses, which is essential for all network communication, including IPv6.
The primary configuration file for DNS resolution on Linux is /etc/resolv.conf. This file lists the IP addresses of the nameservers your system will query.
First, let's view the contents of this file. In your terminal, which is already open and in the ~/project directory, run the following command:
cat /etc/resolv.conf
This command reads the file /etc/resolv.conf and displays its content directly in the terminal.
You should see one or more lines starting with nameserver. These entries define the DNS servers. The addresses can be either IPv4 (e.g., 8.8.8.8) or IPv6 (e.g., 2001:4860:4860::8888). Identifying these servers is the first step in diagnosing any DNS-related issues.
Example Output:
## Dynamic resolv.conf(5) file for glibc resolver(3) generated by resolvconf(8)
## DO NOT EDIT THIS FILE BY HAND -- YOUR CHANGES WILL BE OVERWRITTEN
## 127.0.0.53 is the systemd-resolved stub resolver.
## run "systemd-resolve --status" to see details about the actual nameservers.
nameserver 127.0.0.53
options timeout:2 attempts:3 rotate single-request-reopen
In the example above, the system is configured to use the systemd-resolved stub resolver at 127.0.0.53. This is a local DNS resolver that forwards requests to the actual DNS servers configured for your system. You can run systemd-resolve --status to see details about the actual nameservers being used. If your system were configured for IPv6 DNS, you would see an IPv6 formatted address here.
By completing this step, you now know how to find the DNS servers your system relies on for name resolution. In the next step, you will use a command-line tool to actively query one of these servers for an IPv6 address record.
Query for an IPv6 AAAA Record with dig
In this step, you will use the dig command-line tool to query a DNS server specifically for an IPv6 address record. While the A record maps a domain name to an IPv4 address, the AAAA record (or "quad-A" record) maps a domain name to an IPv6 address.
The dig (domain information groper) utility is a powerful and flexible tool for interrogating DNS servers. It is part of the dnsutils package, which may not be installed by default.
First, let's ensure dig is available on your system. Run the following commands to update your package list and install dnsutils:
sudo apt-get update
sudo apt-get install -y dnsutils
Now that dig is installed, you can use it to look up the AAAA record for a domain that is known to be IPv6-enabled, such as ipv6.google.com.
Execute the following command in your terminal:
dig AAAA ipv6.google.com
This command tells dig to search for records of type AAAA for the domain ipv6.google.com.
Let's examine the output. It is divided into several sections, but the most important one for us is the ANSWER SECTION.
Example Output:
; <<>> DiG 9.18.1-1ubuntu1.3-Ubuntu <<>> AAAA ipv6.google.com
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 35612
;; flags: qr rd ra; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 1
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 65494
;; QUESTION SECTION:
;ipv6.google.com. IN AAAA
;; ANSWER SECTION:
ipv6.google.com. 10 IN CNAME ipv6.l.google.com.
ipv6.l.google.com. 10 IN AAAA 2607:f8b0:4005:814::200e
;; Query time: 148 msec
;; SERVER: 127.0.0.53#53(127.0.0.53) (UDP)
;; WHEN: Thu Jul 17 10:56:59 CST 2025
;; MSG SIZE rcvd: 93
In the ANSWER SECTION, you can see that ipv6.google.com first resolves to a CNAME record pointing to ipv6.l.google.com, which then resolves to an IPv6 address (e.g., 2607:f8b0:4005:814::200e). The presence of both the CNAME and AAAA records confirms that ipv6.google.com has an IPv6 address and your system was able to successfully resolve it.
You have now successfully used dig to perform a specific IPv6 DNS lookup. In the next step, you'll learn how to do the same thing with another common utility, nslookup.
Look Up an AAAA Record Using nslookup
In this step, you will learn to use another common utility, nslookup, to perform the same task of querying for an AAAA record. While dig is often preferred by system administrators for its detailed output, nslookup is also widely available and useful for quick lookups.
The nslookup (name server lookup) tool is also part of the dnsutils package, which you installed in the previous step, so you don't need to install anything new.
To ask nslookup to find a specific type of record, you use the -query= option. We will again look for an AAAA record to find a domain's IPv6 address. Let's use a different IPv6-enabled domain this time, such as facebook.com.
In your terminal, execute the following command:
nslookup -query=AAAA facebook.com
This command instructs nslookup to specifically request the AAAA record for facebook.com from the default DNS server.
The output from nslookup is typically more concise than dig. Look for the "Non-authoritative answer" section.
Example Output:
Server: 127.0.0.53
Address: 127.0.0.53#53
Non-authoritative answer:
Name: facebook.com
Address: 2a03:2880:f131:83:face:b00c:0:25de
The output clearly shows the IPv6 address associated with facebook.com under the "Non-authoritative answer" section. The term "Non-authoritative" simply means the answer came from a DNS server that is not the ultimate authority for the domain, which is normal for recursive DNS queries.
You have now successfully used two different tools, dig and nslookup, to resolve a domain name to an IPv6 address. In the final step, you will test actual network connectivity using one of these resolved domains.
Test IPv6 Connectivity with ping6
In this final step, you will combine DNS resolution and network testing to verify end-to-end IPv6 connectivity. After successfully resolving a domain name to its IPv6 address in the previous steps, you now need to check if your system can actually communicate with that address over the network.
To do this, you will use the ping6 command. This utility is the IPv6 equivalent of the familiar ping command and is used to test network reachability by sending ICMPv6 echo request packets to a target host.
When you provide ping6 with a domain name, it performs two actions:
- It first resolves the domain name to an IPv6 address by querying for its
AAAArecord. - It then sends ping packets to the resolved IPv6 address.
Let's test connectivity to ipv6.google.com. We will use the -c 4 option to send only 4 packets and then stop; otherwise, ping would run indefinitely.
In your terminal, execute the following command:
ping6 -c 4 ipv6.google.com
Observe the output. If your system has a working IPv6 connection to the internet, you will see successful replies.
Example of Successful Output:
PING ipv6.google.com(prg03s07-in-x0e.1e100.net (2a00:1450:4001:82e::200e)) 56 data bytes
64 bytes from prg03s07-in-x0e.1e100.net (2a00:1450:4001:82e::200e): icmp_seq=1 ttl=118 time=1.23 ms
64 bytes from prg03s07-in-x0e.1e100.net (2a00:1450:4001:82e::200e): icmp_seq=2 ttl=118 time=1.30 ms
64 bytes from prg03s07-in-x0e.1e100.net (2a00:1450:4001:82e::200e): icmp_seq=3 ttl=118 time=1.25 ms
64 bytes from prg03s07-in-x0e.1e100.net (2a00:1450:4001:82e::200e): icmp_seq=4 ttl=118 time=1.28 ms
--- ipv6.google.com ping statistics ---
4 packets transmitted, 4 received, 0% packet loss, time 3005ms
rtt min/avg/max/mdev = 1.230/1.265/1.300/0.027 ms
Expected Output in Most Lab Environments:
ping6: connect: Network is unreachable
Important Note: In LabEx VM, you will likely see "Network is unreachable" when attempting to ping IPv6 addresses. This is because the lab environment can resolve the IPv6 address but does not have an IPv6 route to the public internet. This common scenario, known as the "IPv6 gap," demonstrates the crucial difference between successful DNS resolution and actual network connectivity. The fact that DNS resolution worked in the previous steps but connectivity fails here illustrates that your system can properly query for and receive IPv6 addresses, even when it cannot establish actual IPv6 connections.
Congratulations! You have completed this lab. You have learned how to inspect your local DNS configuration, use dig and nslookup to query for IPv6 AAAA records, and use ping6 to test for IPv6 connectivity.
Summary
In this lab, you learned the fundamental steps for performing IPv6 DNS lookups in a Linux environment. You started by inspecting the /etc/resolv.conf file to identify the DNS servers your system is configured to use. You then practiced using two essential command-line utilities, dig and nslookup, to specifically query for IPv6 AAAA records, successfully resolving domain names to their corresponding IPv6 addresses.
Finally, you used the ping6 command to test IPv6 connectivity, which demonstrated the important distinction between DNS resolution and actual network connectivity. Even though the lab environment can successfully resolve IPv6 addresses, it lacks IPv6 routing to the public internet, resulting in "Network is unreachable" errors. By completing these steps, you have gained hands-on experience with the core tools and concepts for managing and troubleshooting IPv6 name resolution on Linux, and understand the difference between successful DNS queries and actual network connectivity.
