Cloudflare Gateway DNS64: location settings, EDNS 65051 and the NAT64 requirement

Separate a DNS answer from a working IPv4 connection

On October 13, 2026, Cloudflare announced two ways to request Gateway DNS64: a DNS location setting and an EDNS option. DNS64 synthesizes an IPv6 answer when a name has A records but no AAAA records. An AAAA record supplies an IPv6 address; an A record supplies an IPv4 address.

NAT64 is the network-side translation that carries IPv6 traffic to an IPv4 service. Gateway uses the 64:ff9b::/96 prefix for synthesized answers, and your IPv6-only network must provide NAT64 for that prefix. With DNS64 alone, resolution can succeed while the subsequent connection still fails.

This configuration concerns administrators authorized to manage Gateway DNS locations and users of the corresponding network. The announcement and technical pages do not list DNS64-specific charges, a complete plan eligibility matrix or country-by-country availability. Check your organization’s account conditions; a visible setting does not establish that every account or region receives it free.

Use Resolver endpoints when the change belongs to a location

First, open the Cloudflare dashboard and go to Zero Trust > Traffic controls > Resolver endpoints, then choose Add a location. Name the location and choose an endpoint for your organization’s DNS queries. For an existing location, use its editing settings.

Next, turn on Enable DNS64. The setting is off by default and applies to queries that match that DNS location. Matching depends on the resolver endpoints and the documented location matching rules; this is not an account-wide switch for every DNS request.

Continue through source filtering, authentication and the location review, choose Done, then follow the resolver setup instructions shown in the interface. Standard IPv4 endpoints require endpoint authentication; authentication is optional for dedicated IPv4 endpoints. The Enterprise documentation for dedicated or BYOIP resolver addresses describes those endpoints, rather than establishing an Enterprise requirement for DNS64 itself.

Permissions must match the resource. The current permissions page lists Zero Trust DNS Location Admin for creating, editing and deleting DNS locations across an account. Existing Cloudflare Gateway or Cloudflare Zero Trust account roles retain the corresponding write access. A resource-scoped permission to edit a DNS policy does not include DNS locations.

Use an empty EDNS option 65051 for a single query

EDNS adds extension options to DNS queries. To request DNS64 for one query, use Cloudflare-specific option code 65051 with option length 0 and no data. Both this option and the location setting support UDP, TCP, DNS over TLS (DoT) and DNS over HTTPS (DoH).

The unexecuted example below follows the official dig example. Replace RESOLVER_IP with the resolver IP for a location you are authorized to use. Add +tcp to send the query over TCP.

dig @RESOLVER_IP ipv4only.arpa AAAA +ednsopt=65051 +short

To carry the EDNS option over DoH, send a DNS wire-format request. The JSON DoH query format cannot carry this option. The existing cf-dns-options: dns64 request header can still request DNS64 independently; using the new EDNS option does not make that header mandatory.

A nonempty payload on option 65051 does not request DNS64, and it does not cancel synthesis requested by the location setting or DoH header. If a query contains several instances of option 65051, any empty instance requests synthesis. Inspect the complete request when troubleshooting rather than just one option.

Preserve the field on PUT, and understand what turning it off means

The location API defines dns64_enabled as a Boolean field that defaults to false. Location updates use PUT. Explicitly include the desired Boolean value and preserve the other location settings in each update. To keep DNS64 enabled, send dns64_enabled: true; omitting the field resets it to false.

Setting the location field to false does not prevent an individual EDNS option or DoH header from requesting DNS64. These are three independent opt-in mechanisms. A disabled location setting does not prove that an individual query will receive no synthesized answer.

Consider a hypothetical change that has not been performed here. A team updates only a location name, but its automation omits dns64_enabled, disabling location-based synthesis. A client that still sends the DoH header may continue to receive synthesized answers. Reviewing both update fields and query contents is more useful than inspecting a single toggle.

Verify the location without another opt-in masking the result

The documented verification name is ipv4only.arpa. An eligible AAAA query that requests DNS64 returns 64:ff9b::c000:aa and 64:ff9b::c000:ab, corresponding to its A records 192.0.0.170 and 192.0.0.171. These are the documented expected answers, rather than results measured in this research.

To test the location setting independently, omit EDNS option 65051 and the cf-dns-options header. The documentation says this name returns no AAAA answers when the location setting is off and there is no per-query opt-in. Leaving an individual opt-in attached means the answer cannot establish the location setting’s effect by itself.

After checking synthesis, separately establish that the network provides NAT64 for 64:ff9b::/96 and that the target service is reachable. A DNS answer describes resolution; it does not replace a connection check or application authorization.

Existing answers and DNSSEC still set boundaries

DNS64 does not change existing AAAA answers, A queries or DNS error responses. It also does not apply to Gateway DNS policy block responses or DNS override answers. If a policy or override is responsible for a result, enabling DNS64 does not remove that rule.

Clients that independently validate DNSSEC may reject synthesized answers. DNSSEC verifies signatures on DNS data, and DNS64 cannot create valid DNSSEC signatures for synthesized AAAA records. If a resolver returns an address that a client rejects, include validation behavior in the investigation rather than treating synthesis as proof of a valid signature.

Choose the mechanism by the scope of the change. For queries matching a location, review its setting and PUT updates. For one query, review EDNS or the DoH header. Then assess the DNS answer, NAT64 path and application access conditions separately, rather than combining them into one conclusion that IPv6 connectivity works.