Skip to main content

6. Deployment Notes

While DNS64 is intended to be part of a strategy for aiding IPv6 deployment in an internetworking environment with some IPv4-only and IPv6-only networks, it is important to realize that it is incompatible with some things that may be deployed in an IPv4-only or dual-stack context.

6.1. DNS Resolvers and DNS64​

Full-service resolvers that are unaware of the DNS64 function can be (mis)configured to act as mixed-mode iterative and forwarding resolvers. In a native IPv4 context, this sort of configuration may appear to work. It is impossible to make it work properly without it being aware of the DNS64 function, because it will likely at some point obtain IPv4-only glue records and attempt to use them for resolution. The result that is returned will contain only A records, and without the ability to perform the DNS64 function the resolver will be unable to answer the necessary AAAA queries.

6.2. DNSSEC Validators and DNS64​

An existing DNSSEC validator (i.e., one that is unaware of DNS64) might reject all the data that comes from DNS64 as having been tampered with (even if it did not set CD when querying). If it is necessary to have validation behind the DNS64, then the validator must know how to perform the DNS64 function itself. Alternatively, the validating host may establish a trusted connection with a DNS64, and allow the DNS64 recursive resolver to do all validation on its behalf.

6.3. DNS64 and Multihomed and Dual-Stack Hosts​

6.3.1. IPv6 Multihomed Hosts​

Synthetic AAAA records may be constructed on the basis of the network context in which they were constructed. If a host sends DNS queries to resolvers in multiple networks, it is possible that some of them will receive answers from a DNS64 without all of them being connected via a NAT64. For instance, suppose a system has two interfaces, i1 and i2. Whereas i1 is connected to the IPv4 Internet via NAT64, i2 has native IPv6 connectivity only. I1 might receive a AAAA answer from a DNS64 that is configured for a particular NAT64; the IPv6 address contained in that AAAA answer will not connect with anything via i2.

+---------------+                 +-------------+
|      i1 (IPv6)+----NAT64--------+IPv4 Internet|
|               |                 +-------------+
| host          |
|               |                 +-------------+
|      i2 (IPv6)+-----------------+IPv6 Internet|
+---------------+                 +-------------+

Figure 1: IPv6 Multihomed Hosts

This example illustrates why it is generally preferable that hosts treat DNS answers from one interface as local to that interface. The answer received on one interface will not work on the other interface. Hosts that attempt to use DNS answers globally may encounter surprising failures in these cases.

Note that the issue is not that there are two interfaces, but that there are two networks involved. The same results could be achieved with a single interface routed to two different networks.

6.3.2. Accidental Dual-Stack DNS64 Use​

Similarly, suppose that i1 has IPv6 connectivity and can connect to the IPv4 Internet through NAT64, but i2 has native IPv4 connectivity. In this case, i1 could receive an IPv6 address from a synthetic AAAA that would better be reached via native IPv4. Again, it is worth emphasizing that this arises because there are two networks involved.

+---------------+                 +-------------+
|      i1 (IPv6)+----NAT64--------+IPv4 Internet|
|               |                 +-------------+
| host          |
|               |                 +-------------+
|      i2 (IPv4)+-----------------+IPv4 Internet|
+---------------+                 +-------------+

Figure 2: Accidental Dual-Stack DNS64 Use

The default configuration of dual-stack hosts is that IPv6 is preferred over IPv4 ([RFC3484]). In that arrangement, the host will often use the NAT64 when native IPv4 would be more desirable. For this reason, hosts with IPv4 connectivity to the Internet should avoid using DNS64. This can be partly resolved by ISPs when providing DNS resolvers to clients, but that is not a guarantee that the NAT64 will never be used when a native IPv4 connection should be used. There is no general-purpose mechanism to ensure that native IPv4 transit will always be preferred, because to a DNS64-oblivious host, the DNS64 looks just like an ordinary DNS server. Operators of a NAT64 should expect traffic to pass through the NAT64 even when it is not necessary.

6.3.3. Intentional Dual-Stack DNS64 Use​

Finally, consider the case where the IPv4 connectivity on i2 is only with a LAN, and not with the IPv4 Internet. The IPv4 Internet is only accessible using the NAT64. In this case, it is critical that the DNS64 not synthesize AAAA responses for hosts in the LAN, or else that the DNS64 be aware of hosts in the LAN and provide context-sensitive answers ("split view" DNS answers) for hosts inside the LAN. As with any split view DNS arrangement, operators must be prepared for data to leak from one context to another, and for failures to occur because nodes accessible from one context are not accessible from the other.

+---------------+                 +-------------+
|      i1 (IPv6)+----NAT64--------+IPv4 Internet|
|               |                 +-------------+
| host          |
|               |
|      i2 (IPv4)+---(local LAN only)
+---------------+

Figure 3: Intentional Dual-Stack DNS64 Use

It is important for deployers of DNS64 to realize that, in some circumstances, making the DNS64 available to a dual-stack host will cause the host to prefer to send packets via NAT64 instead of via native IPv4, with the associated loss of performance or functionality (or both) entailed by the NAT. At the same time, some hosts are not able to learn about DNS servers provisioned on IPv6 addresses, or simply cannot send DNS packets over IPv6.