
What is an AAAA record and how does IPv6 DNS work?
An AAAA record (pronounced "quad-A") is a DNS record that maps a hostname to an IPv6 address, such as 2001:db8:10::1. It's the IPv6 equivalent of the A record, which holds an IPv4 address. IPv6 DNS works in much the same way as IPv4 DNS: a device that wants to connect to www.example.com asks its resolver for the AAAA record as well as the A record, and if it has working IPv6 connectivity and gets an AAAA answer, it usually tries the IPv6 address first, falling back to IPv4 quickly if that fails. Publishing an AAAA record lets visitors on IPv6 networks, which today make up a large and growing share of internet users, reach your site natively.
The name comes from the size of the address. An IPv4 address is 32 bits, and an IPv6 address is 128 bits, four times as long, hence four A's. This article explains what an AAAA record contains, how IPv6 addresses are written, how clients decide between IPv4 and IPv6, how IPv6 fits into the wider DNS system, how to add and test AAAA records safely, and the mistakes that cause IPv6 visitors to see a broken site.
What an AAAA Record Looks Like
An AAAA record has the same structure as any other DNS record, with a 128-bit IPv6 address as its data:
www.example.com. 3600 IN AAAA 2001:db8:10::1
You can look one up with dig by asking for the AAAA type:
dig www.example.com AAAA +noall +answer
www.example.com. 3600 IN AAAA 2001:db8:10::1
Most sites that support IPv6 publish both record types for the same name, a setup known as dual stack:
www.example.com. 3600 IN A 192.0.2.10
www.example.com. 3600 IN AAAA 2001:db8:10::1
A and AAAA records are completely independent. You can have one, the other, or both, and you can have several of each for the same name.
A Quick Guide to IPv6 Addresses
IPv6 addresses are written as eight groups of four hexadecimal digits, separated by colons:
2001:0db8:0010:0000:0000:0000:0000:0001
Two rules make them shorter:
- Leading zeros in a group can be dropped:
0db8becomesdb8, and0010becomes10. - One run of consecutive all-zero groups can be replaced with
::: This can only be done once per address.
Applying both gives the familiar short form:
2001:db8:10::1
RFC 5952 recommends a canonical text form: lowercase letters, leading zeros removed, and :: used for the longest run of zero groups. DNS doesn't care which form you type into a dashboard, because the record stores the 128-bit value, not the text, but sticking to the canonical form makes records easier to compare.
A few ranges are worth recognising:
| Range | Meaning |
|---|---|
2000::/3 | Global unicast, the public addresses used on the internet |
2001:db8::/32 | Reserved for documentation and examples, never routed |
fc00::/7 | Unique local addresses, similar to private IPv4 ranges |
fe80::/10 | Link-local addresses, valid only on a single network segment |
::1 | The loopback address, equivalent to 127.0.0.1 |
64:ff9b::/96 | Well-known prefix used by NAT64 and DNS64 |
Only global unicast addresses belong in public AAAA records. Link-local and unique local addresses won't be reachable from the internet.
How Clients Choose Between IPv4 and IPv6
When an application on a dual-stack device looks up a name, the operating system typically asks for both A and AAAA records. What happens next is designed to make IPv6 the default without letting it slow anything down.
Address Selection
The operating system sorts the returned addresses according to a policy described in RFC 6724. On a device with working IPv6, global IPv6 addresses are generally preferred over IPv4. You can see the order your system produces with a short Python script:
import socket
for family, _, _, _, sockaddr in socket.getaddrinfo(
"www.example.com", 443, proto=socket.IPPROTO_TCP
):
label = "IPv6" if family == socket.AF_INET6 else "IPv4"
print(label, sockaddr[0])
On a dual-stack network the output might be:
IPv6 2001:db8:10::1
IPv4 192.0.2.10
On an IPv4-only network, the operating system usually doesn't return the AAAA results to the application at all, or places them last.
Happy Eyeballs
Preferring IPv6 would be a problem if a broken IPv6 path made users wait for a timeout before falling back. To prevent this, modern browsers and operating systems use Happy Eyeballs, specified in RFC 8305. The client:
- Sends the AAAA and A queries at the same time.
- Starts connecting over IPv6 as soon as it has an AAAA answer.
- If the IPv6 connection hasn't succeeded within a short delay, typically around 250 milliseconds, starts an IPv4 connection in parallel.
- Uses whichever connection completes first and abandons the other.
The result is that a site with a broken IPv6 setup usually still loads, just a fraction slower, which is precisely why IPv6 problems can go unnoticed for a long time.
How IPv6 Fits Into the DNS System
It's easy to assume that IPv6 lookups need IPv6 connectivity, but the record type and the transport are separate things.
The Query Type and the Transport Are Independent
You can ask for an AAAA record over an IPv4 connection to a resolver, and you can ask for an A record over IPv6. The record type describes the answer, not how the question travels. dig lets you choose the transport explicitly:
# Ask for an IPv6 address, sending the query over IPv4
dig -4 @1.1.1.1 www.example.com AAAA +short
# Ask for an IPv4 address, sending the query over IPv6
dig -6 @2606:4700:4700::1111 www.example.com A +short
Both work, as long as the network path to the resolver exists.
Nameservers Need IPv6 Addresses Too
For resolvers on IPv6-only networks to reach your domain, your authoritative nameservers need IPv6 addresses. Check whether yours have AAAA records:
dig example.com NS +short | xargs -I{} dig {} AAAA +short
2001:db8:53::1
2001:db8:53::2
All major managed DNS providers run their nameservers on both IPv4 and IPv6. If you run your own nameservers, give them AAAA records, and if they sit inside your own domain, make sure your registrar publishes IPv6 glue records for them.
DNS64 and NAT64
Some networks, notably many mobile networks, give devices only IPv6 connectivity. To let those devices reach IPv4-only sites, the network uses NAT64 together with DNS64, described in RFC 6147.
When a device on such a network asks for the AAAA record of an IPv4-only site, the DNS64 resolver synthesises one by embedding the site's IPv4 address in a special prefix, commonly the well-known prefix 64:ff9b::/96:
dig @2001:db8:64::53 ipv4only.example.com AAAA +short
64:ff9b::c000:20a
Here c000:20a is the hexadecimal form of 192.0.2.10. The device connects to that synthesised IPv6 address, and the NAT64 gateway translates the traffic to IPv4. If your site publishes a real AAAA record, DNS64 passes it through unchanged and visitors connect directly over IPv6 without any translation.
Reverse DNS for IPv6
Reverse lookups for IPv6 addresses use the ip6.arpa zone. The address is expanded to all 32 hexadecimal digits, reversed one digit (nibble) at a time, and each digit becomes a label:
dig -x 2001:db8:10::1 +noall +answer
1.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.1.0.0.8.b.d.0.1.0.0.2.ip6.arpa. 3600 IN PTR www.example.com.
As with IPv4, the PTR records for an IPv6 range are controlled by whoever holds that range, usually your hosting provider.
When You Should Add an AAAA Record
Add an AAAA record when all of these are true:
- Your server has a global IPv6 address: Most cloud providers and many hosting companies assign one, sometimes as an option you need to enable.
- Your services listen on IPv6: The web server, mail server or application must be bound to the IPv6 address, not only to IPv4.
- Your firewall allows IPv6 traffic: IPv6 rules are often managed separately from IPv4 rules.
- You've tested it: Connections to the IPv6 address actually reach your service.
If you use a CDN or reverse proxy such as Cloudflare, Fastly or Amazon CloudFront, it usually publishes AAAA records for you and accepts IPv6 from visitors even if your origin server is IPv4-only.
Don't publish an AAAA record just to have one. A record pointing at an address that isn't serving your site is worse than none, because some clients will try it first.
How to Add and Test an AAAA Record
Step 1: Confirm the Server's IPv6 Address
On a Linux server, list the global IPv6 addresses:
ip -6 addr show scope global
2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 state UP qlen 1000
inet6 2001:db8:10::1/64 scope global
valid_lft forever preferred_lft forever
Step 2: Make Sure Services Listen on IPv6
For Nginx, each server block needs an IPv6 listen directive alongside the IPv4 one:
server {
listen 443 ssl;
listen [::]:443 ssl;
http2 on;
server_name example.com www.example.com;
ssl_certificate /etc/letsencrypt/live/example.com/fullchain.pem;
ssl_certificate_key /etc/letsencrypt/live/example.com/privkey.pem;
root /var/www/example.com;
}
Check what's listening:
sudo ss -tlnp | grep ':443'
LISTEN 0 511 0.0.0.0:443 0.0.0.0:* users:(("nginx",pid=1123,fd=6))
LISTEN 0 511 [::]:443 [::]:* users:(("nginx",pid=1123,fd=7))
If you only see the 0.0.0.0 line, Nginx isn't accepting IPv6 connections.
Step 3: Test the Address Before Publishing DNS
From a machine with IPv6 connectivity, connect to the IPv6 address directly while sending the right hostname:
curl -6 -sI --resolve "www.example.com:443:[2001:db8:10::1]" https://www.example.com/
HTTP/2 200
server: nginx
Step 4: Create the Record
In a DNS dashboard, add a record with type AAAA, the name (@ or a subdomain), and the IPv6 address. In a BIND zone file:
@ 3600 IN AAAA 2001:db8:10::1
www 3600 IN AAAA 2001:db8:10::1
With the Cloudflare API:
curl -X POST \
"https://api.cloudflare.com/client/v4/zones/$ZONE_ID/dns_records" \
-H "Authorization: Bearer $CF_API_TOKEN" \
-H "Content-Type: application/json" \
--data '{
"type": "AAAA",
"name": "www.example.com",
"content": "2001:db8:10::1",
"ttl": 3600,
"proxied": false
}'
Or with Terraform on Route 53:
resource "aws_route53_record" "www_ipv6" {
zone_id = aws_route53_zone.main.zone_id
name = "www.example.com"
type = "AAAA"
ttl = 3600
records = ["2001:db8:10::1"]
}
Step 5: Verify End to End
Confirm the record resolves, then make a normal request forcing IPv6:
dig www.example.com AAAA +short
curl -6 -sI https://www.example.com/
If both succeed, IPv6 visitors will reach your site natively.
Common AAAA Record Mistakes
- Publishing AAAA without listening on IPv6: The most common mistake. Happy Eyeballs hides it for browsers, but other clients, such as APIs, monitoring tools and some mail servers, may fail outright.
- Forgetting the firewall: IPv6 traffic is often filtered by separate rules, so the server listens but packets never arrive.
- Moving servers and updating only the A record: When you migrate, update or remove the AAAA record too. A stale AAAA record sends IPv6 visitors to the old server.
- Using a link-local or unique local address: Addresses starting with
fe80:orfdaren't reachable from the internet. - Missing certificates for IPv6 virtual hosts: Make sure IPv6 listeners use the same TLS configuration as IPv4 ones.
- Assuming email works over IPv6 automatically: If your mail server's hostname has an AAAA record, other servers may deliver over IPv6, so it needs proper reverse DNS and authentication on that address as well.
FAQ: AAAA Records and IPv6 DNS
An IPv6 address is 128 bits, four times the 32 bits of an IPv4 address held by an A record. The four A's reflect that larger size.
It isn't required, because IPv6-only visitors can usually reach IPv4 sites through NAT64. But adding one lets IPv6 users connect natively, which avoids translation and prepares your site for networks that are increasingly IPv6-first.
Yes, and that's the normal dual-stack setup. Clients with IPv6 usually prefer the AAAA address and fall back to the A record if IPv6 fails.
Only if the address doesn't actually serve your site. Test the IPv6 address directly with curl before publishing the record, and check that your firewall and web server accept IPv6 connections.
Yes. A CNAME aliases the whole name, so a resolver following it returns whatever A and AAAA records the target has.
No. You can query AAAA records over an IPv4 connection to any resolver. You only need IPv6 connectivity to actually connect to the address you get back.
Conclusion
An AAAA record is the IPv6 counterpart to the A record, mapping a hostname to a 128-bit IPv6 address. IPv6 DNS otherwise works just like IPv4 DNS: the same resolvers, the same hierarchy, and the same caching rules. Clients ask for both record types and, thanks to address selection and Happy Eyeballs, prefer IPv6 when it works and fall back to IPv4 quickly when it doesn't.
The important part is making sure an AAAA record points at something real. Confirm your server has a global IPv6 address, that your services and firewall accept IPv6 connections, and that a direct curl -6 test succeeds before publishing the record. Keep A and AAAA records in step whenever you move servers, and IPv6 visitors will get the same reliable experience as everyone else.


