What does an AAAA record do?
AAAA is record type 28, defined in RFC 3596. Its RDATA is sixteen raw bytes — one IPv6 address, written in the usual colon-hexadecimal form. Functionally it is identical to the A record: it terminates a resolution and gives the client an address to connect to. Everything else about DNS — caching, TTLs, delegation, CNAME chasing — behaves exactly the same.
What differs is the client side. A dual-stack machine issues A and AAAA queries in parallel for the same name and then decides which address family to use. Under Happy Eyeballs v2 (RFC 8305) it generally prefers IPv6, attempts a connection, and falls back to IPv4 within a couple of hundred milliseconds if the IPv6 path fails. This is why a broken AAAA record often produces a small, hard-to-reproduce latency penalty rather than an obvious outage.
AAAA record syntax and fields
| Field | Example | Meaning |
|---|---|---|
| Name (owner) | cloudflare.com. | The hostname. @ for the apex; bare labels are relative to the zone origin. |
| TTL | 300 | Seconds a resolver may cache the answer. |
| Class | IN | Internet class. |
| Type | AAAA | Record type 28 — IPv6 host address. |
| RDATA | 2606:4700::6810:85e5 | One IPv6 address. :: collapses the longest run of zero groups and may appear at most once. |
Address notation rules that trip people up
::may be used once per address.2001:db8::1::2is invalid and most validators will reject it — but some provider forms will not, and you find out later.- Leading zeros in a group are optional:
2001:0db8:0000:0000:0000:0000:0000:0001and2001:db8::1are the same address. - Hex digits are case-insensitive. RFC 5952 recommends lowercase for canonical output, which is what
digprints. - The zone file value must be a bare address — no CIDR prefix, no brackets.
2606:4700::6810:85e5/128and[2606:4700::6810:85e5]are both wrong. - A link-local (
fe80::/10) or unique-local (fc00::/7) address in a public zone is as broken as publishing 192.168.x — external clients cannot reach it.
Multiple AAAA records, round-robin, and dual stack
As with A records, several AAAA records at the same name form an RRset and are returned together, usually in rotating order. The same caveats apply: no health checking, per-resolver rather than per-user distribution, and a removal that stays cached for the TTL.
The dual-stack question is where AAAA gets interesting operationally. Publishing both A and AAAA for a name means each client picks a family independently, so you now have two paths that can fail independently. In practice:
- Publish AAAA only when the IPv6 path genuinely works end to end — the host has a routable address, the firewall permits it, and the application listens on
::. A common failure is nginx listening on0.0.0.0:443only while an AAAA record advertises the host. - Test from an IPv6-capable network before you publish. Many office and home networks are IPv4-only, so a broken AAAA can pass local testing and fail for a fraction of real users.
- Keep A and AAAA in sync during migrations. Moving a host and updating only the A record leaves IPv6 users on the old server — a class of "it works for me" ticket that eats hours.
- Some CDNs and mail hosts require IPv6. Reaching a network that is IPv6-only, or one that penalizes IPv4-only senders, is a growing reason to enable AAAA rather than a purely theoretical one.
AAAA and email
Mail is the area where AAAA causes the most avoidable damage. If your MX record target has an AAAA record, receiving servers may connect to you over IPv6 — and if you are the one sending over IPv6, several large mailbox providers apply stricter rules to IPv6 sources than to IPv4. In particular, forward-confirmed reverse DNS on the sending IPv6 address is effectively mandatory, and an IPv6 sender with no PTR record is commonly rejected outright.
Verify what a receiving server sees with the reverse DNS lookup, and check the full picture on the deliverability test.
TTL guidance
AAAA TTLs follow the same logic as A: 3600 or higher for stable hosts, 300 for the day or two around a migration, back up afterwards. One extra rule specific to AAAA — when you are rolling out IPv6 for the first time, start with a low TTL (300) so that pulling the record is fast if something is wrong. IPv6 problems surface unevenly and you want the ability to withdraw the record quickly without waiting out an hour of caching. Raise the TTL once you have a week of clean data.
Common AAAA mistakes
- Publishing AAAA before the service listens on IPv6. The record resolves, the TCP connect times out, and Happy Eyeballs masks it as "the site feels slow".
- Firewall asymmetry.
iptablesrules do not apply to IPv6; you needip6tables(or an nftables ruleset covering both). Hosts routinely end up wide open or completely closed on v6. - Forgetting AAAA when decommissioning a server. Deleting the A record and leaving the AAAA behind sends IPv6 clients to a dead box.
- Assuming a CNAME covers both families. A CNAME does cover both — the target's A and AAAA are both used — but if you replaced a CNAME with an explicit A record, you silently dropped IPv6 support.
- IPv6 without PTR on a mail sender. Covered above; it is the single most expensive AAAA mistake.
- Typing the address by hand. IPv6 addresses are long and the
::rule is easy to get wrong. Copy fromip -6 addroutput rather than transcribing.
Check it with dig
# IPv6 addresses for a name
dig +short cloudflare.com AAAA
# Full answer with TTL
dig +noall +answer google.com AAAA
# Ask the authoritative server, bypassing caches
dig +noall +answer @ns1.google.com google.com AAAA
# Confirm the host actually answers over IPv6
ping6 -c 3 cloudflare.com
curl -6 -sI https://cloudflare.com | head -1
# Reverse lookup for an IPv6 address
dig +short -x 2001:4860:4860::8888If dig returns an AAAA but curl -6 times out, the record is fine and the network or service is not. That single pair of commands separates a DNS problem from a connectivity problem faster than anything else. Cross-check both families with the A record lookup and the full-zone DNS Lookup.