AAAA Records: When to Use IPv6 DNS and Troubleshooting Tips
AAAA records publish IPv6 addresses for a hostname so clients can reach your service over IPv6. When you add them alongside A records, most modern stacks will try both families and pick whichever connects first, often with a small head start that favors quick paths. That means an AAAA that points to a slow or broken route can hurt user experience even if IPv4 still works.
The good news is that dual-stack is predictable once you check a few basics: global routing, firewall policy, and whether your app tiers (origin, CDN, API, auth) are reachable over IPv6 with similar performance to IPv4. If those align, adding AAAA is usually a low-drama change that reduces NAT pain and future-proofs your footprint.
Below we unpack what AAAA records do, when to publish them, and how to test, validate, and debug common dual-stack issues like slow fallback, misrouted prefixes, and black-holed MTU.
What AAAA Records Do
An AAAA record maps a hostname to a 128-bit IPv6 address, just as an A record maps to IPv4. Resolvers cache both, and clients implement connection logic—often called Happy Eyeballs—that races IPv6 and IPv4 to reduce delay. If IPv6 is healthy and close in performance, users will ride it by default; if not, they’ll fall back after a small threshold. Your job is to make IPv6 as reliable and fast as IPv4 so the race picks the right path without human help.
How Clients Choose Between IPv6 and IPv4
Modern clients prefer lower connection setup time, not a hard IPv6-first rule. They may start IPv6 and then IPv4 a short time later, adopting whichever completes first. That’s why small problems on IPv6—extra RTT, bad PMTUD, or an overloaded anycast POP—show up as “sometimes slow” rather than full outages.
When to Publish IPv6
Publish AAAA for public web properties when your provider or CDN advertises stable IPv6 routes globally and your origin is reachable over IPv6 with similar latency to IPv4. Check that your firewall allows required ports on IPv6 and that ICMPv6 is not blocked, because path MTU discovery needs Packet Too Big messages to avoid fragmentation black holes.
Web and APIs
If you front with a CDN, enabling IPv6 at the edge is often a toggle. Ensure the origin also supports IPv6 or that the CDN can proxy IPv6 clients to an IPv4 origin. Measure TLS handshake time and first byte across both families and compare. Do not publish AAAA for internal-only hostnames or admin panels unless their ACLs and routability are ready on IPv6 as well.
Email and MX
For mail, adding AAAA to MX targets invites senders to use IPv6. Only publish when your SMTP listener, spam filters, and reverse DNS are correct on IPv6. If you can’t monitor and rate-limit over IPv6 yet, keep MX on IPv4 and phase in later.
Validation and Monitoring
Before rollout, resolve your hostnames from multiple networks and confirm AAAA visibility, TTLs, and DNSSEC if used. Compare connect times and error rates per address family in your logs. After rollout, watch the fallback rate—how often clients abandon IPv6 for IPv4—and alert if it spikes in a region, which often signals a routing change upstream.
Happy Eyeballs Signals to Track
Instrument handshake duration, TCP resets, TLS alerts, and HTTP 0-RTT success by family. A widening gap between IPv6 and IPv4 setup times usually points to path or PMTUD issues, not DNS. Keep per-POP or per-ASN views so you can distinguish a single carrier problem from a global event.
Reverse DNS for IPv6
IPv6 PTR records live under ip6.arpa using a nibble format, one hex digit per node of the reverse name. For email and some APIs, forward-confirmed reverse DNS helps with reputation. Make sure PTRs resolve to a hostname that in turn resolves back to the same address to avoid noisy warnings and false positives in filters.
Common Failure Modes and Fixes
Blocked ICMPv6: Packet Too Big messages dropped by a firewall cause stalls on large responses. Allow essential ICMPv6 types end to end.
Asymmetric Or Misrouted Prefixes: An upstream might prefer a long, congested path to your /48. Compare routes by ASN and adjust advertisements or engage your provider to fix leaks.
MTU Mismatch: Tunnels or overlays with small MTU can black-hole traffic. Set correct interface MTU and verify end-to-end PMTUD.
Anycast Hotspot: One POP attracts too much IPv6 traffic versus IPv4 due to policy differences. Balance announcements and monitor per-POP latency.
Stale AAAA In Caches: After a change, long TTLs can keep bad addresses alive. Use short TTLs during migrations and raise them later.
Origin Not Listening On IPv6: CDN edge has IPv6 but origin is IPv4-only. Ensure the CDN proxies across families or dual-stack the origin.
Deployment Tips That Usually Work
Roll out in slices. Start with a low TTL and enable AAAA in one region or property, then expand as metrics look good. Keep per-family SLOs so a regression on IPv6 is detectable even when overall success looks fine. Document how to bypass IPv6 temporarily on support calls so users aren’t blocked while you investigate.
Records, TTLs, and Zoning
Keep A and AAAA records aligned across zones and views. Use consistent TTLs so caches don’t favor one family for hours. If you run DNSSEC, sign new AAAA sets and check the chain before publishing widely.
Observability and Runbooks
Log the client address family at the edge and tag synthetic probes with v4 and v6. Build a short runbook for PMTUD tests, traceroute over IPv6, and how to toggle anycast announcements if a POP misbehaves. Train on interpreting reverse DNS for IPv6 so on-call can match addresses to services quickly.