Re: [Doh] [Ext] DNS64 and DOH

Andrew Sullivan <ajs@anvilwalrusden.com> Mon, 19 March 2018 14:27 UTC

Return-Path: <ajs@anvilwalrusden.com>
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 E50691275FD for <doh@ietfa.amsl.com>; Mon, 19 Mar 2018 07:27:16 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level:
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=yitter.info header.b=GIGzTdse; dkim=pass (1024-bit key) header.d=yitter.info header.b=RPv59XI1
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 rlAJ7oCpwuV5 for <doh@ietfa.amsl.com>; Mon, 19 Mar 2018 07:27:15 -0700 (PDT)
Received: from mx4.yitter.info (mx4.yitter.info [159.203.56.111]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3129C12D870 for <doh@ietf.org>; Mon, 19 Mar 2018 07:26:39 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by mx4.yitter.info (Postfix) with ESMTP id 78707BE780 for <doh@ietf.org>; Mon, 19 Mar 2018 14:26:08 +0000 (UTC)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yitter.info; s=default; t=1521469568; bh=AmDoyLcfSMRLxu2XMFzJnoLbB+9h1zHPD48ijXu6CcU=; h=Date:From:To:Subject:References:In-Reply-To:From; b=GIGzTdseBzCi1OTFTWOTcNtHu50XRKpl8EpHUpcplTO8Io0M8z+EuBK8S+8nFyJrk TJ9f7LWbUSnzjxqY1j+50XG8zbbcqgWOmBOCcWlZ2/68pXZxkmmSjaHw9u6B6EKuZt W+ZWcNq4NlbBPUSLvDu/m1fV/YohkNpyASc906bU=
X-Virus-Scanned: Debian amavisd-new at crankycanuck.ca
Received: from mx4.yitter.info ([127.0.0.1]) by localhost (mx4.yitter.info [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Zw5sI3ttDOrO for <doh@ietf.org>; Mon, 19 Mar 2018 14:26:07 +0000 (UTC)
Date: Mon, 19 Mar 2018 10:26:04 -0400
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yitter.info; s=default; t=1521469567; bh=AmDoyLcfSMRLxu2XMFzJnoLbB+9h1zHPD48ijXu6CcU=; h=Date:From:To:Subject:References:In-Reply-To:From; b=RPv59XI1Tvl+0oOjojwoSTf223ZZACv6QgkgfWl9k5q6IbfmFF4a3OFKzpdOp1Qa3 dL1a8dByxEfqJjOrjMM5ezJ+iKek73rq+eUK5KZKsd0FxVxFTUq4SSSesJi2jo6a81 ko8mDa8+7Z1Wt6IGSUZaztC84eoK4r61AN1HoFis=
From: Andrew Sullivan <ajs@anvilwalrusden.com>
To: doh@ietf.org
Message-ID: <20180319142603.6jlcbrk2ank5sotc@mx4.yitter.info>
References: <CAKC-DJjtHE89A=vG5iS_0M_jqnWusDUDnwyernd+FC1VxxmU5Q@mail.gmail.com> <C03FF16F-CA2A-40AD-9138-C0F089ADA832@icann.org> <20180319103315.zubfti6m4zoscas5@mx4.yitter.info> <CAHbrMsCtzLh+kUPui730=SX3WHRjwYvgQ_TZXC_im3BNaoOyHQ@mail.gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <CAHbrMsCtzLh+kUPui730=SX3WHRjwYvgQ_TZXC_im3BNaoOyHQ@mail.gmail.com>
Archived-At: <https://mailarchive.ietf.org/arch/msg/doh/L9E-Z3vX0IuW85ruzAXMlAA2uFc>
Subject: Re: [Doh] [Ext] 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: Mon, 19 Mar 2018 14:27:17 -0000

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
ajs@anvilwalrusden.com