Skip to content

DNS A vs AAAA records

In-Depth Technical Comparison & Architecture Guide

Publishing both an A and an AAAA record for the same hostname (dual-stack) is standard modern practice, but the real engineering problem it creates — a client racing to figure out which protocol actually works, quickly, without a slow timeout on a broken path — was significant enough to need its own dedicated IETF algorithm, Happy Eyeballs, which is the part of this story most A-vs-AAAA comparisons skip entirely.

Quick Reference Matrix

MetricA RecordAAAA Record
Address Format32-bit IPv4 (e.g. 192.0.2.1)128-bit IPv6 (e.g. 2001:db8::1)
StandardRFC 1035RFC 3596
Bit Size32 bits128 bits
Client Selection When Both ExistRaced against AAAA via Happy Eyeballs (RFC 8305)Raced against A via Happy Eyeballs (RFC 8305), given a small head start
Historical Risk If BrokenN/A — universally reliablePre-Happy-Eyeballs: long hang on broken IPv6 paths

Technology Overview

An A record resolves a hostname to a 32-bit IPv4 address (RFC 1035), the original and still near-universally-supported address format. An AAAA record (RFC 3596) resolves the same kind of hostname-to-address mapping to a 128-bit IPv6 address instead — four times the bit-width of IPv4, which is where the name comes from (four A's, for quadruple-A).

Modern dual-stack practice publishes both record types for the same hostname simultaneously wherever infrastructure supports it, letting a client choose whichever protocol it can actually use. This sounds simple, but it created a real, specific problem in the 2000s and early 2010s known informally as 'IPv6 brokenness': some networks advertised IPv6 connectivity that was actually broken or badly performing (misconfigured tunnels, dead-end routes), and a client naively trying the AAAA-resolved address first would hang for a long timeout before falling back to the working IPv4 address — a genuinely bad user experience that discouraged sites from publishing AAAA records at all, which in turn slowed real-world IPv6 adoption.

The IETF's answer to this specific problem is RFC 8305, 'Happy Eyeballs v2': rather than trying one address family and waiting for it to fail before trying the other, a Happy-Eyeballs-compliant client starts connection attempts to both the IPv6 and IPv4 addresses nearly simultaneously (with IPv6 typically given a small head start), and uses whichever connection actually succeeds first. This is precisely what makes dual-stack publishing safe and fast in practice today, and it's why 'just add an AAAA record' stopped being a UX risk once Happy Eyeballs became widely implemented in modern operating systems and browsers.

How Happy Eyeballs Actually Solves the Dual-Stack Race

When a dual-stack-aware client resolves a hostname with both A and AAAA records, it doesn't pick one address family and wait for failure — it launches connection attempts to the IPv6 address and (after a short, deliberately brief delay, commonly around 250ms per RFC 8305's recommendation) the IPv4 address as well, then uses whichever one establishes a working connection first, immediately abandoning the other attempt.

This is exactly why publishing an AAAA record for a domain no longer carries the 'might make my site slow for some users' risk it once did: a client running a Happy-Eyeballs-compliant stack will fall back to IPv4 within a few hundred milliseconds if IPv6 is broken for that specific network path, rather than hanging for the many-second timeout that made early IPv6 adoption a real user-experience gamble.

Address Format and Practical Consequences

IPv4 addresses (32 bits) are conventionally written in dotted-decimal notation (192.0.2.1); IPv6 addresses (128 bits) are written as eight groups of hexadecimal digits separated by colons, commonly compressed using :: to represent one run of consecutive zero groups (2001:db8::1). This compression, along with the raw address length, is why IPv6 addresses are harder to read and transcribe by hand than IPv4 addresses — a genuine, if minor, usability regression that IPv6 accepts in exchange for its vastly larger address space.

See IPv4 vs IPv6 for the broader protocol-level comparison (address exhaustion, header simplification, and the actual current status of the mandatory-IPsec claim some older sources repeat) — this comparison focuses specifically on the DNS record types themselves and the client-side resolution behavior that makes publishing both safely possible.

A Record Advantages & Disadvantages

Advantages / Pros

  • Universal compatibility with every IPv4-capable client and network.
  • Shorter, easier-to-read and transcribe address format.

Disadvantages / Cons

  • Bound by IPv4's finite, exhausted address space, often requiring NAT.

AAAA Record Advantages & Disadvantages

Advantages / Pros

  • Effectively unlimited address space, no NAT required.
  • Now safe to publish alongside an A record thanks to Happy Eyeballs (RFC 8305).

Disadvantages / Cons

  • Longer, harder-to-read address format.
  • Still depends on the client and network path actually supporting working IPv6.

Real-World Use Cases

A Record

Any public-facing hostname

Still required as a baseline for universal client compatibility, IPv6 adoption notwithstanding.

AAAA Record

Dual-stack publishing for modern infrastructure

Published alongside an A record so IPv6-capable clients can use it, safely, thanks to Happy Eyeballs fallback.

Developer Recommendation

Publish both A and AAAA records for any public-facing hostname where your hosting infrastructure supports IPv6 — modern Happy-Eyeballs-compliant clients make this safe, with automatic, fast fallback to IPv4 if a specific network path's IPv6 is broken.

Don't withhold an AAAA record out of outdated caution about 'IPv6 brokenness' — that specific risk was the direct target of RFC 8305's Happy Eyeballs algorithm, which is now broadly implemented in modern operating systems and browsers.

Continue treating the A record as non-negotiable — IPv4 remains universally supported, and no production public hostname should rely on IPv6 alone.

Frequently Asked Questions

What does AAAA stand for?
The four As represent the quadrupled address size — 128 bits for IPv6 versus IPv4's 32 bits (32 x 4 = 128), which is also the origin of the name itself.
Is it risky to add an AAAA record if my IPv6 setup might be broken for some users?
Much less risky than it used to be — the Happy Eyeballs algorithm (RFC 8305), now broadly implemented in modern browsers and operating systems, races IPv4 and IPv6 connection attempts nearly simultaneously and falls back within a few hundred milliseconds if IPv6 fails for a given network path.
What is the Happy Eyeballs algorithm?
An IETF-specified client behavior (RFC 8305) that starts connection attempts to both a hostname's IPv6 and IPv4 addresses nearly simultaneously, using whichever succeeds first — designed specifically to prevent the long hangs that occurred when a client tried a broken IPv6 path before falling back to IPv4.
Should I configure both A and AAAA records, or just one?
Configure both wherever your infrastructure supports IPv6 — dual-stack publishing is standard modern practice, and Happy Eyeballs makes it safe for clients regardless of whether IPv6 actually works on a given network path.
Why is an IPv6 address harder to read than an IPv4 address?
IPv6's 128-bit address is written as eight groups of hexadecimal digits (versus IPv4's four decimal groups), and while :: compression shortens runs of zero groups, the format remains longer and less immediately readable than IPv4's dotted-decimal notation.
Does having an AAAA record slow down IPv4-only clients?
No — a client with no IPv6 support simply doesn't attempt the AAAA address at all and uses the A record directly, with no meaningful delay from the AAAA record's mere presence.

Part of the Domain Name System (DNS) Developer Hub

This comparison is part of our Domain Name System (DNS) topic guide, covering related tools, standards, and decision guidance.