What Is an AAAA Record, and Why Does IPv6 Need It?

If you've ever looked at a DNS dashboard and wondered why there's a record type called "AAAA" sitting right next to the familiar A record, you're not alone. The A record has been around since the earliest days of the internet, and for a long time it was the only way to tell the world where your website lives. But the pool of IPv4 addresses ran dry years ago, and a growing share of traffic — especially from mobile networks — now arrives over IPv6. The AAAA record is how DNS hands out those IPv6 addresses.

This article explains what an AAAA record is, why IPv6 needed its own record type, how clients choose between IPv4 and IPv6 when both exist, and how to add, test, and troubleshoot AAAA records without breaking your site. If you need a refresher on the broader set of record types first, start with what DNS records are.

What Is an AAAA Record?

An AAAA record (pronounced "quad-A") is a DNS record that maps a hostname to a 128-bit IPv6 address. It does exactly the same job as an A record — "this name lives at this address" — but for IPv6 instead of IPv4.

The name is a small joke built into the protocol. An IPv4 address is 32 bits long, and the record that holds it is called "A" (for address). An IPv6 address is 128 bits — four times as long — so its record became "AAAA." The type was originally defined in RFC 1886 and later updated by RFC 3596, which is still the current specification. Its numeric type code is 28.

Here's how the two look side by side for the same host:

Record	Address family	Address size	Example value
A	IPv4	32 bits	203.0.113.10
AAAA	IPv6	128 bits	2001:db8:85a3::8a2e:370:7334

A hostname can have an A record, an AAAA record, both, or several of each. When a name has both, it's described as dual-stack: reachable over either protocol.

Why IPv6 Needs Its Own Record Type

It's reasonable to ask why DNS didn't just let the A record hold longer addresses. The answer comes down to how DNS records are structured on the wire.

Every resource record has a fixed type, and each type defines the exact format of its data. An A record's data is always exactly four bytes. Software across the internet — resolvers, firewalls, libraries, load balancers — has been written to expect that. Stuffing a 16-byte value into an A record would have broken every one of those implementations in unpredictable ways.

Creating a new record type was the clean solution:

1. Backward compatibility. Old software that doesn't understand IPv6 never asks for AAAA records, so it keeps working exactly as before.
2. Independent queries. A client can ask specifically for an IPv4 address, an IPv6 address, or both, and the resolver returns only what was asked for.
3. Gradual migration. Site owners can add IPv6 one hostname at a time without touching their existing IPv4 setup.

That last point is the real reason AAAA records matter. IPv4 and IPv6 aren't compatible with each other — an IPv6-only device can't talk to an IPv4-only server without a translation layer in between. The internet has been running both side by side for years, and the AAAA record is what makes that coexistence possible at the DNS layer.

Why IPv6 Matters for Your Site Today

IANA handed out its last blocks of IPv4 addresses to the regional registries in 2011, and the regional registries have since run out of free pools too. New IPv4 addresses are now bought, leased, or shared behind carrier-grade NAT. IPv6, by contrast, has an address space so large that running out isn't a practical concern.

What that means in practice:

• Mobile carriers lean heavily on IPv6. Many large mobile networks run IPv6-first or IPv6-only internally and translate to IPv4 only when a destination has no AAAA record. Serving IPv6 directly can skip that translation hop.
• Global adoption keeps climbing. Google's public IPv6 statistics show a large and growing share of its users connecting over IPv6 — well over a third in recent years, and much higher in some countries.
• Some cloud providers now charge for public IPv4 addresses, which pushes infrastructure toward IPv6 where possible.
• Some networks are IPv6-only. For those clients, a site without an AAAA record is reachable only through a translation mechanism like NAT64/DNS64.

You don't need IPv6 for your site to work for most visitors today. But adding an AAAA record is usually low effort and future-proofs your setup.

How AAAA Lookups Work

When a browser wants to connect to www.example.com, the operating system's stub resolver typically sends two queries in parallel: one for type A and one for type AAAA. The DNS resolver answers each independently, following CNAMEs if needed.

What happens next depends on the client:

• If only an A record comes back, the client connects over IPv4.
• If only an AAAA record comes back and the client has working IPv6, it connects over IPv6.
• If both come back, the client uses a selection algorithm to decide.

Happy Eyeballs

Modern browsers and operating systems use an algorithm called Happy Eyeballs (RFC 8305, version 2). The idea is simple: prefer IPv6, but don't let a broken IPv6 path make the user wait. The client starts an IPv6 connection first, and if it hasn't succeeded within a short delay (RFC 8305 recommends 250 milliseconds), it starts an IPv4 connection in parallel and uses whichever finishes first.

This is why a misconfigured AAAA record often doesn't cause a complete outage — just mysterious slowness for some users, or failures in tools that don't implement Happy Eyeballs (older scripts, some API clients, certain embedded devices). It's also why you should test IPv6 explicitly rather than assuming it works because the site loads in your browser.

AAAA Record Syntax and Zone File Examples

In a zone file, an AAAA record looks just like an A record, with a different type and an IPv6 address as the value:

$ORIGIN example.com.
$TTL 3600

@     IN  A      203.0.113.10
@     IN  AAAA   2001:db8:10::10

www   IN  A      203.0.113.10
www   IN  AAAA   2001:db8:10::10

api   IN  AAAA   2001:db8:10::20
api   IN  AAAA   2001:db8:10::21

The root domain and www are dual-stack. The api host has two AAAA records and no A record, so it's reachable only over IPv6, and clients will spread connections between the two addresses.

IPv6 address notation rules

IPv6 addresses are written as eight groups of four hex digits separated by colons. Two shorthand rules keep them readable:

1. Leading zeros in a group can be dropped. 2001:0db8:0010:0000:0000:0000:0000:0010 becomes 2001:db8:10:0:0:0:0:10.
2. One run of consecutive all-zero groups can be replaced with ::. That gives 2001:db8:10::10. You can only use :: once in an address, otherwise it would be ambiguous.

DNS servers accept either full or compressed forms and store the same 16 bytes either way. RFC 5952 recommends lowercase hex and the most compressed form when writing addresses for humans, which is what most tools display.

How to Look Up an AAAA Record

You can query AAAA records with the same tools you use for any other record type. If you're new to these tools, see the guides on using dig for DNS lookups and using nslookup.

Using dig:

dig AAAA example.com +short

Using nslookup:

nslookup -type=AAAA example.com

Using host:

host -t AAAA example.com

Using PowerShell on Windows:

Resolve-DnsName -Name example.com -Type AAAA

Each of these returns the IPv6 addresses published for the name. An empty answer with a NOERROR status means the name exists but has no AAAA record — that's normal for an IPv4-only host and not an error.

Checking from code

In Python, socket.getaddrinfo() uses the system resolver and can be restricted to IPv6:

import socket

results = socket.getaddrinfo("example.com", 443, family=socket.AF_INET6, type=socket.SOCK_STREAM)
for family, socktype, proto, canonname, sockaddr in results:
    print(sockaddr[0])

This prints each IPv6 address the system resolver returns for example.com, and raises socket.gaierror if none exist.

In Node.js, the dns/promises module can query AAAA records directly from DNS, bypassing the hosts file:

import { resolve6 } from "node:dns/promises";

const addresses = await resolve6("example.com");
console.log(addresses);

resolve6() returns an array of IPv6 address strings and throws an error with code ENODATA if the name has no AAAA records.

How to Add an AAAA Record

The process is the same as adding an A record in your DNS provider's dashboard — if you're unsure where those settings live, see how to access DNS settings.

1. Find your server's IPv6 address. On a cloud VM, it's usually shown in the instance details once IPv6 is enabled for the network. On Linux, ip -6 addr show scope global lists global IPv6 addresses.
2. Create the record. Choose type AAAA, enter the hostname (@ for the root, or www), and paste the IPv6 address.
3. Set a sensible TTL. If this is your first time enabling IPv6, a short TTL like 300 seconds lets you roll back quickly if something goes wrong.
4. Make sure the server is actually listening on IPv6 before you publish the record.

On AWS Route 53, you can create the record with the CLI:

aws route53 change-resource-record-sets \
  --hosted-zone-id Z0123456789EXAMPLE \
  --change-batch '{
    "Changes": [{
      "Action": "UPSERT",
      "ResourceRecordSet": {
        "Name": "www.example.com",
        "Type": "AAAA",
        "TTL": 300,
        "ResourceRecords": [{ "Value": "2001:db8:10::10" }]
      }
    }]
  }'

UPSERT creates the AAAA record if it doesn't exist or replaces it if it does.

Make the web server listen on IPv6

A common mistake is publishing an AAAA record while the web server only binds to IPv4. In Nginx, you need an explicit IPv6 listen directive:

server {
    listen 80;
    listen [::]:80;
    listen 443 ssl;
    listen [::]:443 ssl;
    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;
}

The [::] lines tell Nginx to accept connections on all IPv6 addresses, alongside the existing IPv4 listeners. Remember that firewalls often have separate IPv4 and IPv6 rule sets — ufw handles both, but raw iptables rules don't apply to IPv6, which uses ip6tables or nftables.

Testing That IPv6 Actually Works

Once the record is published, test the full path — DNS, routing, firewall, and web server — by forcing curl to use IPv6:

curl -6 -sS -o /dev/null -w "%{http_code} via %{remote_ip}\n" https://www.example.com/

The -6 flag makes curl resolve only AAAA records and connect over IPv6. A 200 (or a redirect code) with an IPv6 remote IP means the whole chain is working. Run the same command with -4 to compare.

If your own network doesn't have IPv6 connectivity, run the test from a cloud VM that does, or use an online IPv6 reachability checker. And if you just changed the record, give caches time to pick it up — see how to check whether DNS changes have propagated.

AAAA Records with CDNs, CNAMEs, and Hosting Platforms

You often won't write AAAA records by hand at all:

• CDNs and proxies like Cloudflare usually serve IPv6 to visitors automatically, even if your origin server is IPv4-only. The edge accepts IPv6 connections and talks to your origin over IPv4.
• CNAME targets handle it for you. If www is a CNAME to a hosting platform's hostname, the platform decides whether that target has AAAA records. You can't add your own AAAA record alongside a CNAME on the same name.
• Root domains on managed platforms often use provider-specific flattening or alias records, which return both A and AAAA answers when the target supports them.

Common Mistakes and Best Practices

1. Publishing an AAAA record for a server that isn't reachable over IPv6. The record says "connect here," but the server isn't listening, or a firewall drops the traffic. Happy Eyeballs hides this for browsers, but API clients and monitoring tools may fail outright.
2. Forgetting to update AAAA when you migrate servers. Teams update the A record and leave the old AAAA record pointing to a decommissioned machine. Visitors on IPv6 then land on the wrong server — or nowhere. Audit both record types during any migration.
3. Mismatched content between stacks. If the A and AAAA records point to different servers, make sure they serve the same site, certificate, and configuration.
4. Typos in IPv6 addresses. They're long and easy to get wrong. Copy them from your provider's console rather than retyping them.
5. Ignoring reverse DNS for mail servers. If your mail server sends over IPv6, major mailbox providers expect a matching PTR record for that IPv6 address too. See PTR records for how reverse lookups work in ip6.arpa.
6. Using AAAA as a pointer to another name. AAAA records hold addresses only. If you want an alias, that's what a CNAME is for.

---

AAAA Record FAQ

Conclusion

The AAAA record exists because IPv6 addresses don't fit in an A record, and because the internet needed a way to introduce IPv6 without breaking IPv4. It works exactly like an A record — a name pointing to an address — and modern clients use both together, preferring IPv6 and falling back to IPv4 when needed.

Adding one is easy, but publishing it is a promise that your server is reachable over IPv6. Before you add an AAAA record, confirm your host has a working IPv6 address, your web server listens on it, and your firewall allows it. Test with curl -6, keep both record types in sync during migrations, and you'll be ready for the share of your visitors who are already on IPv6.

Here are some useful references for going deeper on AAAA records and IPv6:

1. RFC 3596: DNS Extensions to Support IP Version 6 — the current specification for the AAAA record type and ip6.arpa.
2. RFC 8305: Happy Eyeballs Version 2 — how clients race IPv6 and IPv4 connections.
3. RFC 5952: A Recommendation for IPv6 Address Text Representation — the canonical way to write IPv6 addresses.
4. Cloudflare Learning Center: What is a DNS AAAA record? — a short explainer with examples.
5. Google: IPv6 Statistics — ongoing measurements of IPv6 adoption among Google users.