Do Not Publish an AAAA Record Until the IPv6 Path Passes

• Publish an AAAA record only after the same hostname works over IPv6 from outside your network.
• Test TLS, HTTP, large responses and uploads; a successful connection alone can miss a path-MTU fault.
• Monitor IPv4 and IPv6 separately, and keep the IPv6 endpoint healthy until cached AAAA answers expire after rollback.

An IPv6 address alone proves little. DNS, routing, firewalls, TLS and the application can each send users toward a different result.

The AAAA record is the public switch. Once it exists, a dual-stack client may try that IPv6 address. Some clients can fall back to IPv4, but that fallback can hide a broken path from your team.

Use a launch gate instead. Publish only after one named owner can prove the full request and the rollback.

Know what your AAAA record points to

An A record stores an IPv4 address. An AAAA record stores one IPv6 address. It does not say whether the service is ready on that address.

Map the path for the exact hostname. Record the DNS provider, edge or load balancer, IPv6 route, firewall policy, TLS endpoint, origin and health check.

A managed proxy may accept IPv6 from users while it still contacts your origin over IPv4. That can be a valid design, but it is not proof that the origin has IPv6. Check the provider's current behavior and test the public path you actually expose.

Do not block all ICMPv6

IPv6 depends on ICMPv6 for more than ping. A router sends a Packet Too Big message when the next link cannot carry a packet. IPv6 Path MTU Discovery uses that message to lower the packet size.

If a firewall drops the signal, a small request may work while a larger response or upload hangs. The TCP connection can already be open. That is why a port check is not enough.

RFC 4890 lists Packet Too Big among the ICMPv6 errors that must not be dropped for normal communication. Apply a reviewed ICMPv6 policy. Do not translate an old “block ICMP” rule into IPv6 without checking each message type.

Test the address before publishing it

Use the final hostname so Server Name Indication, the certificate and virtual-host routing match production. A documentation-only example looks like this:

dig AAAA app.example.com +short
curl -6 --resolve 'app.example.com:443:[2001:db8::20]' \
  https://app.example.com/health

The 2001:db8::/32 block is reserved for examples. Replace it with your assigned address; never deploy the sample.

Test from several outside networks. Fetch a small health response, a normal page and a larger asset. Exercise an upload if the service accepts one. Verify the certificate name and chain, the expected HTTP status, key security headers and a known response marker.

Then test the application paths that often hide address assumptions: login, outbound callbacks, IP allow lists, rate limits, logs and abuse controls. An IPv6 client address is longer and may be written in compressed forms. Store it as an address value, not in a field sized for an IPv4 string.

Keep live TLS checks in the runbook. If the new edge changes script or API origins, repeat the CSP rollout checks too.

Monitor each address family on purpose

Happy Eyeballs lets a dual-stack client race connection choices and reduce visible delay. It does not prove both paths are healthy. The IETF warns that fallback can hide an IPv6 fault and recommends external monitoring for each family.

Create one forced-IPv4 probe and one forced-IPv6 probe. Each should check DNS, TLS, HTTP status and a short body marker. Label the family in alerts. A combined “site is up” check can stay green while all IPv6 attempts fall back.

Also watch application results by family. A route may connect yet fail after TLS, return the wrong virtual host or time out only on larger transfers. Record enough evidence to separate DNS, network, TLS and app failures.

Roll out with a real removal plan

1. Start with a test hostname. Use the same edge and application policy as production.
2. Run forced-family checks. Cover two external networks and the important request sizes.
3. Publish the production AAAA record. Note the change time, record value and DNS TTL.
4. Watch both families. Compare errors, latency and application outcomes.
5. Rollback by removing the AAAA record. Keep the IPv6 service working while cached answers can still be used.

Lowering a TTL before launch may shorten future cache life. It does not erase answers already cached under an older TTL, and removing the record cannot recall an answer a resolver still holds.

Keep the prior path and configuration available. The service-worker rollback guide shows the same principle at the browser layer: a control-plane change does not instantly change every client.

If the DNS zone is signed, follow the DNSSEC change checklist. DNSSEC can protect the authenticity of the record; it cannot make the IPv6 endpoint reachable.

These are release checks for your team to run. TechWeb did not test your DNS, firewall, network or application.

Frequently asked questions

Does an AAAA record make a site IPv6-ready?

No. It publishes an IPv6 destination. The route, firewall, TLS endpoint and application must work there too.

Will browsers always fall back to IPv4?

No guarantee covers every client or failure. Modern connection racing can reduce some delays, but it may also hide an IPv6 fault from basic monitoring.

Can a firewall block every ICMPv6 message?

No. Some ICMPv6 messages are needed for normal operation. Packet Too Big is vital to Path MTU Discovery.

Is removing the AAAA record an instant rollback?

No. Resolvers and clients may keep a cached answer until its TTL expires. Keep the IPv6 endpoint healthy during that window.

Sources

IETF RFC 3596: DNS Extensions to Support IPv6 · IETF RFC 8201: IPv6 Path MTU Discovery · IETF RFC 4890: ICMPv6 Filtering Recommendations · IETF RFC 8305: Happy Eyeballs v2 · Cloudflare Docs: IPv6 compatibility. Provider behavior can change; verify the current service documentation before rollout.