Re: [Doh] [Ext] assorted things

Paul Hoffman <> Tue, 05 June 2018 14:42 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id F1B151310BE for <>; Tue, 5 Jun 2018 07:42:27 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -4.2
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 ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id BPYQ4-eUYiDu for <>; Tue, 5 Jun 2018 07:42:26 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 8606C131002 for <>; Tue, 5 Jun 2018 07:42:26 -0700 (PDT)
Received: from ( by ( with Microsoft SMTP Server (TLS) id 15.0.1367.3; Tue, 5 Jun 2018 07:42:24 -0700
Received: from ([]) by PMBX112-W1-CA-1.PEXCH112.ICANN.ORG ([]) with mapi id 15.00.1367.000; Tue, 5 Jun 2018 07:42:24 -0700
From: Paul Hoffman <>
To: bert hubert <>
CC: "" <>
Thread-Topic: [Ext] [Doh] assorted things
Date: Tue, 5 Jun 2018 14:42:23 +0000
Message-ID: <>
References: <>
In-Reply-To: <>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: yes
x-ms-exchange-messagesentrepresentingtype: 1
x-ms-exchange-transport-fromentityheader: Hosted
x-originating-ip: []
Content-Type: multipart/signed; boundary="Apple-Mail=_54AB44F6-906C-477A-8FF6-B6FDB0FD36C5"; protocol="application/pkcs7-signature"; micalg=sha1
MIME-Version: 1.0
Archived-At: <>
Subject: Re: [Doh] [Ext] assorted things
X-Mailman-Version: 2.1.26
Precedence: list
List-Id: DNS Over HTTPS <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Tue, 05 Jun 2018 14:42:29 -0000

On Jun 5, 2018, at 5:35 AM, bert hubert <>; 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