An AAAA record (pronounced “quad-A”) is the DNS resource record that maps a domain name to a 128-bit IPv6 address. Among DNS records it is the IPv6 counterpart of the A record, which maps a name to an IPv4 address, and it is what a client requests when it wants to connect to a host over IPv6.
The record type was standardized as type code 28 in the IPv6 DNS extensions. Its name reflects the address size: an IPv6 address is four times as long as an IPv4 address, so the single “A” became four. Publishing AAAA records is the step that makes a service reachable for IPv6-only and dual-stack clients by name.
Structure of an AAAA record
Like every resource record, an AAAA record has an owner name, a TTL, a class and a type, followed by data. The data field is always exactly 16 bytes, the binary form of one IPv6 address. In zone file notation a typical entry looks like shop.example.org. 3600 IN AAAA 2001:db8::10.
| Field | Example value | Meaning |
|---|---|---|
| Owner name | shop.example.org. | The name being described |
| TTL | 3600 | Seconds a resolver may cache the record |
| Class | IN | Internet class, used for practically all records |
| Type | AAAA (28) | IPv6 address record |
| Data | 2001:db8::10 | One IPv6 address, 128 bits |
A name can have several AAAA records, for example for multiple servers, and resolvers return them as one record set. IPv6 addresses are written in hexadecimal groups, and the double colon compresses consecutive zero groups once per address.
AAAA record compared with other DNS records
The AAAA record is one of the address records, but it interacts closely with several other types in the same zone. The comparison shows where it fits.
| Record | Maps | Relation to AAAA |
|---|---|---|
| A | Name to IPv4 address | Published alongside AAAA for dual-stack hosts |
| CNAME | Name to another name | An alias name cannot also hold an AAAA record |
| PTR | Address to name | Reverse mapping for IPv6 lives under ip6.arpa |
| MX | Domain to mail server name | The mail server name needs A or AAAA records |
| NS | Zone to name server names | IPv6 glue records are AAAA records |
Reverse DNS for IPv6 uses nibble format: the 32 hexadecimal digits of the address are reversed, separated by dots and placed under ip6.arpa. Many mail receivers expect matching forward AAAA and reverse PTR records for sending servers.
How clients use AAAA records
A dual-stack client usually queries for A and AAAA records in parallel. The answers feed an address selection algorithm that by default prefers IPv6 when the client has working global IPv6 connectivity.
To avoid long delays when the IPv6 path is broken, modern clients implement Happy Eyeballs. They start an IPv6 connection first and, if it does not succeed within a short delay of about 250 milliseconds, they race an IPv4 connection and use whichever completes first. This hides many IPv6 faults from users, but it also means broken AAAA records can go unnoticed for a long time.
| DNS answer | Dual-stack client | IPv6-only client |
|---|---|---|
| A and AAAA | Prefers IPv6, falls back to IPv4 | Uses IPv6 |
| Only A | Uses IPv4 | Needs DNS64 and NAT64 to connect |
| Only AAAA | Uses IPv6 if available | Uses IPv6 |
On IPv6-only mobile networks, a DNS64 resolver synthesizes AAAA records from A records, typically inside the well-known prefix 64:ff9b::/96, so that a NAT64 gateway can translate traffic to IPv4-only servers.
Publishing AAAA records correctly
An AAAA record should be published only when the service really answers over IPv6 with the same content, certificate and security policy as over IPv4. The checklist below guides a typical rollout.
- Confirm IPv6 connectivity of the server or load balancer and open firewall rules for IPv6 explicitly.
- Test the service on the IPv6 address directly, including TLS certificates and redirects.
- Publish the AAAA record with a short TTL, for example 300 seconds, during the rollout.
- Monitor IPv6 traffic and errors separately from IPv4, since fallback can mask failures.
- Raise the TTL to the normal value once the service is stable.
Unlike a CNAME, an AAAA record is allowed at the zone apex, so a bare domain can point directly to IPv6 addresses. When a CDN or load balancer provides the addresses, many DNS providers offer alias or flattening features that publish synthesized A and AAAA records at the apex and keep them current automatically.
Common mistakes with AAAA records
AAAA problems are typically operational mismatches between DNS and the network, not syntax errors. The most frequent cases are summarized below.
| Problem | Effect | Fix |
|---|---|---|
| AAAA points to an old server | IPv6 users see outdated content | Update both address records together |
| IPv6 firewall missing | Slow loads while clients fall back | Mirror IPv4 firewall rules for IPv6 |
| Documentation prefix in production | Unreachable address | Never publish 2001:db8::/32 addresses |
| AAAA beside a CNAME | Zone rejected or undefined results | Put the AAAA on the target name |
| Link-local or private address published | Works only inside one network | Publish global unicast addresses publicly |
In everyday language
The internet has two address systems: the older, shorter IPv4 addresses and the newer, much longer IPv6 addresses. An AAAA record is the entry in the internet’s phone book that lists the new-style address for a name.
When your device supports the newer system, it looks for this entry first. If the entry exists and works, the connection uses IPv6; if not, the device quietly falls back to the older address.
Seen in the real world
A university hosts its course portal on a dual-stack load balancer and publishes both an A and an AAAA record for the portal name. Monitoring shows that about half of the student traffic arrives over IPv6, mostly from mobile networks.
After a firewall upgrade, IPv6 rules are accidentally left out. Users do not see errors, but page loads become noticeably slower because Happy Eyeballs waits before falling back to IPv4. Separate IPv6 monitoring detects the drop in IPv6 connections within an hour, the rules are restored, and load times return to normal without any DNS change.