AAAA Record Explained: The DNS Record Behind Every IPv6 Address

The Record IPv6 Traffic Ultimately Depends On

Strip DNS down to its literal job and it's this: turning a name a person types into an address a network can route packets toward. For thirty-plus years, that job belonged almost entirely to the A record. Then IPv6 arrived with an address space so large it needed a fundamentally bigger container — 128 bits instead of 32 — and DNS needed a new record type to carry it. That record is the AAAA record, and despite looking like a typo the first time anyone sees it, it does exactly what an A record does, just for a much larger number.

This matters more than it first appears, because IPv6 adoption isn't a future consideration anymore — it's already carrying a meaningful, steadily growing share of global internet traffic, and a domain's AAAA record (or lack of one) directly determines whether IPv6-native visitors reach it the efficient way or fall back to a translated, sometimes slower IPv4 path. Understanding this record properly means understanding both its mechanics and the practical consequences of publishing it, or not.

Why "AAAA" and Not Just "A6" or "B"

The naming decision looks arbitrary until the underlying math is laid out. An IPv4 address occupies 32 bits. An IPv6 address occupies 128 bits — precisely four times larger. When the IETF was standardizing DNS support for IPv6 in the 1990s, RFC 1886 (later superseded by RFC 3596) settled on quadrupling the letter A as a deliberate mnemonic for that 4x jump, rather than simply assigning the next unused letter in the alphabet. It's an unusual naming convention by modern standards, but once the "four times the size" logic clicks, "AAAA" stops looking like an odd typo and starts looking like a small, clever piece of protocol design.

Worth noting: an earlier, now-abandoned proposal called A6 also existed briefly during IPv6's DNS standardization process, designed to support more flexible address renumbering through record indirection. It was deprecated in RFC 6563 for adding complexity that didn't pay for itself in practice — AAAA's simpler, flatter approach won out, and it's the only IPv6 address record type in production use today.

Anatomy of an AAAA Record

Structurally, an AAAA record mirrors an A record almost exactly — a name, a record type, a TTL, and a value — except that value must be a syntactically valid 128-bit IPv6 address instead of a 32-bit IPv4 one. There's no priority field, no weighting, no additional metadata baked into the record format itself. Whatever complexity IPv6 introduces lives in how the address space and surrounding infrastructure work, not in this specific record's structure.

example.com.       3600  IN  AAAA  2606:4700:4700::1111
www.example.com.   3600  IN  AAAA  2606:4700:4700::1111
api.example.com.   300   IN  AAAA  2001:db8:85a3::8a2e:370:7334

IPv6 addresses support a compression shorthand that IPv4 never needed: a single run of consecutive all-zero groups can be collapsed to a double colon (::), and leading zeros within any group can be dropped. 2606:4700:4700:0000:0000:0000:0000:1111 and 2606:4700:4700::1111 refer to the exact same address — the shorter form is purely a notational convenience, never a different value, and only one :: compression is permitted per address to keep the shorthand unambiguous.

How Resolution Actually Differs From an A Record Lookup

The resolution chain itself — stub resolver, recursive resolver, root servers, TLD servers, authoritative servers — works identically regardless of whether the query asks for an A or AAAA record type. What differs is the query type field sent in the DNS request (type 28 for AAAA versus type 1 for A) and, critically, what happens when no matching record exists.

1. Client sends a type-28 query. A browser or application requests specifically the AAAA record for a hostname, separately from any A record request.
2. Resolver walks the same chain. Root, then TLD, then authoritative nameservers — no different from an A record lookup structurally.
3. Authoritative server answers, or returns nothing. If the zone has no AAAA record for that name, the server returns a successful empty answer (NOERROR with no data), not an error — this distinction trips up a lot of debugging.
4. Client falls back if needed. If no AAAA record came back but an A record exists, IPv4-capable clients simply use that instead, usually without the user noticing anything happened.

That third step is worth sitting with: an empty AAAA response is not the same thing as a DNS error, and treating it as one is a common source of confused troubleshooting. A domain that's IPv4-only by design will correctly and normally return "no AAAA records found" every single time it's checked — that's expected behavior, not a broken configuration.

Reading an IPv6 Address in an AAAA Record

An IPv6 address breaks into two conceptual halves for most global unicast addresses: a 64-bit network/routing prefix, assigned by an ISP or allocated to an organization, and a 64-bit interface identifier, which historically was often derived from a device's MAC address (EUI-64) though modern operating systems increasingly use randomized identifiers for privacy instead. An AAAA record doesn't care about that internal structure — it just stores the full 128-bit value — but understanding the split helps explain why IPv6 addressing feels so different operationally from the scarce, carefully rationed IPv4 space: there's genuinely enough room to hand out entire /64 subnets, sometimes larger, to individual customers or even individual devices, without anyone worrying about running out.

Multiple AAAA Records and How Clients Choose

Just like A records, a hostname can carry several AAAA records simultaneously — common for load-balanced or geo-distributed infrastructure. Resolvers can return them in any order, and the requesting client's operating system typically applies its own address-selection logic (commonly following RFC 6724's rules) to decide which to try first, factoring in things like matching address scope and prefix length to the client's own configured addresses. In dual-stack environments, that selection also interacts with Happy Eyeballs (RFC 8305), the algorithm that races an IPv6 attempt against an IPv4 attempt in parallel and uses whichever completes its handshake first — usually IPv6, on networks where it's genuinely well-provisioned end to end.

Caching and TTL Behavior

TTL works identically for AAAA as it does for any other record type — it's simply how long, in seconds, a resolver is permitted to serve a cached answer before it's obligated to re-query. A freshly published or changed AAAA record doesn't reach every resolver worldwide instantly; each one continues answering from its previously cached value until that specific cache entry's TTL expires, which is precisely why a DNS change can appear live from one location and stale from another for a window entirely explained by caching mechanics, not by anything actually broken in the change itself.

Why Some Domains Still Don't Publish One

Despite IPv6's steady growth, plenty of well-run, high-traffic domains remain IPv4-only by deliberate choice, and it's rarely negligence. Common, entirely reasonable causes include a legacy load balancer or firewall appliance that doesn't support IPv6 cleanly, a third-party CDN or hosting contract that hasn't enabled it by default, an internal compliance requirement that hasn't been updated to account for dual-stack operation, or simply a team that's prioritized other work because their current IPv4 setup functions without complaint. None of these are wrong decisions on their own — they're trade-offs, and "no AAAA record" should be read as a snapshot of current infrastructure choices, not as a mistake to immediately flag.

Security Considerations Specific to AAAA

An AAAA record doesn't introduce meaningfully different risk on its own — exposure risk comes from what's actually listening on the address, identical to IPv4. What does change with IPv6's vastly larger space is that brute-force scanning across an entire subnet becomes computationally infeasible in a way IPv4 subnet scanning simply isn't, which is a genuine, if modest, security benefit. The more operationally relevant risk is configuration drift: teams that carefully lock down IPv4 firewall rules sometimes leave IPv6 rules at a permissive default, effectively leaving a second, unguarded path into the same infrastructure — auditing both stacks with equal rigor is non-negotiable once AAAA records are in production.

Common Mistakes

Best Practices

Publish AAAA alongside A wherever infrastructure genuinely supports it, rather than IPv6-only, unless every consuming client is guaranteed IPv6-capable (true for a lot of internal infrastructure, rarely true for the open public internet). Keep TTLs at a sensible middle ground — long enough to limit unnecessary query volume, short enough to allow a genuine emergency cutover without excessive delay. Monitor both address families independently instead of assuming one implies the health of the other, and treat firewall parity between IPv4 and IPv6 as a recurring audit item rather than a one-time setup task.

Real-World Examples

AAAA Records Across Major DNS Providers

Every major managed DNS provider — Cloudflare, AWS Route 53, Google Cloud DNS, Azure DNS, and standard registrar panels — treats AAAA as a fully first-class record type with the same add-record workflow used for an A record, just selecting AAAA from the type dropdown and pasting in an IPv6 address instead. Where providers meaningfully differ is in supporting tooling: some flag a hostname with an A record but no matching AAAA as an IPv6-readiness gap directly in their dashboard, and Cloudflare specifically can synthesize an AAAA response at the edge even for origins that are internally IPv4-only, terminating IPv6 at the proxy layer and translating to IPv4 on the way to origin — worth knowing, because it means a working AAAA lookup through a Cloudflare-proxied domain doesn't necessarily confirm your actual origin server supports IPv6 natively.

Command-Line Reference: Checking an AAAA Record Yourself

Beyond any DNS lookup tool, verifying an AAAA record from a terminal is a single command on every major platform, and knowing all of them is genuinely useful since not every environment has every tool installed:

The +trace flag is particularly valuable when an AAAA lookup behaves unexpectedly — it walks the entire resolution chain manually, root servers through TLD servers through the domain's own authoritative servers, exposing exactly where a delegation or configuration problem actually sits rather than just returning a final empty or failed answer with no context about why.

DNSSEC and AAAA Records

DNSSEC — the cryptographic signing layer that protects DNS answers from tampering and cache poisoning — applies to AAAA records exactly the same way it applies to A records or any other record type in a signed zone; there's no IPv6-specific carve-out in how DNSSEC itself functions. What's worth double-checking during an IPv6 rollout is that DNSSEC signing was actually re-verified after adding new AAAA records, since a misconfigured signing pipeline can occasionally produce validation failures for newly added record types even when the zone's overall DNSSEC status appears healthy at a glance.

A Practical IPv6 DNS Rollout Checklist

Pros & Cons of Publishing an AAAA Record

Expert Tips

Related Tools

Check any hostname's live AAAA record with AAAA Record Lookup. For the IPv4 side of the same hostname, use A Record Lookup. For the full record picture — AAAA, A, MX, TXT, NS, CNAME — use DNS Lookup, and to check IPv6 address geolocation or type directly, try IPv6 Lookup. Ready to set one up yourself? See Configure AAAA, or read the broader IPv6 DNS Records guide for everything else IPv6 touches in a DNS zone.