AAAA Record

An AAAA record is spoken "quad-A". It is the DNS record that maps a hostname to a single 128-bit IPv6 address. It is the IPv6 counterpart of the A record. The A record holds a 32-bit IPv4 address. AAAA is also the only record type still standardised for the job. The rival A6 record was moved to Historic status precisely to clarify "that implementers and operators should represent IPv6 addresses in the DNS by using AAAA records only" (RFC 6563 §1). It is not a translation, proxy or health-checking feature. The record announces an address and nothing else. Publishing one does not prove that anything answers on it. A AAAA pointing at an address with no IPv6 connectivity simply steers IPv6-capable clients onto a path that fails (RFC 4472 §4.3). For CDN work the rule is short. Publish A and AAAA together for every hostname you serve. Make sure both families actually work.

How it works

AAAA is DNS record type 28. Its RDATA is exactly one 128-bit IPv6 address "in network byte order (high-order byte first)". That is 16 bytes, against the A record's 4 (RFC 3596 §2.1, §2.2; RFC 1035 §3.4.1; IANA DNS parameters).

• One address per record. "A host that has more than one IPv6 address must have more than one such record" at the same name (RFC 3596 §2).
• A type-AAAA query returns every AAAA record at that name in the answer section. It triggers no additional-section processing (RFC 3596 §2.3). No single query returns A and AAAA together. A client that wants both makes two queries.
• The query is independent of the transport carrying it. "IPv4 transport can be used to query IPv6 records and vice versa" (RFC 3596 §1).
• Reverse mapping uses a different record in a different tree. PTR records live under IP6.ARPA, the address written as dot-separated hexadecimal nibbles in reverse order (RFC 3596 §2.5). Publishing an AAAA creates no reverse DNS.
• When a name has A records but no AAAA, the correct answer to a AAAA query is RCODE 0 (no error) with an empty answer section. This tells the client to go and look for A records (RFC 4074 §3). A CDN with IPv6 switched off should behave the same way. CloudFront documents that it does: it "responds to IPv6 DNS requests with the DNS response code NOERROR and with no IP addresses. This allows viewers to submit a second request, for an IPv4 address" (AWS, IsIPV6Enabled).
• Dual-stack clients race the two families using Happy Eyeballs. Both queries go out as close together as possible, "with the AAAA query made first and immediately followed by the A query". A positive AAAA answer starts the IPv6 connection attempt at once. If the A answer arrives first, the client waits a short Resolution Delay. The recommended delay is 50 ms, so that IPv6 keeps its preference. Connection attempts are then staggered rather than simultaneous. They are separated by a Connection Attempt Delay whose recommended default is 250 ms, with a recommended minimum of 100 ms and a current recommended maximum of 2 seconds (RFC 8305 §3, §5).
• DNS cannot pick the family for the client. Publishing both records offers both. The resolver library "MAY order the results returned to the application in order to influence the version of IP packets used". The client makes the final choice (RFC 4213 §2.2). An AAAA record is an offer, not an instruction.

Why it matters for a CDN

IPv6 is now roughly half the audience. The exact figure depends on who is counting. Google's measurement of its own users reached 50% for the first time in April 2026. APNIC Labs' independently weighted measurement recorded 42% global IPv6 capability on the same dates. The two figures "effectively bracket the likely range of actual IPv6 capability" (APNIC, "Google hits 50% IPv6"). A hostname with no AAAA record is unreachable over IPv6 for that population. Every alternative path is worse than a native one.

• On an IPv6-only network the client depends on DNS64 to "synthesize a AAAA record from an A record containing a real IPv4 address of the responder, whenever the DNS64 cannot retrieve a AAAA record for the queried name". A NAT64 translator forwards the packets (RFC 6147 §2). That is an extra box on the path. It is operated by the access network rather than by you.
• Dual-stack clients that find no AAAA fall back to IPv4. Today that is commonly "IPv4 mediated through Network Address Translation (NAT), either in home networks or at the carrier level via Carrier-Grade NAT (CGNAT)" (APNIC).
• Adoption is concentrated where newer operators built IPv6-first. APNIC describes this pattern as "particularly evident in the mobile sector, most notably in large-scale IPv6 deployments such as Reliance Jio's network in India".
• Viewer-to-edge and edge-to-origin are separate decisions. A CDN can serve IPv6 viewers from an IPv4-only origin. APNIC notes this is "visible in the way large content and caching providers, such as Cloudflare, are able to offer dual-stack services regardless of whether the backend systems themselves support both protocols". But the origin family is a configuration setting, not an automatic consequence of publishing an AAAA.
• Apex names can only point at a CDN with address records. That is because "if a CNAME RR is present at a node, no other data should be present" (RFC 1034 §3.6.2). So a CNAME and an AAAA cannot share a name. The AAAA at a zone apex is therefore usually an anycast address. That gives up the provider's own DNS-based steering. With anycast IPs, Fastly warns, "connections select a Fastly POP based on routing decisions made outside of Fastly and over which Fastly has less ability to direct traffic for best performance" (Routing traffic to Fastly).

What CDNs do

• Cloudflare has IPv6 compatibility turned on by default: "when IPv6 compatibility is turned on, Cloudflare auto generates AAAA DNS records to allow IPv6 clients to connect", for the names covered by proxied DNS records. Only Enterprise accounts can customise or turn it off. Where the origin has both families, "Cloudflare will prefer the IPv4 address when connecting to your origin server". For origin software that only understands IPv4-formatted addresses, Pseudo IPv4 (default: off) adds a Class E IPv4 address in a Cf-Pseudo-IPv4 header. It can instead overwrite Cf-Connecting-IP and X-Forwarded-For. The viewer connection itself stays IPv6 (IPv6 compatibility, Pseudo IPv4).
• Amazon CloudFront "supports both IPv4 and IPv6 from clients to AWS edge locations". IPv6 is a per-distribution switch: "in general, you should enable IPv6 if you have users on IPv6 networks who want to access your content." Enabling it does not force IPv6. CloudFront "responds to viewer requests by using IPv4 if our data suggests that IPv4 will provide a better user experience". For custom origins other than Amazon S3 and VPC origins, the origin side is configured separately: IPv4 only (the default), IPv6 only, or dual-stack. If a Route 53 alias points at the distribution and you use alternate domain names, enabling IPv6 also requires a second alias record set. A plain CNAME needs no change (Enable IPv6 for CloudFront distributions).
• Fastly enables IPv6 by default on newly created customer-specific hostnames. It also does so on Fastly-shared hostnames from v.sni onwards alphabetically. Shared hostnames before that point opt in by prefixing the CNAME with dualstack, as in dualstack.j.sni.global.fastly.net. Origin-side IPv6 is configured separately in host settings. For apex domains Fastly lists anycast IPv4 and IPv6 address sets to install as A and AAAA records. If you already use its anycast IPv4 addresses, you must contact support to get the matching IPv6 set (Enabling dualstack connections, Routing traffic to Fastly).

Watch out for

• Misbehaving authoritative servers have three classic failure modes, each with a different effect. Servers that "seem to ignore queries for an AAAA RR" cause "a delay at the stub resolver to fall back to a query for an A RR". Servers that answer RCODE 3 ("Name Error") are worse: "the stub resolver may immediately give up and never fall back". The negative answer is cached. A server that returns a AAAA "with the length of the RDATA being 4 bytes" is publishing nonsense. It does not break IPv4, though, because "the broken response does not affect queries for an A RR of the same name". So the cost is redundant queries, not reachability (RFC 4074 §4).
• Broken AAAA records are "AAAA records that contain seemingly valid IPv6 addresses but those addresses never reply when contacted on the usual ports". They are caused by mistyped zone data, routing black holes or outages. A Happy Eyeballs client on a dual-stack network recovers from these by racing. The clients they actually break are on IPv6-only networks with NAT64 and DNS64. That is because the authoritative server returns a real AAAA, so the resolver never synthesises a translated one (RFC 8305 §7.2).
• Treating an ALIAS-style record as a neutral substitute for anycast A/AAAA at the apex. Fastly "recommends against using these solutions because they often result in inferior performance or interfere with the ability of records to update automatically" (Routing traffic to Fastly).
• Assuming HTTPS/SVCB hints replace address records. The "ipv4hint" and "ipv6hint" keys "convey IP addresses that clients MAY use to reach the service. If A and AAAA records for TargetName are locally available, the client SHOULD ignore these hints" (RFC 9460 §7.3).
• Access controls that pin the viewer's IP address are a risk. AWS is explicit: if you use signed URLs or signed cookies with a custom policy containing the IpAddress parameter, "don't enable IPv6". Split the content across two distributions instead (AWS, IsIPV6Enabled).
• Different TTLs on the A and AAAA at one name are a risk. The shorter-lived record leaves the caches first, opening a window in which only one family is served. Where those records are delegation glue that a resolver cannot query directly, this leads "to a potential operational situation with unreachable servers" (RFC 4472 §4.4).

Best practice

• Add the AAAA only when the address is assigned to the interface, configured on it, and that interface "is on a link that is connected to the IPv6 infrastructure". Then keep the two families at roughly equal quality. That is the harder operational test (RFC 4472 §4.3).
• Publish A and AAAA at the same name with the same TTL. Change them together.
• Verify in two steps, because they prove different things. First, resolve the record (dig example.com AAAA). Then make a real IPv6 connection to the exact hostname (curl -6). This exercises routing, listener, certificate and virtual-host configuration all at once.
• When the origin is IPv4-only, keep the AAAA at the edge and set the edge-to-origin family explicitly. Use Cloudflare's Pseudo IPv4 for origin software that needs IPv4-shaped addresses, or CloudFront's origin IPv4-only / IPv6-only / dual-stack setting. Do not delete the record.
• Before migrating providers or edge addresses, lower the TTL on the existing records. Wait out the old value, switch, then raise it again once traffic has moved. Fastly's own guidance is to drop to around 60 seconds for the migration and "following a successful migration, consider increasing it to an hour or more" (Routing traffic to Fastly).
• Know your provider's switch before you debug DNS. Cloudflare auto-generates AAAA on proxied records. CloudFront makes IPv6 a per-distribution setting. Fastly uses the dualstack CNAME prefix on its older shared hostnames.