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
- [Doh] DNS64 and DOH Erik Nygren
- Re: [Doh] DNS64 and DOH Stephane Bortzmeyer
- Re: [Doh] DNS64 and DOH Jim Reid
- Re: [Doh] DNS64 and DOH Patrick McManus
- Re: [Doh] [Ext] DNS64 and DOH Paul Hoffman
- Re: [Doh] [Ext] DNS64 and DOH Andrew Sullivan
- Re: [Doh] [Ext] DNS64 and DOH Ben Schwartz
- Re: [Doh] DNS64 and DOH Lee Howard
- Re: [Doh] [Ext] DNS64 and DOH Andrew Sullivan
- Re: [Doh] [Ext] DNS64 and DOH Jim Reid
- Re: [Doh] DNS64 and DOH Lee Howard
- Re: [Doh] DNS64 and DOH JORDI PALET MARTINEZ