[BEHAVE] Proposed change to dns64 document

[Andrew Sullivan <ajs at shinkuro.com>]

Dear colleagues,

There remain a couple outstanding issues with the DNS64 document, both
of which have to do with cases where we have more than one interface.

Section 5.6 currently has this:

5.6.  DNS64 and multihoming

   Synthetic AAAA records may be constructed on the basis of the network
   context in which they were constructed.  Therefore, a synthetic AAAA
   received from one interface MUST NOT be used to resolve hosts via
   another network interface.  Because it will be hard (if not
   impossible) for a multihomed system to tell whether a given AAAA is
   synthetic, a host SHOULD treat any AAAA record received on a given
   interface as local to that interface; the alternative risks
   communication failures when the AAAA is used to communicate on
   another interface.  See the discussion in
   [I-D.savolainen-mif-dns-server-selection].

Section 6 currently mentions dual-stack hosts, but does not actually
address the case of a dual-stack host or treat what the interaction
between dual-stack and DNS64 is.

I propose to remove 5.6, and replace it with a new section 6.3 that
addresses multihoming and dual-stack.  The new proposed text is a
little long-winded, but given that this issue has come up in a few
different guises, I thought it better to aim for completeness.  Note
that there is no RFC2119 language in here, because one of the Chairs
suggested we can't purport to regulate client behaviour from inside
the server-behaviour specification.  The new text:

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 has
   multiple interfaces, 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.

   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.  For more discussion
   of this topic, see [I-D.savolainen-mif-dns-server-selection].

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 IPv4 native transit.
   In this case, i1 could receive an IPv6 address from a synthetic
   AAAA that would better be reached via native IPv4 transit.

   Since it is most likely that the host will attempt AAAA resolution
   first, in this arrangement the host will often use the NAT64 when a
   native IPv4 would be preferable.  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 to a LAN, with an IPv6-only connection on i1 to the Internet,
   connecting to the IPv4 Internet via NAT64.  Traffic to the LAN may
   not be routable from the global Internet, as is often the case (for
   instance) with LANs using RFC1918 addresses.  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.

Your comments are soliticted.

Best regards,

A

-- 
Andrew Sullivan
ajs at shinkuro.com
Shinkuro, Inc.