Re: [Doh] [Ext] New version: draft-ietf-doh-resolver-associated-doh-03.txt

Paul Hoffman <paul.hoffman@icann.org> Mon, 25 March 2019 15:25 UTC

Return-Path: <paul.hoffman@icann.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 B56AE1203CB for <doh@ietfa.amsl.com>; Mon, 25 Mar 2019 08:25:50 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.201
X-Spam-Level:
X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-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 l8HESLbaKAVo for <doh@ietfa.amsl.com>; Mon, 25 Mar 2019 08:25:49 -0700 (PDT)
Received: from out.west.pexch112.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 EAD561203C5 for <doh@ietf.org>; Mon, 25 Mar 2019 08:25:48 -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; Mon, 25 Mar 2019 08:25:46 -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; Mon, 25 Mar 2019 08:25:46 -0700
From: Paul Hoffman <paul.hoffman@icann.org>
To: Ralf Weber <dns@fl1ger.de>
CC: DoH WG <doh@ietf.org>
Thread-Topic: [Ext] [Doh] New version: draft-ietf-doh-resolver-associated-doh-03.txt
Thread-Index: AQHU4x8ESCmlJ+SFTkKwlZVf9bBsZQ==
Date: Mon, 25 Mar 2019 15:25:46 +0000
Message-ID: <39393D27-1905-4832-B9A7-D5BBA1A7FA7C@icann.org>
References: <155341529409.18062.10657099011172813446@ietfa.amsl.com> <55AE7511-5BDF-4E96-84B3-BD0B6E6C6FE3@icann.org> <BDAC592D-32C6-40C4-ADD1-18D1C342DAA2@fl1ger.de>
In-Reply-To: <BDAC592D-32C6-40C4-ADD1-18D1C342DAA2@fl1ger.de>
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.47.234]
Content-Type: text/plain; charset="utf-8"
Content-ID: <2F24CEFFBB07364BA5AB01137135D99B@pexch112.icann.org>
Content-Transfer-Encoding: base64
MIME-Version: 1.0
Archived-At: <https://mailarchive.ietf.org/arch/msg/doh/7xIjrFwrrNTyQaFF_b3-VhWwPAU>
Subject: Re: [Doh] [Ext] New version: draft-ietf-doh-resolver-associated-doh-03.txt
X-BeenThere: doh@ietf.org
X-Mailman-Version: 2.1.29
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, 25 Mar 2019 15:25:51 -0000

On Mar 25, 2019, at 4:05 PM, Ralf Weber <dns@fl1ger.de> wrote:
> I have some questions after reading -03 (and skipping -02 ;-)
> - The resolver IP addresses returned from DNS on section 4 are these Do53 server addresses or DoH server address or are they just the IP to start the process in section 2 (maybe 3)?

They are the IP addresses of the Do53 resolver that the computer is using. I'll make that clearer in the next draft.

> - On section 3 a non compliant current server will return NXDomain. What are we going to do with this answer (treat is as no DoH associated)?

Yes, that was the intention. I'll clarify that.

>> As for the late discussion of using the URI RRtype instead of TXT, I would not know what to put in the "priority" and "weight" values. That alone seems enough reason to leave this as a TXT record, but others might disagree. It's not a lot of effort to change the text to the URI RRtype, but I don't want to do so unless it is actually better than TXT.
> Another option could be a new RRType, given that it doesn’t have to be provisioned on auth servers it should not be that difficult to roll it out. We still could use the special name or just ask .

I have been told that some OSs have "send a TXT request" API call, but I have not verified that. If so, then TXT records will have an advantage. Otherwise, using a new RRtype is cleaner.

Can someone who from the application implementation world verify or refute my hazy memory of API calls for TXT records?

--Paul Hoffman