Recognize a partial dual-stack outage
A site can work over IPv4 while failing for IPv6-capable visitors. Record whether the failure affects all users or only some networks, then test A and AAAA independently. Do not treat one successful IPv4 browser test as proof that the service is globally reachable.
Check the AAAA record first
Use DNS Lookup to confirm the AAAA record belongs to the intended hostname, is current and points to an address assigned to the service. Look for stale records from an old host, a copied address, an unintended CDN target or a record published before the server was ready.
Verify IPv6 routing and listening
An address in DNS does not prove that packets can reach the host. Confirm the provider has assigned the address, the route is advertised, the server listens on IPv6 and the web service is bound to the expected interface and port. Check the host and upstream network separately.
Review IPv6 firewall policy
Inspect cloud security groups, host firewalls, CDN rules, load balancer listeners, allowlists and rate limits for IPv6 independently from IPv4. A rule that permits 0.0.0.0/0 does not necessarily permit IPv6 traffic. Make sure monitoring and abuse controls do not reject legitimate IPv6 clients.
Test TLS, SNI and virtual hosting
The certificate must cover the hostname on both address families. When a request arrives over IPv6, SNI must select the same intended virtual host as IPv4, and redirects must use the correct canonical URL. Test the hostname, not only the literal IPv6 address, because TLS and virtual hosting depend on the name.
Check CDN and load balancer behavior
Confirm the edge publishes the intended AAAA record, accepts IPv6 clients and can reach the origin through its configured path. The edge may support IPv6 while the origin, health check or private network does not. Compare direct, proxied and origin-side observations only when authorized.
Decide whether to fix or remove AAAA
If IPv6 is ready, correct the route, listener, firewall or proxy configuration and retest end to end. If IPv6 is not ready, temporarily remove the unreachable AAAA record rather than leaving a known broken path. Restore it only after external IPv6 tests, TLS and application checks pass.
Use a repeatable dual-stack workflow
Query A and AAAA; test IPv4 and IPv6 from suitable networks; compare status, response time, certificate and redirects; inspect IPv6 client addresses in logs; check CDN and origin health; then retest after DNS and CDN caches update. Record the old AAAA value before making a change so rollback is possible.
Common mistakes and limits
Do not assume IPv4 success proves IPv6 health, rely on every client to fall back from a broken AAAA, or publish an address copied from another environment. Public diagnostics show one network’s view; confirm important conclusions with the hosting, network or CDN provider.
Check real data now
Use the live IIPP tool to inspect the domain or IP address you are working with.
DNS Record Lookup →