The AAAA Record

The same idea as an A record, aimed at a different address space

A AAAA record maps a hostname to a single IPv6 address. It does the same job as an A record, in the same place in the zone, for the addressing scheme that is replacing the one A records were designed around.

The name is arithmetic rather than a code. An IPv4 address is 32 bits; an IPv6 address is 128 bits, four times as long, so the record type collected four As. IANA lists it under type value 28, defined by RFC 3596, which describes it as a record specific to the Internet class that stores a single IPv6 address encoded in network byte order. One address per record, several records for several addresses, TTL rules identical to A.

If format were the whole story this page would stop there. It does not, because of a consequence that has nothing to do with the record's shape. A client that can see both a AAAA record and an A record for a name does not treat them as equal options. Publishing a AAAA record does not add a path to your service; it changes which path most of your users try first, and that is why this record is more interesting than its definition.

What a client actually does when both records exist

Two specifications describe the behavior, and they apply in order.

RFC 6724 sets the preference. Its default policy table prefers communication using IPv6 addresses to communication using IPv4 addresses when a matching source address is available, expressed as precedence values in which the general IPv6 range outranks the IPv4-mapped range. An administrator can invert that locally, and the RFC shows how, but almost nobody does. On a dual-stack machine, the AAAA answer wins by default.

RFC 8305, Happy Eyeballs version 2, describes what a well-behaved client does next. It sends the AAAA query first, immediately followed by the A query. If the A answer arrives first, it waits a short Resolution Delay, recommended at 50 milliseconds, rather than racing ahead on IPv4. It then sorts and interleaves the addresses, so the first of the preferred family is followed by one from the other family, and it staggers connection attempts by a Connection Attempt Delay recommended at 250 milliseconds, with a floor of 100 milliseconds and a ceiling of 2 seconds. The first connection to complete wins; the rest are abandoned.

Read that as a statement of intent and the shape of the problem appears. The algorithm exists to hide broken IPv6 from the user, and against a browser it usually succeeds. Success at hiding a fault is not the same as not having one.

Why a broken AAAA record is worse than no AAAA record

Having no AAAA record is an unambiguous statement: this service is reachable over IPv4. Clients ask, get nothing back, use the A record, and connect. Nothing is lost except native IPv6 reachability.

A AAAA record that does not work is a false statement, and false statements in DNS are paid for in time. The client believes the address, prefers it, and tries it first. How much that costs depends on how it fails, and the two modes are not close. If something at that address refuses the connection, the refusal comes back quickly and the client moves on. If the packets are silently dropped, by a firewall rule that was never written for IPv6 or by a route that does not exist, nothing comes back and the client waits for a timeout.

RFC 6555, the first version of Happy Eyeballs, put the pre-mitigation version plainly: IPv6-capable applications incur many seconds of delay before falling back to IPv4 when IPv6 connectivity is impaired. It also recorded why content providers were reluctant to publish AAAA records at all, since returning multiple AAAA records to a client with broken IPv6 connectivity further increases the delay before it gives up.

Happy Eyeballs shortened the delay. It did not repair the fault, and it is a client-side behavior specified with should rather than must. Browsers implement it well. Command-line tools, mail servers, monitoring agents, API clients and older HTTP libraries frequently do not race address families at all: they resolve, prefer IPv6, connect, and hang. Your visitors may never notice a broken AAAA record. The service calling your webhook will.

How adding one record breaks a site that was working

The usual sequence is that somebody enables IPv6 on a server, copies the address it was given into a AAAA record, and hears about slow or failed page loads within the hour. Nothing about the site changed. The record simply started routing people down a path that was never finished.

RFC 4472 states the conditions that should hold before a AAAA record is published: the address is assigned to the interface on the node, the address is configured on the interface, and the interface is on a link connected to the IPv6 infrastructure. Most incidents are a failure of that third condition, or of something above it:

• Firewall rules are maintained separately per family. An IPv4 rule set that permits port 443 says nothing about IPv6, and the default in most stacks is to drop.
• The service is bound only to an IPv4 socket. The interface has the address, the process is not listening on it, and the port answers nothing.
• The address is configured but not routed. Link-local or internal-only IPv6 looks identical in an interface listing and is unreachable from outside.
• Something upstream speaks only IPv4. A reverse proxy, WAF or origin connection without IPv6 turns a reachable front end into a broken one.
• Address-aware logic assumes 32 bits. Allow lists, rate limits, geo rules and logging pipelines break in quiet ways when the source address is suddenly 128 bits long.

Testing before you publish, not after

Every item above can be checked while the name still carries only an A record, which is the point. RFC 4472 recommends that approach directly, suggesting a service be piloted using separate service names and moved to the shared name once you are confident the service level will not degrade for users unaware of IPv6.

A workable order looks like this. Publish the AAAA record on a test hostname that nothing depends on. From a network with real IPv6, connect to it with the client forced to IPv6 only, and confirm you get a full response rather than a handshake that stalls. Repeat with the tools that are not browsers, since those are the ones that will not fall back. Check that your logs show the requests arriving over IPv6 and that whatever reads those logs handles the addresses. Then publish on the real name with a short TTL.

The short TTL is there so you can undo the change. Removing a AAAA record is instant on your own servers and slow everywhere else, bounded by the TTL that was in force when resolvers cached it, so publishing at a long TTL removes your ability to withdraw it in any useful timeframe.

Getting the address itself right

IPv6 addresses have more than one valid written form, which makes comparing two of them by eye unreliable in a way IPv4 never was. RFC 5952 defines a canonical representation: leading zeros must be suppressed, so 2001:0db8::0001 is written 2001:db8::1; the double colon must be used to its maximum capability; the double colon must not be used to shorten a single 16-bit zero field; and the hexadecimal letters must be lowercase.

The practical consequence is that a AAAA record can look wrong and be right, or look right and differ from the address on the interface in a character nobody noticed. Normalize both values before deciding they match, rather than comparing strings. The other thing to watch for is 2001:db8::, the prefix RFC 3849 reserved for documentation. It appears in every example and every tutorial, it is valid in a AAAA record, and it reaches nothing at all.