An AAAA record maps a hostname to an IPv6 address, the counterpart to the A record used for IPv4, and it is what lets dual-stack clients reach a site over the newer protocol.
What is an AAAA record?
An AAAA record ("quad-A") is defined in RFC 3596 and stores a 128-bit IPv6 address for a hostname, the same role an A record plays for a 32-bit IPv4 address. A domain can hold both record types at once for the same name, which is what "dual-stack" means in practice: one hostname, two addresses, two protocol versions.
The record itself carries no priority or weight. A hostname can have several AAAA records, and resolvers are free to return them in any order, though most name servers rotate the order on repeated queries.
- AAAA holds a full IPv6 address, written in compressed hex-colon form (e.g. 2606:4700::6810:85e5)
- A domain with both A and AAAA records is dual-stack; AAAA-only is IPv6-only, and is still rare for public-facing sites
- AAAA target hostnames must resolve directly, never through a CNAME, the same constraint RFC 1034 places on A records
Dual-stack and happy eyeballs
When a name has both A and AAAA records, a dual-stack client (one with both IPv4 and IPv6 connectivity) has to pick which address family to try. Doing this naively is slow: if IPv6 is broken somewhere on the path, a client that waits for a full IPv6 connection timeout before falling back to IPv4 can stall for many seconds.
RFC 8305 describes the fix, known as Happy Eyeballs. The client requests both A and AAAA records, then starts connecting to the IPv6 address first but fires a fallback connection attempt to IPv4 after a short delay (commonly 250ms) if the first attempt has not succeeded yet. Whichever connection completes first wins, and the other is abandoned. Modern browsers and most operating system resolvers implement this by default, which is why publishing an AAAA record rarely breaks anything for IPv4-only visitors: a client without real IPv6 connectivity should fail over to A within a couple hundred milliseconds.
The failure mode Happy Eyeballs was built to avoid is still visible when AAAA is published but not actually reachable, for example a firewall that drops IPv6 traffic silently instead of refusing it. Silent drops (as opposed to a fast connection refusal) are the slowest case for any client, including ones that implement Happy Eyeballs correctly, because the client has to wait out a timeout rather than get an immediate signal to switch families.
AAAA at the zone apex
The zone apex (the bare domain, like example.com rather than www.example.com) cannot use a CNAME per RFC 1034, since the apex also needs to hold the SOA and NS records, and a CNAME must be the only record at its name. AAAA at the apex sidesteps that restriction entirely, since AAAA is a normal record type that coexists with SOA and NS at the same name; it does not need the ALIAS/ANAME workarounds that some DNS providers built specifically for apex CNAME-like behavior.
Providers that offer both A and AAAA on the apex, and only A (or an ALIAS) on the apex while pushing AAAA to www, are both legitimate configurations. What matters for consistency is that any address published at a name resolves to a service that actually answers on that protocol version, since a stale AAAA record pointing at a decommissioned IPv6 address will not fail over the way a CNAME chain break might.
Reading AAAA lookup results
Each AAAA result row shows the record type, the resolved IPv6 address, and, when the resolver reports it, a TTL in seconds. There is no priority or weight field on AAAA, unlike MX or SRV, since address records do not encode ordering preference in the protocol.
| Field | Example value | Meaning |
|---|---|---|
| Type | AAAA | Record type, always AAAA for this query |
| Value | 2606:4700::6810:85e5 | The resolved IPv6 address, compressed form |
| TTL | 300 | Seconds a resolver may cache this answer before re-querying |
Common AAAA problems
- No AAAA record: the domain is IPv4-only. Not an error, just means IPv6-only clients (some mobile carriers, some IoT networks) fall back to a NAT64/DNS64 gateway if one is configured, or fail if not
- AAAA published but unreachable: the address is announced in DNS but nothing answers on it, often a load balancer or firewall not yet configured for the IPv6 listener that matches the IPv4 one
- Mismatched content behind A vs AAAA: some CDN or hosting setups accidentally serve different content or TLS certificates depending on which address family a client used, usually from stale configuration on one leg of the dual stack
- Very short or very long TTL left over from a migration: a short TTL is normal while cutting over to a new IPv6 range, but leaving it low long-term adds needless query load on authoritative servers
FAQ
Does adding an AAAA record break access for IPv4-only visitors?
No. IPv4-only clients simply ignore AAAA and use the A record as before. Dual-stack clients with Happy Eyeballs (RFC 8305) try both and use whichever connects first, so adding AAAA is additive rather than a replacement for A.
Can a hostname have an AAAA record but no A record?
Yes, an IPv6-only host is valid and increasingly common for internal or backend services. For public-facing sites it is still uncommon, since it excludes IPv4-only clients unless a NAT64/DNS64 gateway sits in front of the network.
Why does my AAAA lookup return nothing when the A lookup works?
It means the domain has not published an IPv6 address yet. This is a configuration choice, not a fault: many domains run IPv4-only indefinitely and will never return an AAAA record until the operator explicitly adds one.
Can an AAAA record point to a CNAME target?
No. Like an A record, an AAAA record must resolve directly to an address; RFC 1034 requires that any name with a CNAME have no other record types, so a hostname is either a CNAME or has A/AAAA records, never both patterns mixed at the same name.
Why do two AAAA lookups for the same domain sometimes return addresses in a different order?
Many authoritative servers rotate the order of multiple AAAA records on each answer (round-robin), and resolving caches along the path may also reorder them. This is normal load-distribution behavior, not a fault, and matches how multiple A records behave.
Is IPv6 required for a domain to work correctly?
No. A domain with only A records is fully functional for the large majority of internet traffic today. AAAA becomes relevant for reaching IPv6-only or IPv6-preferring networks, which are more common on mobile carriers and in networks that have run out of IPv4 address space to allocate.