DNS64 is a DNS service function that synthesises AAAA records for IPv6-only clients when a name has only an IPv4 address. It works with NAT64, which translates IPv6 traffic to IPv4 so dual-stack reachability can be maintained across an IPv6-only network.
How DNS64 works
DNS64 is a resolver-side translation function, not a routing protocol or an access control mechanism. Its job is to answer IPv6-only client queries with a synthetic AAAA record when the name exists only as an IPv4 address, so the client can still initiate connectivity through NAT64.
The key idea is that DNS64 preserves application reachability without forcing every upstream service to become dual-stack immediately. That makes it useful during IPv6 transition, but it also means the resolver is actively shaping name resolution outcomes rather than merely passing authoritative data through unchanged.
Where DNS64 fits in IPv6 transition
DNS64 normally sits alongside NAT64 in an IPv6-only network. The client sees an IPv6 destination, while the network translates that traffic to an IPv4 destination behind the scenes. In practice, DNS64 helps mask IPv4-only dependencies from IPv6-only hosts.
This design is most valuable where end systems or access segments are IPv6-only, but external services, legacy applications, or partner systems still publish only A records. It is a compatibility layer, not a substitute for native IPv6 support, because the dependency on translation remains.
DNS64 also changes how operators think about reachability. A service may appear “IPv6 reachable” to clients even though the actual destination remains IPv4-based, so troubleshooting, logging, and path analysis need to account for the translation stage.
Operational characteristics and limitations
Because DNS64 synthesises records dynamically, it must be configured carefully with the right prefix, resolver policy, and exclusion handling. If the resolver synthesises when it should not, clients may be directed toward an unintended translation path. If it fails to synthesise where expected, IPv6-only clients may lose reachability to otherwise valid services.
DNS64 also depends on accurate DNS answers and consistent NAT64 behaviour. Breakage can appear as application timeouts, partial service reachability, or confusing name resolution results that differ from what an operator sees when querying authoritative DNS directly.
For that reason, DNS64 is usually treated as part of an end-to-end transition architecture, not an isolated DNS feature. Its value comes from coordinated resolver, translation, and network planning.
DNS64 security and visibility implications
DNS64 does not create a new authentication model, but it does affect how traffic is directed and observed. Synthetic answers can complicate network monitoring, because the destination seen by the client and the ultimate IPv4 endpoint are not the same thing.
That matters for filtering, logging correlation, and incident analysis. Security teams need to understand whether a connection failure or unusual flow is caused by DNS synthesis, NAT64 translation, the IPv4 destination, or a policy decision elsewhere in the path.
It also means DNS64 should be deployed with clear resolver governance. If the synthesis logic is overly broad, it can change which destinations are reachable from IPv6-only networks. If it is too narrow, it can unintentionally block legitimate legacy dependencies.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
NIST SP 800-53 Rev 5, NIST CSF 2.0, CIS Controls v8 and NIST Zero Trust (SP 800-207) set the technical controls, while ISO/IEC 27001:2022 defines the regulatory obligations.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST SP 800-53 Rev 5 | SC-7 — Boundary Protection | DNS64 and NAT64 alter network paths across protocol boundaries. |
| Recommendation — Constrain translated traffic paths and monitor cross-boundary flows through boundary protection controls. | ||
| NIST CSF 2.0 | PR.PS-1 — Configurations are managed and changes are tracked | DNS64 depends on careful resolver and translation configuration. |
| Recommendation — Manage DNS64 and NAT64 settings as controlled security-relevant configurations. | ||
| CIS Controls v8 | CIS-12 — Network Infrastructure Management | DNS64 is a network service that must be inventoried, configured, and monitored. |
| Recommendation — Inventory DNS64-capable resolvers and monitor their operational behaviour. | ||
| ISO/IEC 27001:2022 | A.8.20 — Network security | DNS64 affects how network traffic is resolved and forwarded. |
| Recommendation — Document and secure DNS64 translation paths within network security controls. | ||
| NIST Zero Trust (SP 800-207) | SCALABLE — Zero Trust Architecture | DNS64 sits inside a trust-boundary translation design that should be explicitly governed. |
| Recommendation — Treat DNS64 as part of a zero-trust transition architecture and verify each translation boundary. | ||
Practitioner Guidance
Why practitioners should care: DNS64 is often the difference between a usable IPv6-only environment and one that cannot reach critical IPv4-only services. The practical question is not whether it “supports IPv6”, but whether the translation path is predictable, observable, and intentionally scoped.
What to watch for: Validate which resolvers are allowed to synthesise AAAA records, and keep NAT64 and DNS logging aligned so that connectivity issues can be traced end to end. Treat unexpected synthesis behaviour as an operational signal, not just a DNS curiosity.
Deepen Your Knowledge
Free weekly newsletter
Subscribe to the NHI & AI Identity Journal
The latest on NHI and Agentic AI security – articles, research, breaches, news and events every week.
Bonus 33% off our NHI Course when you subscribe.
Reviewed and updated by the NHIMG editorial team on November 9, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org