You enable IPv6 "to stay current": one click in the DNS panel, an AAAA record added, and the site vanishes for a handful of visitors — especially those whose ISP routes v6 poorly or whose phone flips between stacks. Support gets "site unreachable" tickets you cannot reproduce from the office, where everything still works on IPv4.
The trap is not IPv6 itself. It is publishing an AAAA without aligning server, firewall, TLS and routing to the same service quality as IPv4.
Happy Eyeballs: why a bad AAAA hurts
Modern clients do not pick "IPv4 or IPv6" once and forever. They start both attempts, with fallback timers. If your AAAA points at an IP where nothing listens, or where the firewall silently drops, the user waits — sometimes several seconds — before falling back to IPv4.
| Symptom | Common cause | Check |
|---|---|---|
| Very slow first load | IPv6 timeout then IPv4 fallback | curl -6 -v https://yourdomain.tld |
| Blank page for some ISPs | AAAA to unconfigured IP | Test from IPv6-only network |
| Mixed content or redirect loop | Vhost ignores v6 address | nginx/Apache logs on [::]:443 |
| Mail rejected | No PTR / SPF missing v6 | dig AAAA + SPF records |
A valid AAAA in DNS does not guarantee valid IPv6 service — only that the resolver will return an address.
Pre-publication checklist
1. IPv6 assigned and routed. On VPS or cloud, v6 is not always on by default. Check the interface (ip -6 addr), gateway and any billing.
2. Web listener on [::]:80 and [::]:443. Nginx, Apache or Caddy must listen explicitly dual-stack or IPv6-only. listen 443 ssl without [::] leaves IPv6 orphaned.
3. Firewall and security groups. Open the same ports as IPv4. iptables/nftables IPv4 rules do not apply to IPv6 — you need ip6tables or dedicated rules.
4. TLS certificate and full chain. The cert binds to the name, not the stack — but the handshake must succeed on the v6 address. Test with openssl s_client -connect [2001:db8::1]:443.
5. CDN and proxy. Cloudflare, Fastly or a cloud load balancer need IPv6 on edge and origin. An IPv4-only proxy in front of a v6 origin creates grey zones.
Gradual rollout
Instead of a big bang:
- Test locally via
/etc/hostsorcurl --resolve example.tld:443:[2001:db8::1]. - Publish with short TTL (300 s) for fast rollback.
- Monitor v6 error logs and CDN timeout metrics.
- Remove the AAAA if v6 failure rate exceeds your threshold — no v6 beats broken v6.
Some shared hosts offer IPv6 optionally or on specific plans. Check the product page before changing public DNS.
The climax: IPv6 is not mandatory — a broken AAAA is
Do not let the registrar tick a box by default.
Decide and move forward without blind spots
- Audit the full stack (server, FW, TLS, CDN) before any AAAA record.
- Test from an IPv6-only network — not only your dual-stack home connection.
- Document who removes the AAAA in an incident (DNS rollback procedure).
- Compare hosts that clearly document IPv6 support in our directory.
Frequently asked questions
Can I add an AAAA if my host only offers IPv4?
Not until server, load balancer and firewall have working IPv6.
Why do some users see IPv4 and others fail?
Happy Eyeballs: IPv6 timeout delays IPv4 fallback or fails depending on network.
Do I need a separate TLS certificate for IPv6?
No — but the vhost must accept connections on the IPv6 address.
How do I test before publishing the AAAA record?
curl --resolve, IPv6-only tests, PTR/SPF checks if you send mail.
Before adding an AAAA, ask one question: does IPv6 work as well as IPv4 here? If the answer is not yes, do not publish yet.