Network & Security Published by

IPv6 Troubleshooting: Why an AAAA Record Is Not Enough

Separate DNS publication from real IPv6 connectivity with a reproducible client-to-service troubleshooting sequence.

A published AAAA record tells a client which IPv6 address a hostname advertises. It does not prove that the client has usable IPv6, that the path is reachable, or that the application listens on the advertised address.

When an app works over IPv4 but times out over IPv6, avoid toggling random router settings. Isolate the failing layer.

Follow the path in order

  1. DNS: Query both A and AAAA for the exact hostname. Record the resolver and response time.
  2. Client addressing: Check whether the client has a usable global IPv6 address, a route and DNS resolution. Link-local addresses alone do not establish internet connectivity.
  3. Default route: Check that a router advertisement or equivalent configuration provides a usable route. A delegated prefix and a client address are related but not interchangeable.
  4. Transport: Test TCP connection establishment to the service port over IPv6. An ICMP echo result by itself does not prove HTTP works.
  5. Service: Confirm that the server listens on IPv6 and that its firewall, proxy and TLS virtual host support the same name.
  6. Application: Compare behavior on Wi-Fi and cellular networks and check whether the client prefers IPv6 or falls back to IPv4.

Example diagnostic commands on a supported system:

nslookup -type=AAAA example.com
curl -4 -I https://example.com
curl -6 -I https://example.com

These are examples, not universal commands: curl -6 only succeeds when the operating system and network have working IPv6. An upstream proxy or VPN may change which path gets tested.

Common failure patterns

AAAA exists, but service is down: The browser can try an unreachable address. Fix the route or service, or withdraw the stale AAAA record after confirming its owner.

Router has IPv6, client does not: Check prefix delegation, LAN router advertisements and firewall behavior.

One network works, another fails: Distinguish local access-provider, DNS, VPN and server differences before drawing conclusions.

Start with the NexKit IPv6 and DNS checks, then reproduce findings on the real client. See RFC 8200 for the IPv6 specification.

Boundary: This guide diagnoses public connectivity; it cannot infer a private router’s configuration from a public hostname.