AAAA: IPv6 address record

One name → one IPv6 address. Same role as A, for IPv6. AAAA is pronounced "quad-A," and the name has four A's because the address it holds is four times the size of an IPv4 address (32 → 128 bits).

In one line:

neal.example.isitdns.net.    AAAA    2001:db8::7
└── this name ──────────┘   └type┘  └── lives at this IPv6 address

What it holds#

A 128-bit IPv6 address. On the wire the RDATA is the raw 128 bits in network byte order (RFC 3596 §2.2); zone files and tool output render it in the canonical text form of RFC 5952 (lowercase hex, leading zeros dropped, longest zero run collapsed to ::):

2001:db8::1

2001:db8::1 is the IPv6 address this name points to: the same idea as an A record, with a bigger address.

As with A, a name can have multiple AAAA records. Clients use whichever combination of A + AAAA they prefer (Happy Eyeballs: the client queries both record types but gives IPv6 a head start. If the A answer arrives first, the client still waits ~50ms for the AAAA (the Resolution Delay), then the IPv6 connection attempt starts first; IPv4 only begins if IPv6 has not succeeded after ~250ms, per RFC 8305 §§3 and 5).

When to use it#

• Always, on any name that has IPv6 connectivity. Lots of clients prefer IPv6 by default. Whether you have usable IPv6 depends entirely on the ISP: some delegate a generous prefix (several /64s via DHCPv6-PD), some hand out a single /64, and some offer none at all. RFC 6177 recommends end sites get significantly more than a single /64 (a site implies multiple subnets) but deliberately declines to name one size for every site; /48 and /56 are both common in practice.
• At the zone apex: same as A, valid choice for the bare name.
• For dual-stack endpoints: define both A and AAAA. Clients pick the winner.

When not to use it#

• Don't publish AAAA pointing to addresses that aren't actually reachable. Clients that "have IPv6" will try AAAA first; if it's broken they fall back to A after a delay, hurting startup latency. (This is a real, well-documented failure mode: the "broken IPv6" problem.)
• For aliasing: use CNAME.

dig example#

$ dig @1.1.1.1 example.isitdns.net AAAA

The learning zone uses a documentation address (RFC 3849) for illustration; the address is not routable.

dig @1.1.1.1 example.isitdns.net AAAA +short

2001:db8::1

nslookup -type=AAAA example.isitdns.net 1.1.1.1

Server:		1.1.1.1
Address:	1.1.1.1#53

Non-authoritative answer:
Name:	example.isitdns.net
Address: 2001:db8::1

The Non-authoritative answer: header is normal here: 1.1.1.1 is a recursive resolver relaying the zone's data, not one of the zone's authoritative servers, so the aa flag is not set.

Watch both at once with dig +short:

dig @1.1.1.1 example.isitdns.net A    +short
dig @1.1.1.1 example.isitdns.net AAAA +short

192.0.2.1
2001:db8::1

nslookup -type=A    example.isitdns.net 1.1.1.1
nslookup -type=AAAA example.isitdns.net 1.1.1.1

Non-authoritative answer:
Name:	example.isitdns.net
Address: 192.0.2.1

Non-authoritative answer:
Name:	example.isitdns.net
Address: 2001:db8::1

(Each nslookup run also prints the Server: / Address: header shown earlier; it is trimmed here.)

See it live: isitdns.net/#dig?name=example.isitdns.net&qtype=AAAA

Defined by: RFC 3596 §2.2 (AAAA RDATA format)

DoH query (HTTPS)#

DoH is DNS-over-HTTPS. The JSON API (a Cloudflare/Google extension, not part of RFC 8484) is the easiest to inspect:

curl -s -H 'accept: application/dns-json' \
  'https://cloudflare-dns.com/dns-query?name=example.isitdns.net&type=AAAA' \
  | jq .Answer

[
  {
    "name": "example.isitdns.net",
    "type": 28,
    "TTL": 300,
    "data": "2001:db8::1"
  }
]

"AD": true in the full response means the resolver validated the DNSSEC chain for this answer (RFC 4035 §3.2.3); you are trusting 1.1.1.1's validation rather than doing your own.

nslookup cannot do DoH/DoT/DoQ, use dig or curl instead. On Windows 11, Resolve-DnsName uses the system-configured DoH resolver when the OS is set up for encrypted DNS; it does not accept a -DnsOverHttps parameter or let you specify an arbitrary DoH endpoint. To probe a specific DoH service, use the curl examples above (or a third-party tool like kdig).

dig +https (wire-format DoH via dig) requires dig 9.18 or later. Use the curl form above if your system dig is older.

Gotchas#

• Record type and transport are independent. An AAAA record does not mean the DNS query travels over IPv6. An IPv4-only client can fetch AAAA records (this page's dig examples do exactly that when run from an IPv4 host), and resolvers routinely serve A records over IPv6 transport. The record describes the target address family, not the lookup's.
• Happy Eyeballs masks broken AAAA. Apps that "feel slow" sometimes have a broken AAAA: IPv6 gets the first connection attempt; if it does not complete within the ~250ms Connection Attempt Delay (RFC 8305 §5), IPv4 kicks off and the client takes whichever succeeds first. A consistently losing IPv6 path means every connection pays that delay. Use dig for both records and verify reachability with ping -6 (ping6 on older systems) before publishing.
• Reverse zones for IPv6 are painful. See the ip6.arpa breakdown: 32 single-character labels per address.
• EDNS / response size. A response carrying multiple AAAA records can exceed the classic 512-byte UDP limit faster than A. EDNS0 raises the limit; if EDNS is stripped en route, large responses get truncated and clients retry over TCP (tc=1 flag). See wireshark-dns-filters for EDNS capture filters.
• Proxied records. When a managed DNS provider proxies a record, querying AAAA returns the provider's anycast IPv6 addresses, not what you configured in your zone.

See also#

• A: the IPv4 counterpart
• PTR in .ip6.arpa: IPv6 reverse
• Reverse DNS: in-addr.arpa and ip6.arpa
• All record types: cheat sheet
• DNS over HTTPS and TLS (DoH/DoT)
• DNSSEC: signing and validation
• nslookup and dig: command reference
• Wireshark DNS filters