Subject: draft-palet-v6ops-nat64-deployment (was DNS64 and DOH) - DNS64 support in draft-ietf-6man-rfc6434-bis

From: JORDI PALET MARTINEZ <[email-masked]>
Date: Thu, 28 Jun 2018 11:00:01 +0200

Hi all,

I just recalled this issue that Erik brought to the DOH list during last meeting, which by some reason, I totally forget until just now.

This is related to the last email exchange with Fred as well regarding pros/cons of DNS64.

draft-ietf-doh-dns-over-https (v12) has the following on this matter:

3.1.  Non-requirements

   o  Supporting network-specific DNS64 [RFC6147]

and

11.  Operational Considerations

   Local policy considerations and similar factors mean different DNS

   servers may provide different results to the same query: for instance

   in split DNS configurations [RFC6950].  It logically follows that the

   server which is queried can influence the end result.  Therefore a

   client's choice of DNS server may affect the responses it gets to its

   queries.  For example, in the case of DNS64 [RFC6147], the choice

   could affect whether IPv6/IPv4 translation will work at all.

So, if DNS64 is being used, it may get broken not just by DoH, but I guess also it may be happening in DNS over TLS, DNS over QUIC. I’m going to check some of those cases and bring back a new version including some text, if needed.

Obviously, the best solution will be to ensure that every host has support for RFC7050/RFC7227/RFC6147, so they can do the DNS64 by themselves. This will resolve all the issues of DNS64 I think. I’ve copied Tim on this, may be is something that we haven’t realized till now, and should be considered in (draft-ietf-6man-rfc6434-bis) ? (copied 6man).

Regards,

Jordi

De: <[email-masked]> en nombre de Erik Nygren <[email-masked]>
Fecha: domingo, 18 de marzo de 2018, 20:20
Para: <[email-masked]>, Jordi Palet Martinez <[email-masked]>, Lee Howard <[email-masked]>
Asunto: DNS64 and DOH

In reading through the dns-over-https draft I'm wondering if we should have some better coverage of DNS64 which is becoming widely deployed in some mobile environments.

(See https://tools.ietf.org/html/draft-palet-v6ops-nat64-deployment-00 for some discussions which is on the v6ops agenda for this week.)

Thinking some about this (and general IPv6-only deployments):

* The section mentioning using IP literals as DOH service end-points may wish to point out the risk that this may have challenges due to mixtures of IPv6-only, dual-stacked, and IPv4-only environments.

* It would be good to add a section on how applications using DOH may wish to handle "A" lookups in DNS64 environments.  In particular, to do the DNS64-synthesis and construction in the client when no AAAA record is available and when a NAT64 prefix is available through a mechanism such as:
           RFC 7050 - Discovery of the IPv6 Prefix Used for IPv6 Address Synthesis,
           RFC 7225 - Discovering NAT64 IPv6 Prefixes Using the Port Control Protocol (PCP)

 Doing the synthesis in the client seems preferable over trying to get the server to do synthesis with the proper prefix in most scenarios, plus in cases where the client is using the results directly this will get around some of the DNSSEC issues. 

At least for mobile, not using DNS64 synthesis in the client will likely result in this either breaking the client in NAT64 environments or causing something lower in the stack to do the equivalent (a 464xlat CLAT on Android or bump-in-the-API on iOS).

        Erik

**********************************************
IPv4 is over
Are you ready for the new Internet ?
http://www.consulintel.es
The IPv6 Company

This electronic message contains information which may be privileged or confidential. The information is intended to be for the exclusive use of the individual(s) named above and further non-explicilty authorized disclosure, copying, distribution or use of the contents of this information, even if partially, including attached files, is strictly prohibited and will be considered a criminal offense. If you are not the intended recipient be aware that any disclosure, copying, distribution or use of the contents of this information, even if partially, including attached files, is strictly prohibited, will be considered a criminal offense, so you must reply to the original sender to inform about this communication and delete it.