IETF Logo Mail Archive

Re: [DNSOP] [Ext] draft-sah-resolver-information (revised)

Paul Hoffman <paul.hoffman@icann.org> Fri, 24 May 2019 01:07 UTC

Return-Path: <paul.hoffman@icann.org>
X-Original-To: dnsop@ietfa.amsl.com
Delivered-To: dnsop@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 70EA51201D6 for <dnsop@ietfa.amsl.com>; Thu, 23 May 2019 18:07:00 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.2
X-Spam-Level:
X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham 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 m83heKhXZ0Im for <dnsop@ietfa.amsl.com>; Thu, 23 May 2019 18:06:59 -0700 (PDT)
Received: from mail.icann.org (out.west.pexch112.icann.org [64.78.40.10]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E1F821201D1 for <dnsop@ietf.org>; Thu, 23 May 2019 18:06:58 -0700 (PDT)
Received: from PMBX112-W1-CA-1.pexch112.icann.org (64.78.40.21) by PMBX112-W1-CA-2.pexch112.icann.org (64.78.40.23) with Microsoft SMTP Server (TLS) id 15.0.1367.3; Thu, 23 May 2019 18:06:56 -0700
Received: from PMBX112-W1-CA-1.pexch112.icann.org ([64.78.40.21]) by PMBX112-W1-CA-1.PEXCH112.ICANN.ORG ([64.78.40.21]) with mapi id 15.00.1367.000; Thu, 23 May 2019 18:06:56 -0700
From: Paul Hoffman <paul.hoffman@icann.org>
To: Erik Nygren <erik+ietf@nygren.org>
CC: dnsop <dnsop@ietf.org>
Thread-Topic: [Ext] [DNSOP] draft-sah-resolver-information (revised)
Thread-Index: AQHVEcz7aATKLfvOj0q33w2i8nhAAQ==
Date: Fri, 24 May 2019 01:06:56 +0000
Message-ID: <1444A5A2-B814-42D6-83DF-978B6CF1BDE2@icann.org>
References: <3BCCE28D-17C6-4367-A9C3-D0DCF56AB03A@icann.org> <alpine.LRH.2.21.1905151256480.22294@bofh.nohats.ca> <C3668C33-E3DB-4267-AF5B-FDC46262CC8F@icann.org> <alpine.LRH.2.21.1905152258340.18222@bofh.nohats.ca> <0F4F5B08-A81B-48D4-AAFE-F89FEE980F9A@icann.org> <CAKC-DJhmQMMCRJAJTB4ZG1MmxohKS12KPXuBwwbmVXFR=ubWFQ@mail.gmail.com>
In-Reply-To: <CAKC-DJhmQMMCRJAJTB4ZG1MmxohKS12KPXuBwwbmVXFR=ubWFQ@mail.gmail.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-ms-exchange-messagesentrepresentingtype: 1
x-ms-exchange-transport-fromentityheader: Hosted
x-originating-ip: [192.0.32.234]
Content-Type: text/plain; charset="us-ascii"
Content-ID: <A47815D7EC0DA44192CEEA7F9E8B3219@pexch112.icann.org>
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/y-rOfnIhqEQe72L5eyexbjWGNz0>
Subject: Re: [DNSOP] [Ext] draft-sah-resolver-information (revised)
X-BeenThere: dnsop@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: IETF DNSOP WG mailing list <dnsop.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dnsop>, <mailto:dnsop-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/dnsop/>
List-Post: <mailto:dnsop@ietf.org>
List-Help: <mailto:dnsop-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dnsop>, <mailto:dnsop-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 24 May 2019 01:07:00 -0000

On May 22, 2019, at 7:01 PM, Erik Nygren <erik+ietf@nygren.org> wrote:
> 
> Some comments:
> 
> * We should define what TLS SNI value gets sent.  Perhaps the first value of "domain-to-match" when present, but preferably the hostname of the URL when it's not an IP?

The "domain-to-match" values are not known until after the query has been responded to. Thus, it seems like the only likely SNI value would be the domain name of the resolver, if the application knows that. We can include that in a future draft.

> * Should clients consider the templates list to be ordered or unordered?  We may wish to define the behavior for handling multiple entries.  (A common case might be both an IPv6 and IPv4 address.  Some clients might only have only one of those, so would need to filter appropriately, and operators may wish to specify an ordering preference such as IPv6-preferred.)

Our first guess was "unordered". The draft says:
   If the "template" array has more than one string, a client
   can consider them all to be of equal value when finding a
   DoH server associated with the resolver.
My personal view is that suggesting order always complicates processing for very little actual gain. Assume that clients are smart if they want to be smart.

> * It would be worth a conversation with the people working on PvD in IntArea to see if there is some alignment (eg, in-terms of JSON practices, and perhaps even with PvDs being able to include or reference a resolver-information block).  There might be a path here that could also help with the split-horizon case.

The PvD folks are free to do their JSON however they want. It may be premature to try to add DoH information to their document.

> * With the draft-sah-resolver-information framework, we may wish to also have an attribute or draft for specifying the DNS64 prefix to allow client-side DNS64 synthesis.  (On the other hand, there are also drafts to send this via an RA option as well as some other paths in-addition to other mechanisms.  So perhaps another mechanism isn't needed.)

draft-sah-resolver-information framework makes it easy for anyone to suggest new additions to the information.

--Paul Hoffman

v2.23.0 | Report a Bug | By Email