IPv6 and dual-stack sites: what changes for uptime and DNS monitoring

Global IPv6 adoption crossed 50% in April 2026, per Google's own IPv6 statistics. Dual-stack, a site reachable over both IPv4 and IPv6, is now the majority real-world condition, not an edge case. That changes what an uptime or DNS monitoring setup actually needs to check, because a broken IPv6 path fails in a way a typical single-protocol check cannot see at all.

The failure mode a single-protocol check misses entirely

Modern browsers use Happy Eyeballs (RFC 8305, the successor to RFC 6555): a dual-stack client races an IPv4 and an IPv6 connection attempt in parallel and uses whichever responds first, preferring IPv6 when both succeed. In practice this means the browser opens both connection attempts almost simultaneously, staggered by a short interval, and simply keeps whichever one completes first, closing the other. When both paths are healthy, this is invisible, IPv6 usually wins the race and the visitor never knows a race happened at all.

When the IPv6 path is degraded, not fully down, just slow or intermittently failing, the client does not error out. It waits for IPv6 to time out, roughly 250ms or more, then falls back to the IPv4 attempt that was racing alongside it, and the page loads. The visitor experiences a delay, not an error, and nothing in their browser or in a typical error log flags which protocol actually served the page.

To the visitor on that IPv6-preferring network, the site is slow. To an uptime monitor checking only over IPv4, which is the default for most tools, the site is up the entire time, because it is, over IPv4. A meaningful share of real visitors experiences a real, repeatable slowdown that never once shows up as a failed check, an incident, or an alert. This is not a corner case: with over half of global traffic now IPv6-capable, a degraded IPv6 path affects a real, non-trivial fraction of visits, invisibly, for as long as the monitoring only looks at one protocol.

What a monitoring setup needs to do differently

• Check both protocols independently, not just whichever one a monitor defaults to: a check that only ever connects over IPv4 structurally cannot detect an IPv6-specific problem, no matter how sophisticated the rest of the check is, because it is testing a path the affected visitors are not actually using
• Treat "IPv6 slow, IPv4 fine" as its own alertable condition: not a full outage, but a real degradation worth surfacing separately from a binary up/down signal, since it affects real visitors without ever crossing the threshold that trips a standard uptime alert, and a team that only watches for full outages will never see this pattern form
• Watch AAAA records with the same discipline as A records: a stale AAAA record pointing at a decommissioned IPv6 address, or one added and then never validated, breaks the IPv6 path exactly the way a bad A record breaks the IPv4 path, but is far more likely to go unnoticed since fewer people are watching it, and fewer tools default to checking it at all
• Do not assume dual-stack is a one-time setup task: a working configuration today can drift: a load balancer reconfigured for IPv4 only, a firewall rule added without an IPv6 equivalent, a CDN edge that silently drops IPv6 support during a migration, none of which touch the IPv4 path at all, so nothing about the IPv4-only view of the system changes even as the IPv6 path quietly stops working

The DNS half of the problem

Every one of those failure modes traces back to DNS in some way. A site advertising an AAAA record commits to actually serving that address; a record pointing nowhere real, or to something no longer listening, is worse than not publishing IPv6 at all, since it invites a connection attempt that then fails or times out rather than falling through cleanly. A common way this actually happens: a server migration updates the A record to the new host's IPv4 address, since that is the address most runbooks and migration checklists explicitly call out, while the AAAA record is left pointing at the old host's IPv6 address, either because the old host is being decommissioned on a slower timeline or because the migration checklist itself never mentioned IPv6 at all. The site keeps working perfectly over IPv4 while quietly breaking for every IPv6-preferring visitor.

Watching for AAAA changes with the same rigor as A record changes, not as an afterthought, is the DNS-side half of taking dual-stack seriously. This means treating a changed or missing AAAA record as worth the same attention as a changed A record, rather than a secondary detail nobody reviews until a visitor complains.

What WebPixie actually does here

WebPixie's DNS monitoring tracks A and AAAA records among its 20+ monitored record types, surfacing the old and new value whenever either changes, so a drifting or stale IPv6 address does not go unnoticed the way it would on a check that only watches the IPv4 side. Uptime monitoring confirms reachability against the address a check actually resolves and connects to. And since a check can target a literal IP address with a matching custom Host header, you can verify each protocol independently by pointing one check at the A record's address and another at the AAAA record's, rather than relying on whichever one DNS resolution and Happy Eyeballs would pick automatically. For planning or auditing IPv6 address blocks directly, the IP subnet calculator works for both IPv4 and IPv6 CIDR ranges, useful when reasoning through how an IPv6 allocation is actually laid out before wiring monitoring around it.