Re: [Doh] DNS64 and DOH

Lee Howard <lee@asgard.org> Thu, 22 March 2018 14:17 UTC

Return-Path: <lee@asgard.org>
X-Original-To: doh@ietfa.amsl.com
Delivered-To: doh@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 004F8126D85 for <doh@ietfa.amsl.com>; Thu, 22 Mar 2018 07:17:27 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.236
X-Spam-Level:
X-Spam-Status: No, score=-1.236 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_MSPIKE_H2=-0.001, SPF_SOFTFAIL=0.665] autolearn=no autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JcKSghL0uPBZ for <doh@ietfa.amsl.com>; Thu, 22 Mar 2018 07:17:20 -0700 (PDT)
Received: from jax4mhob19.registeredsite.com (jax4mhob19.registeredsite.com [64.69.218.107]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 74F9E12E887 for <doh@ietf.org>; Thu, 22 Mar 2018 07:17:20 -0700 (PDT)
Received: from mailpod.hostingplatform.com ([10.30.71.210]) by jax4mhob19.registeredsite.com (8.14.4/8.14.4) with ESMTP id w2MEHDji048099 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for <doh@ietf.org>; Thu, 22 Mar 2018 10:17:14 -0400
Received: (qmail 7076 invoked by uid 0); 22 Mar 2018 14:17:13 -0000
X-TCPREMOTEIP: 31.133.147.181
X-Authenticated-UID: lee@asgard.org
Received: from unknown (HELO ?31.133.147.181?) (lee@asgard.org@31.133.147.181) by 0 with ESMTPA; 22 Mar 2018 14:17:12 -0000
To: Stephane Bortzmeyer <bortzmeyer@nic.fr>, Erik Nygren <erik+ietf@nygren.org>
Cc: doh@ietf.org, Jordi Palet Martinez <jordi.palet@consulintel.es>
References: <CAKC-DJjtHE89A=vG5iS_0M_jqnWusDUDnwyernd+FC1VxxmU5Q@mail.gmail.com> <20180319090048.GB16151@laperouse.bortzmeyer.org>
From: Lee Howard <lee@asgard.org>
Message-ID: <4c0b18e4-0f97-e1d5-7e93-1dc81d03f114@asgard.org>
Date: Thu, 22 Mar 2018 14:17:10 +0000
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.6.0
MIME-Version: 1.0
In-Reply-To: <20180319090048.GB16151@laperouse.bortzmeyer.org>
Content-Type: text/plain; charset="utf-8"; format="flowed"
Content-Transfer-Encoding: 8bit
Content-Language: en-US
Archived-At: <https://mailarchive.ietf.org/arch/msg/doh/KY2SHzuvOP6Nvo6PHHFOv34_foE>
Subject: Re: [Doh] DNS64 and DOH
X-BeenThere: doh@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: DNS Over HTTPS <doh.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/doh>, <mailto:doh-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/doh/>
List-Post: <mailto:doh@ietf.org>
List-Help: <mailto:doh-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/doh>, <mailto:doh-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 22 Mar 2018 14:17:27 -0000


On 03/19/2018 09:00 AM, Stephane Bortzmeyer wrote:
> On Sun, Mar 18, 2018 at 07:20:35PM +0000,
>   Erik Nygren <erik+ietf@nygren.org> 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"?

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