Subject: [Doh] DNS64 and DOH

From: Erik Nygren <[email-masked]>
Date: Sun, 18 Mar 2018 19:20:35 +0000

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

---

From: Stephane Bortzmeyer <[email-masked]>
Date: Mon, 19 Mar 2018 09:00:48 +0000

On Sun, Mar 18, 2018 at 07:20:35PM +0000,
 Erik Nygren <[email-masked]> wrote 
 a message of 86 lines which said:

> At least for mobile, not using DNS64 synthesis in the client will
> likely result in this either breaking the client in NAT64
> environments

Is it a DNS64-specific problem? It could also happen if you have
local-only domain names, dummy local TLDs, alternative roots,
split-horizon, CDN, geo-based answers, or other DNS tricks.

Yesterday, one IETFer told me that DoH was a bad idea because it allows
people to avoid DNS-based national censorship…

May be a warning "the DoH resolver may give you a different answer
from what you would have got from the usual resolver"?

---

From: Jim Reid <[email-masked]>
Date: Mon, 19 Mar 2018 09:07:20 +0000

> On 19 Mar 2018, at 09:00, Stephane Bortzmeyer <[email-masked]> wrote:
> 

Surely not! DNS sometimes lies. Tell me it isn't so. :-)

---

From: Patrick McManus <[email-masked]>
Date: Mon, 19 Mar 2018 10:17:25 +0000

> from what you would have got from the usual resolver"?
that text exists in section 10

---

From: Paul Hoffman <[email-masked]>
Date: Mon, 19 Mar 2018 10:19:16 +0000

On Mar 18, 2018, at 7:20 PM, Erik Nygren <[email-masked]> wrote:
> 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).
>  

This is true for DNS64 in any environment, not just DOH, correct? If a client has two resolvers configured and only one is doing DNS64, or they are doing it differently, you have the same problem, yes?

--Paul Hoffman

---

From: Andrew Sullivan <[email-masked]>
Date: Mon, 19 Mar 2018 06:33:16 -0400

> This is true for DNS64 in any environment, not just DOH, correct? If a client has two resolvers configured and only one is doing DNS64, or they are doing it differently, you have the same problem,…

Quite so, but even in a MIF (split horizon) environment the
different-scope resolution is not usually imagined to be two different
paths to the whole Internet.  I think the point is basically that, if
the host is doing DNS64 for resolution but somehow gets DOH that is
not using the DNS64 path, there's a problem.  That does seem worth
noting.

A

-- 
Andrew Sullivan
[email-masked]

---

From: Ben Schwartz <[email-masked]>
Date: Mon, 19 Mar 2018 06:52:00 -0400

On Mon, Mar 19, 2018 at 6:33 AM, Andrew Sullivan <[email-masked]>
wrote:

> > This is true for DNS64 in any environment, not just DOH, correct? If a
> client has two resolvers configured and only one is doing DNS64, or they
> are doing it differently, you have the same problem, yes?
> >
>

I am fine with a note on this topic, but I will observe that RFC 7858 (DNS
over TLS) feels no need to mention DNS64, so I think we are free to take a
similar approach here.

>
> A
>
> --
> Andrew Sullivan
> [email-masked]
>
> _______________________________________________
> Doh mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/doh
>

---

From: Lee Howard <[email-masked]>
Date: Mon, 19 Mar 2018 13:49:04 +0000

> from what you would have got from the usual resolver"?
Well, in the mobile NAT64 case, "a different answer" will be "an 
unusable answer," wouldn't it?

Lee

---

From: Andrew Sullivan <[email-masked]>
Date: Mon, 19 Mar 2018 10:26:04 -0400

On Mon, Mar 19, 2018 at 06:52:00AM -0400, Ben Schwartz wrote:
> 
> I am fine with a note on this topic, but I will observe that RFC 7858 (DNS over
> TLS) feels no need to mention DNS64, so I think we are free to take a similar
> approach here.

The draft already explicitly calls out DNS64.  Section 4.1 says that
it won't support network-specific DNS64.

It is possible that this means it won't work in lots of the cases
people are worried about, however.  I just don't know.

In any case, I think simply making a small modification to section 10
would be enough:

OLD

   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.

NEW

   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.  In the case of DNS64 [RFC6147], the choice could affect
   whether IPv6/IPv4 translation will work at all.

Best regards,

A

-- 
Andrew Sullivan
[email-masked]

---

From: Jim Reid <[email-masked]>
Date: Mon, 19 Mar 2018 14:29:13 +0000

> On 19 Mar 2018, at 14:26, Andrew Sullivan <[email-masked]> wrote:
> 

wfm

---

From: Lee Howard <[email-masked]>
Date: Thu, 22 Mar 2018 14:17:10 +0000

> from what you would have got from the usual resolver"?

Now that I have a couple more minutes, I thought I'd note Apple's 
measurements of IPv6-only hosts:
https://www.ietf.org/proceedings/98/slides/slides-98-maprg-measuring-trends-in-ipv6-support-tommy-pauly-00.pdf
As of a year ago in maprg, 5-10% of hosts had no IPv4.
Thanks for including the text, "For example, in the case of DNS64 
[RFC6147], the choice could affect whether IPv6/IPv4 translation will 
work at all." It might not be immediately clear to a server operator 
that the implication of translation not working is that they must 
dual-stack the server. Proposed text:
"... IPv6/IPv4 translation will work at all, so running both IPv4 and 
IPv6 on the server is recommended." If you don't like "is recommended" 
because it's rfc2119 language, maybe "will improve the chances of 
connecting."

I'm also a little nervous about the text in Section 9 Operational 
Considerations describing the bootstrap problem, and suggesting as one 
possibility  "IP based URIs and corresponding IP based certificates for 
HTTPS". Using IP literals as the URI is the opposite of DNS. I think 
this is the fundamental resolution problem, which DNS solves with root 
hints and glue records. There are, of course, lots of problems with IP 
literals, including that the syntax is different in IPv4 and [IPv6], and 
that addresses change.

Lee

---

From: JORDI PALET MARTINEZ <[email-masked]>
Date: Thu, 22 Mar 2018 14:29:54 +0000

I will also draft some text in https://tools.ietf.org/html/draft-palet-v6ops-nat64-deployment-00, in order to consider different issues that have been raised with this thread, so at least, those deploying NAT64s/DNS64s are aware of it.

Regards,
Jordi
 
-----Mensaje original-----
De: Doh <[email-masked]> en nombre de Lee Howard <[email-masked]>
Fecha: jueves, 22 de marzo de 2018, 14:17
Para: Stephane Bortzmeyer <[email-masked]>, Erik Nygren <[email-masked]>
CC: <[email-masked]>, Jordi Palet Martinez <[email-masked]>
Asunto: Re: [Doh] DNS64 and DOH

    

    Lee

    

**********************************************
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.