Dual-stack networks with both IPv6 and IPv4 connectivity are now common, but they are still far from universal. To take the next step of the transition to IPv6 and deploy IPv6-only networks, network operators must still preserve access to IPv4-only networks and services. There are several transition mechanisms to provide IPv6 access to IPv4; an increasingly popular choice with many network operators is NAT64. Using a NAT64 gateway with IPv4-IPv6 translation capability lets IPv6-only clients connect to IPv4-only services via synthetic IPv6 addresses starting with a prefix that routes them to the NAT64 gateway.
DNS64 is a DNS service that returns AAAA records with these synthetic IPv6 addresses for IPv4-only destinations (with A but not AAAA records in the DNS). This lets IPv6-only clients use NAT64 gateways without any other configuration. Google Public DNS64 provides DNS64 as a global service using the reserved NAT64 prefix 64:ff9b::/96.
Important: Before you start
Before configuring your systems to use Google Public DNS64, consider the following limitations that may affect your use of the service:
Google Public DNS64 is intended for use only on networks with access to a NAT64 gateway using the reserved NAT64 prefix
64:ff9b::/96. Do not use it on networks that cannot reach such a NAT64 gateway.
Google Public DNS64 does not provide access to private domains that cannot be resolved from the public Internet, although it can return AAAA records for private (RFC 1918) IPv4 addresses returned in public DNS responses.
Google Public DNS64 is not needed for dual-stack networks or hosts, but it does work, returning both synthesized AAAA and original A records (this can result in traffic to IPv4-only hosts going through NAT64 rather than directly via IPv4, but generally only when the NAT64 connection is faster).
Configuring Google Public DNS64
If your systems have no problems with the above Google Public DNS64 limitations, you can follow the usual Google Public DNS getting started instructions, replacing the standard resolver addresses with the following:
Do not configure any other IPv6 addresses: doing so makes DNS64 unreliable. If you also configure Google Public DNS IPv4 addresses (22.214.171.124 or 126.96.36.199), dual-stack hosts may not get synthesized AAAA records sometimes.
Some devices use separate fields for all eight parts of IPv6 addresses and
cannot accept the
:: IPv6 abbreviation syntax. For such fields enter:
0 entries to
64 entry to
if four hex digits are required.
Test your DNS64 settings
You can follow the test steps in the getting started guide to verify that your DNS64 configuration is working. If you don't have access to a NAT64 gateway, Wikipedia lists several NAT64 implementations you can deploy yourself.
Some NAT64 implementations are known not to work with Google Public DNS64:
MacOS X 10.11 and later incorporates NAT64/DNS64 but cannot pass IPv6, preventing access to the Google Public DNS64 resolvers. It is intended for testing IPv6-only devices when you only have IPv4 connectivity to the Internet, and only works with the included DNS64 (IPv6-only devices connected to it cannot use Google Public DNS directly, although you can configure the MacOS X system to use 188.8.131.52 and 184.108.40.206).
Cisco ASA 9.0 and later incorporates NAT64 but does not support the well-known prefix
64:ff9b::/96and requires you to select your own prefix. It does not implement DNS64 but provides inspection and NAT rewriting of DNS traffic passing through the NAT64 gateway.
IPv6-only devices behind a Cisco ASA can get IPv4 connectivity using Google Public DNS by configuring the following resolver addresses:
::0808:0808(220.127.116.11 via Cisco ASA NAT64)
::0808:0404(18.104.22.168 via Cisco ASA NAT64)
This routes queries to Google Public DNS through the Cisco ASA NAT64. With some additional Cisco ASA configuration, AAAA queries are translated into A queries, and A responses are translated back into AAAA with the configured prefix.
Using both NAT64 addresses and Google Public DNS IPv6 resolver addresses (2001:4860:4860::8888 or 2001:4860:4860::8844) does not work, as negative responses from either one will not be re-queried with the other. You must choose either IPv6 or IPv4 DNS resolution for all queries.