Re: [Doh] [Ext] assorted things
Paul Hoffman <paul.hoffman@icann.org> Tue, 05 June 2018 14:42 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 F1B151310BE for <doh@ietfa.amsl.com>; Tue, 5 Jun 2018 07:42:27 -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 BPYQ4-eUYiDu for <doh@ietfa.amsl.com>; Tue, 5 Jun 2018 07:42:26 -0700 (PDT)
Received: from out.west.pexch112.icann.org (pfe112-ca-2.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 8606C131002 for <doh@ietf.org>; Tue, 5 Jun 2018 07:42:26 -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; Tue, 5 Jun 2018 07:42:24 -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; Tue, 5 Jun 2018 07:42:24 -0700
From: Paul Hoffman <paul.hoffman@icann.org>
To: bert hubert <bert.hubert@powerdns.com>
CC: "doh@ietf.org" <doh@ietf.org>
Thread-Topic: [Ext] [Doh] assorted things
Thread-Index: AQHT/MnAMTM+RUINW0SyNYIuXR3MXKRSMpmA
Date: Tue, 05 Jun 2018 14:42:23 +0000
Message-ID: <95D1F35A-B7C4-4AF9-B682-CA1C17DCE34F@icann.org>
References: <20180605123541.GB29047@server.ds9a.nl>
In-Reply-To: <20180605123541.GB29047@server.ds9a.nl>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: yes
X-MS-TNEF-Correlator:
x-ms-exchange-messagesentrepresentingtype: 1
x-ms-exchange-transport-fromentityheader: Hosted
x-originating-ip: [192.0.32.234]
Content-Type: multipart/signed; boundary="Apple-Mail=_54AB44F6-906C-477A-8FF6-B6FDB0FD36C5"; protocol="application/pkcs7-signature"; micalg="sha1"
MIME-Version: 1.0
Archived-At: <https://mailarchive.ietf.org/arch/msg/doh/Qoas8_B9A2INuZ0cPlY57caSZBw>
Subject: Re: [Doh] [Ext] assorted things
X-BeenThere: doh@ietf.org
X-Mailman-Version: 2.1.26
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: Tue, 05 Jun 2018 14:42:29 -0000
On Jun 5, 2018, at 5:35 AM, bert hubert <bert.hubert@powerdns.com> wrote: > > Hi everyone, > > I'm going through -10 with fresh eyes, so I may be discovering some parts > that are not obvious to the outsider, or at least this reader. > > This paragraph in 4 seems to be important, but I can't figure out what it is > trying to achieve: > > A DNS API client MUST NOT use a different URI simply because it was > discovered outside of the client's configuration, or because a server > offers an unsolicited response that appears to be a valid answer to a > DNS query. This specification does not extend DNS resolution > privileges to URIs that are not recognized by the DNS API client as > configured URIs. Such scenarios may create additional operational, > tracking, and security hazards that require limitations for safe > usage. A future specification may support this use case. > > Does this say "don't just use any URI"? It says "don't use a URI that is not configured". > What are 'DNS resolution > privileges'? The equivalent of "a DNS open resolver that you discovered by accident". > Is this about disallowing javascript to send out random DNS > queries? No. It is about them sending out queries to servers not in their configuration. > > This sentence: > > Some of these non-successful HTTP responses (e.g., redirects or > authentication failures) could mean that clients need to make new > requests to satisfy the original question. > > I would recommending teeth to this. Naive implementations may decide to not > follow 3xx codes. I would recommend making this explicit with a MUST. Good catch. We assume that developers of DNS API clients will follow HTTP semantics here, but we didn't say so explicitly. > Also, > it may be worth it to explicitly say if authentication is in our out of > scope. No, definitely not. Authentication is completely in scope. > Here it is a bit uncertain if you'd ever prompt a user for a > username/password for doing DNS resolution. HTTP authentication does not require a UI at all. > > In 6.3 "Server Push": > For HTTP server push ([RFC7540] Section 8.2) extra care must be taken to > ensure that the pushed URI is one that the client would have directed the > same query to if the client had initiated the request. > > This means an API server is free to send responses to DNS queries we haven't > seen yet? And should a client do something with that? Or can it ignore the > pushed records? Yes; not "should" but "may"; yes. This is all well-defined in HTTP/2. --Paul Hoffman
- [Doh] assorted things bert hubert
- Re: [Doh] assorted things Daniel Stenberg
- Re: [Doh] [Ext] assorted things Paul Hoffman
- Re: [Doh] assorted things Patrick McManus