Dual Stack DNS Explained: Running IPv4 and IPv6 Together, Correctly
Publishing both an A and an AAAA record is the easy part. Operating dual-stack correctly — where neither protocol silently masks problems in the other — is where the real discipline lives.
What Dual-Stack Actually Means
Dual-stack is deceptively simple to define and genuinely nuanced to operate well: a hostname (or an entire network) runs IPv4 and IPv6 simultaneously and independently, with neither protocol acting as a fallback or wrapper for the other. In DNS terms, that means a dual-stack hostname publishes both an A record and an AAAA record, and a connecting client picks whichever protocol its own network path supports — commonly negotiated through the Happy Eyeballs algorithm covered in detail below. Nothing about dual-stack requires the two protocols to share infrastructure; a domain's IPv4 and IPv6 traffic frequently take completely different physical paths all the way to origin, sometimes through entirely different edge networks.
Happy Eyeballs: The Algorithm That Makes Dual-Stack Feel Seamless
When a hostname returns both an A and an AAAA record, a modern client doesn't pick one blindly — it uses an algorithm formally defined in RFC 8305 and commonly nicknamed Happy Eyeballs. The client fires off connection attempts to both address families in close succession (typically with IPv6 given a small head start, since it's usually faster where genuinely well-provisioned) and uses whichever completes its handshake first, abandoning the slower attempt. This is precisely why a dual-stack domain with a broken or sluggish IPv6 path can still feel completely normal to end users — Happy Eyeballs quietly falls back to IPv4 within a few hundred milliseconds if IPv6 stalls, masking a real problem that would otherwise be immediately obvious.
That masking effect is exactly why dual-stack requires deliberate operational discipline. A team that only ever observes user-facing behavior will have no visibility into a degrading or broken IPv6 path until it gets bad enough to actually exceed Happy Eyeballs' fallback window — by which point it's likely been quietly hurting a subset of users for some time.
Why Dual-Stack Is the Recommended Default
| Configuration | Reaches IPv4-Only Clients | Reaches IPv6-Native Clients | Typical Fit |
|---|---|---|---|
| IPv4-only | Yes | Yes, via translation/fallback | Legacy or simple setups, leaves latency on the table |
| IPv6-only | No, unless behind a translation gateway | Yes, natively | Internal infrastructure with guaranteed IPv6-capable clients |
| Dual-stack | Yes, natively | Yes, natively | Public-facing internet services — the safest general-purpose choice |
Dual-stack is the safest default for a public-facing hostname specifically because it makes no assumptions about a visitor's network capability — everyone connects over whichever protocol their own path supports, natively, without anyone needing special handling or being excluded.
Migration Strategy: From IPv4-Only to Dual-Stack
Audit Current Infrastructure
Confirm which servers, load balancers, and CDN configurations already support IPv6, and which will need explicit enablement.
Enable IPv6 on Infrastructure First
Get the actual server or service listening on IPv6 and confirm connectivity works before touching public DNS at all.
Mirror Firewall Rules
Duplicate every IPv4 firewall or security-group rule to the IPv6 equivalent — treat this as mandatory, not optional cleanup.
Add AAAA on a Low-Traffic Subdomain First
Validate the entire path on something low-risk before touching the apex domain or www.
Extend Monitoring to Cover IPv6 Explicitly
Add dedicated health checks against the AAAA-resolved endpoint — don't assume existing IPv4 monitoring implicitly covers it.
Roll Out to Production Hostnames
Once the subdomain has run cleanly for a reasonable period, extend AAAA records to the apex domain and any remaining public hostnames.
Monitoring Dual-Stack Correctly
The single biggest monitoring mistake in dual-stack environments is treating IPv6 as implicitly covered by existing IPv4 checks. It isn't — a monitoring probe that only ever connects over IPv4 will report full uptime even during a complete IPv6 outage, because it never actually tests that path. Proper dual-stack monitoring runs two independent probe sets: one explicitly resolving and connecting via the A record, one explicitly resolving and connecting via the AAAA record, with alerting configured separately for each so a protocol-specific degradation doesn't get averaged away or hidden behind an overall "healthy" status.
Security Considerations Unique to Dual-Stack
Running two address families in parallel means two firewall rule sets, two sets of exposed services to audit, and — most commonly overlooked — two independent attack surfaces that need equal scrutiny. A service locked down tightly on IPv4 but left at a permissive default on IPv6 is a genuinely common gap, and it's a serious one, since it effectively creates a second, unguarded path into infrastructure that looks secure when audited only through an IPv4 lens. Any security review of dual-stack infrastructure needs to explicitly validate both stacks independently, never assuming parity without checking.
Common Mistakes in Dual-Stack Deployments
| Mistake | Why It's a Problem |
|---|---|
| Trusting "it works" as proof IPv6 is healthy | Happy Eyeballs can mask a broken IPv6 path for a long time before anyone notices |
| Monitoring only the IPv4 path | An IPv6-specific outage can run completely undetected |
| Incomplete firewall parity between stacks | Creates an unintentionally more permissive path over the less-scrutinized protocol |
| Rolling out AAAA to the apex domain first | Skips the lower-risk validation step a subdomain rollout would have provided |
| Assuming CDN-level IPv6 proxying means origin is IPv6-ready | A proxy can synthesize IPv6 at the edge without the actual backend supporting it at all |
Pros & Cons of Dual-Stack
| Pros | Cons |
|---|---|
| Reaches every visitor regardless of their network's protocol support | Doubles the operational surface — firewalls, monitoring, security audits |
| Often lower latency for IPv6-native visitors versus CGNAT'd IPv4 | Happy Eyeballs can mask a degrading IPv6 path from casual observation |
| Future-facing as IPv6 adoption continues growing | Requires genuinely disciplined, protocol-separated monitoring to operate safely |
| No visitor is excluded during the transition period | More configuration surface for something to be inconsistently applied across stacks |
Related Tools
Check a domain's current dual-stack status instantly with AAAA Record Lookup, which compares AAAA against the A record directly. Check the IPv4 side specifically with A Record Lookup, or the full record picture with DNS Lookup. If dual-stack isn't behaving as expected, our AAAA Troubleshooting guide walks through the diagnostic process.
FAQ
ToolsNovaHub guides are researched against primary sources (RFCs, vendor docs) and kept up to date as standards change. Spotted an error? Let us know.
📋 Related Tools & Guides Comparison
| Resource | Type | Link |
|---|---|---|
| AAAA Record Lookup | Tool | Open Tool → |
| A Record Lookup | Tool | Open Tool → |
| DNS Lookup | Tool | Open Tool → |
| AAAA Troubleshooting | Guide | Read Guide → |