Your Website Works on IPv4 — But What Do IPv6 Users See?
An AAAA record can open a second production path. Audit DNS, reachability, TLS, redirects, and security controls separately across IPv4 and IPv6.
Your website is online, monitoring is green, and everything works from your office network. Yet one customer reports that the site fails on mobile data.
One possible cause sits in a layer many website reviews never test separately: IPv4 and IPv6 can send the same hostname through two different production paths.
An A record publishes an IPv4 address. RFC 3596 defines the AAAA record for IPv6 addresses. Once both exist, DNS tells clients that the host is reachable over both protocol families. Whether both paths actually deliver the same working website is a separate question.
Happy Eyeballs can hide a fault — not fix it
Dual-stack clients need to choose between possible IPv4 and IPv6 destinations. RFC 6724 describes default address selection. RFC 8305 adds the Happy Eyeballs approach, coordinating A and AAAA results and connection attempts so that blocked, broken, or slow address paths cause less user-visible delay.
That is good for users. It can hide a production defect from operators. RFC 8305 explicitly discusses "Hostnames with Broken AAAA Records": a valid A record exists, the AAAA record looks valid, but the IPv6 address never responds on the normal service ports. The RFC lists DNS-zone typos, routing black holes, and service outages as example causes.
A browser may fall back to IPv4 in some dual-stack situations. That does not prove IPv6 is healthy. On IPv6-only or NAT64/DNS64 networks, a broken AAAA path can also have more serious consequences.
Red flag 1: A and AAAA lead to different production versions
The two addresses do not need to terminate on the same physical server. The resulting service should, however, be intentionally equivalent.
A common migration failure looks like this: the A record moves to the new hosting provider while the AAAA record still points at the previous environment. Both servers answer, so there is no obvious full outage. Different users simply receive different releases.
A security split is worse: A points to a CDN or WAF while AAAA still points directly to the origin. IPv4 visitors receive edge rate limits, bot controls, caching, or security headers while IPv6 bypasses part of that layer. IPv6 is not the security weakness. The inconsistent route is.
Red flag 2: DNS works but HTTPS does not
A reachable IPv6 address is not the same as a working web service. Test both families for at least:
- port 443 reachability,
- correct virtual-host and SNI behavior,
- the expected valid certificate and complete chain,
- consistent HTTP-to-HTTPS redirects,
- the intended canonical target for the apex domain and
www, - the same application version and critical response headers.
An old IPv6 server can be reachable while serving the wrong certificate or a stale website. DNS and ping can still look reassuringly healthy.
Red flag 3: "IPv6 enabled" is not an architecture
A request can cross several layers: browser → CDN → load balancer → reverse proxy → application. Not every internal hop has to use IPv6. What matters is knowing where IPv6 terminates and what takes over afterwards.
AWS documents separately which Route 53 targets support A and AAAA records; for an IPv6-enabled CloudFront distribution, for example, it documents A and AAAA alias records. The broader operational rule is provider-independent: the DNS record, its target resource, and that resource's real IPv6 capability must agree.
Red flag 4: Firewall and allowlist behavior was tested only on IPv4
Network controls often evolve separately. Port 443 may be allowed over IPv4 while the equivalent IPv6 rule is absent. Or an administrative route may accidentally be more open over IPv6.
Review:
- inbound rules for both families,
- rate limiting and abuse protection,
- proxy and client-IP handling,
- IPv6 logging and parsing,
- IP-based allowlists and denylists,
- direct origin reachability outside the intended CDN or WAF path.
IPv6 is not inherently less secure. Inconsistent controls are.
Red flag 5: Monitoring checks only "the domain"
A check against https://example.com does not automatically tell you which address family the monitoring agent used. Happy Eyeballs can even route around a broken family and make the check look healthy.
A useful audit separates three views:
DNS
What A and AAAA records do the authoritative nameservers publish? Are stale targets, unexpected TTLs, or forgotten subdomains present?
Network
Can the hostname be reached deliberately over IPv4 and deliberately over IPv6?
Application
Do both paths return the same expected status, redirect, release marker, TLS state, and relevant security headers?
A 200 OK is not enough if IPv6 is still serving last quarter's website.
A practical dual-stack audit
- Inventory A, AAAA, CNAME, and alias targets for the apex domain,
www, application, API, login, checkout, and other critical hosts. - Force tests separately over IPv4 and IPv6 rather than relying only on browser defaults.
- Compare TLS, status codes, redirect chains, HTML or release version, cache and security headers, and CDN/WAF markers.
- Exercise the failure path: what happens when only IPv6 breaks?
- Monitor important services with at least one explicit IPv4 and one explicit IPv6 check.
Differences are not automatically defects. They do need to be intentional, documented, and operable.
Does every website need IPv6 immediately?
No. A stable IPv4-only service is better than a half-configured dual-stack deployment. If your infrastructure cannot support IPv6 reliably yet, publishing no AAAA record is more honest than publishing a destination that does not work.
The reverse is equally important: once an AAAA record is public, IPv6 is part of your production surface.
What Website-Pflichtencheck would inspect
A hosting and reachability review can inventory A and AAAA resolution separately, force independent IPv4 and IPv6 connections, and compare TLS, redirects, HTTP responses, security headers, and CDN or reverse-proxy behavior.
We can also identify stale IPv6 destinations left after migrations, AAAA records that bypass the intended WAF path, firewall policies that differ between address families, and monitoring that would never notice a one-family outage.
The goal is not IPv6 at any cost. It is a clear production contract: every address your DNS advertises should lead to a route you understand, monitor, and operate.
If your website appears reliable only because browsers politely route around a broken network path, that is not a redundancy strategy. It is a defect being hidden by a helpful client.
Sources
- RFC 3596: DNS Extensions to Support IP Version 6 — https://www.rfc-editor.org/rfc/rfc3596.html
- RFC 6724: Default Address Selection for Internet Protocol Version 6 — https://www.rfc-editor.org/rfc/rfc6724.html
- RFC 8305: Happy Eyeballs Version 2 — https://www.rfc-editor.org/rfc/rfc8305.html
- Amazon Route 53: Supported DNS record types — https://docs.aws.amazon.com/Route53/latest/DeveloperGuide/ResourceRecordTypes.html