Records

AAAA: IPv6 address record

One record → one IPv6 address (RFC 3596 §2). Same role as A, for IPv6.

In one line:

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


Type number	28
RFC	3596
RDATA	A single IPv6 address (128 bits)
Reverse counterpart	PTR in `.ip6.arpa`

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 ::), for example 2001:db8::1. As with A, a name can carry more than one AAAA record.

When to use it#

Any name with real, working IPv6 connectivity. Most OS resolvers prefer a matching IPv6 address over IPv4 when both are offered (RFC 6724 §2.1).
At the zone apex, same as A.
For dual-stack endpoints, publish both A and AAAA. The client picks.

When not to use it#

Don't publish AAAA pointing at an address that isn't actually reachable. Clients try it first and only fall back to A after a delay (see Gotchas).
For aliasing, use CNAME.

dig example#

Asks example.isitdns.net for its IPv6 address.

$ dig @1.1.1.1 example.isitdns.net AAAA

; <<>> DiG 9.20.11-0ubuntu0.2-Ubuntu <<>> @1.1.1.1 example.isitdns.net AAAA

; (1 server found)

;; global options: +cmd

;; Got answer:

;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 63154

;; flags: qr rd ra ad; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:

; EDNS: version: 0, flags:; udp: 1232

;; QUESTION SECTION:

;example.isitdns.net. IN AAAA

;; ANSWER SECTION:

example.isitdns.net. 300 IN AAAA 2001:db8::1

;; Query time: 33 msec

;; SERVER: 1.1.1.1#53(1.1.1.1) (UDP)

;; WHEN: Mon Sep 14 13:45:34 CDT 2026

;; MSG SIZE rcvd: 76

GO NOERROR, one AAAA record, 2001:db8::1

NO GO NOERROR with no answer, which means the name has no IPv6 address

run this query in the dig tool →

what each part of this output means →

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

DoH query (HTTPS)#

DoH is DNS-over-HTTPS. The JSON form used here is a Cloudflare/Google extension, not part of RFC 8484 itself:

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 1.1.1.1 validated the DNSSEC chain for this answer (RFC 4035 §3.2.3); you are trusting its validation, not doing your own.

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, 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. A client queries both A and AAAA, giving IPv6 a head start (RFC 8305 §3): if the A answer arrives first the client still waits the ~50ms Resolution Delay for AAAA, then IPv6 gets the first connection attempt; IPv4 only starts if IPv6 has not succeeded within the ~250ms Connection Attempt Delay (RFC 8305 §5). A consistently losing IPv6 path means every connection pays that delay, which reads as an app that "feels slow." Verify reachability with ping -6 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).
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.