IPv6 and dual-stack DNS

AAAA records and dual-stack delivery, happy eyeballs, IPv6-only clients behind NAT64 and DNS64, and how to test whether a site really works over IPv6.

AAAA records and dual stack

; serve both families from the same name
www   IN  A     203.0.113.10
www   IN  AAAA  2001:db8:abcd::10

; never point an AAAA at a family that cannot serve the traffic
; a broken IPv6 path is worse than no IPv6 at all

• A host with both records is dual stacked. A host with only AAAA is IPv6-only and will be unreachable from an IPv4 client unless a translator is in the path.
• Publish AAAA only when the service genuinely listens on IPv6 everywhere - origin, load balancer, firewall and CDN must all agree.
• An IPv6 address in the 2001:db8::/32 range is documentation only and never routable; using it in a real zone is a common copy-paste error.

dig AAAA www.example.com +short
dig A    www.example.com +short

# does the site actually serve over IPv6?
curl -6 -sIv https://www.example.com -o /dev/null
curl -4 -sIv https://www.example.com -o /dev/null

# which family did the client actually choose?
curl -6 -s https://www.example.com -o /dev/null -w 'ipv6 connect: %{time_connect}\n'

How clients choose

When both families resolve, clients use an algorithm commonly called happy eyeballs: they start the connection over one family and, if it does not complete quickly, race the other. The practical consequence is that a partially broken IPv6 path does not always look broken - it looks slow, and only for some users.

1. Publish AAAA on a low-TTL record and watch error rates for a day before making it permanent.
2. Verify from an external IPv6-only test service, not just from your own machine.
3. Check that the load balancer health check covers IPv6 as well as IPv4; a healthy IPv4 check says nothing about the other family.
4. Watch the latency metrics, not just the error rate. A broken IPv6 path shows up as slower connections and abandoned requests, not as failures.

NAT64, DNS64 and IPv6-only networks

How an IPv6-only client reaches an IPv4-only site

  1. client asks for AAAA
  2. DNS64 resolver finds no AAAA, only an A
  3. resolver synthesises a AAAA from the well-known prefix 64:ff9b::/96
     plus the IPv4 address
  4. NAT64 gateway translates that address and forwards the connection

Consequences
  an IPv6 host must not publish a fake AAAA - it would win the lookup
  and then fail, because DNS64 only synthesises when no AAAA exists
  a service that is IPv6-only is invisible to IPv4 clients with no DNS64

The hard rule is that a AAAA record is a promise. Publishing one for a host that cannot accept IPv6 traffic breaks clients that would otherwise have worked over IPv4, and the failure appears only on dual-stack networks - which is most of your users.

FAQ

Related

Anycast, GeoDNS and traffic steering Record types that matter

Last refreshed 2026-09-18.