AAAA record
The name is genuinely a joke that stuck: an IPv6 address is four times the bit-length of an IPv4 address, so the record that carries one got four A's instead of one. Underneath the naming quirk, an AAAA record does exactly the same job as an A record — it just does it for the other address family.
What it stores, and why the format is stricter
An AAAA record, specified in RFC 3596, maps a domain name to a single 128-bit IPv6 address:
RFC 3596 is deliberately thin — it defines the record type and states plainly that AAAA queries don't trigger the kind of automatic follow-up lookups some other record types do, and otherwise leans entirely on RFC 1035's general record format. The RDATA is just the 128-bit address in network byte order; nothing about the record's mechanics differs from an A record at all. What differs is everything downstream of DNS: whether the network path, the client's own stack, and every router in between actually has working IPv6 connectivity end to end.
Dual stack: both records, one name
Most production domains that support IPv6 publish both record types under the identical name:
A client capable of both address families gets both answers back from a single query round and has to decide which to actually use. Modern operating systems generally implement Happy Eyeballs (RFC 8305): they attempt both address families in quick succession and use whichever connects first, rather than committing to one and waiting out a full timeout if it happens to be broken. That's a deliberate hedge against exactly the failure mode this article's scenario walks through.
Practical scenario: a working site that's broken for exactly some visitors
A support team gets a strange trickle of complaints: a small, consistent slice of visitors report the site simply won't load, while server logs show no errors and most visitors have no problem at all. The affected visitors, when asked, all report the same odd detail — the page eventually times out rather than failing immediately.
dig for the domain shows both record types present:
Both records resolve cleanly. The actual fault is on the far side of a recent infrastructure change: a new load balancer was added in front of the origin server, and its IPv6 listener was never actually configured, even though the AAAA record advertising it was copied over from the old setup and still points at an address that no longer accepts connections. A client with only IPv4 connectivity never even attempts the AAAA address and loads the site normally. A client with IPv6 connectivity gets an address back, tries to connect to it, gets nothing, and — depending on how well its Happy Eyeballs implementation falls back — either hangs for a long timeout before retrying over IPv4, or fails outright if the fallback logic is weak.
* Trying 2606:2800:220:1:248:1893:25c8:1946:443...
* connect to 2606:2800:220:1:248:1893:25c8:1946 port 443 failed: Connection timed out
That -6 flag forces curl to use IPv6 specifically rather than letting it choose, which is exactly how you isolate this class of problem: force each address family in turn and see which one actually fails. The fix here isn't a DNS change at all — the AAAA record is telling the truth about what it's supposed to point to; the load balancer's IPv6 listener needs to actually be turned on, or the AAAA record needs to be pulled until it is.
Common mistakes
- Publishing an AAAA record before IPv6 is genuinely working end to end. An address that resolves but doesn't accept connections is worse for IPv6-capable clients than not publishing the record at all, because it costs them a failed attempt and a timeout instead of an instant, clean fallback to IPv4.
- Assuming an AAAA record's mere presence proves IPv6 connectivity works. DNS only proves the record exists; reaching it is a separate, later question, exactly as this scenario shows.
- Forgetting that A and AAAA are independent records that must each be kept current. Updating one after an infrastructure change and forgetting the other is how a site ends up reachable over one address family and broken over the other.
Practice exercises
- Run
dig <a-major-site> AAAA +shortagainst a large site and confirm it returns a valid IPv6 address, then runcurl -6 -vagainst that same site to confirm the address actually accepts connections. - Explain what Happy Eyeballs is doing when a client has both an A and an AAAA record to choose from, and why that behavior specifically protects against this article's scenario.
- A junior engineer proposes removing all AAAA records "since IPv4 still works for everyone." Explain what visitor population that would actually affect, and why the honest fix is making IPv6 work rather than hiding the record.
Both records so far answer "what address." The next one answers a completely different question — not where a name points, but which other server should actually receive email addressed to a domain: MX record.