Re: [Doh] [Ext] Re: Use cases and URLs

Patrick McManus <> Wed, 07 March 2018 23:03 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 7F5291242F5 for <>; Wed, 7 Mar 2018 15:03:20 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: 2.102
X-Spam-Level: **
X-Spam-Status: No, score=2.102 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_SBL_CSS=3.335, SPF_SOFTFAIL=0.665, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 19bN4gWhE7Qh for <>; Wed, 7 Mar 2018 15:03:18 -0800 (PST)
Received: from ( [IPv6:2600:3c02::f03c:91ff:fe6e:e8da]) by (Postfix) with ESMTP id AFCF5120727 for <>; Wed, 7 Mar 2018 15:03:18 -0800 (PST)
Received: from ( []) by (Postfix) with ESMTPSA id 07B643A067 for <>; Wed, 7 Mar 2018 18:03:18 -0500 (EST)
Received: by with SMTP id f11so3688314otj.12 for <>; Wed, 07 Mar 2018 15:03:18 -0800 (PST)
X-Gm-Message-State: APf1xPDPqz318xVPHEgJlcKYPj+9STiPPuTOpQluaFXqE1b/HAUSyLCE UHrAQ7X5k0oHFipezi0UeXoR2UikhG2sV3gGEGc=
X-Google-Smtp-Source: AG47ELutmAgmrib8dO/4qCuZp2KwoGO8acbFBi4joQsSlb2ZHWTiLi2PrYq3WJ57aMcy731ObHfq+ekHUYnv7oHIv/Y=
X-Received: by with SMTP id g91mr17613108otg.2.1520463797714; Wed, 07 Mar 2018 15:03:17 -0800 (PST)
MIME-Version: 1.0
Received: by with HTTP; Wed, 7 Mar 2018 15:03:17 -0800 (PST)
In-Reply-To: <>
References: <> <> <> <> <>
From: Patrick McManus <>
Date: Wed, 7 Mar 2018 18:03:17 -0500
X-Gmail-Original-Message-ID: <>
Message-ID: <>
To: Paul Hoffman <>
Cc: Patrick McManus <>, "" <>
Content-Type: multipart/alternative; boundary="001a114c59d68e84bb0566da905f"
Archived-At: <>
Subject: Re: [Doh] [Ext] Re: Use cases and URLs
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: DNS Over HTTPS <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Wed, 07 Mar 2018 23:03:20 -0000

I believe that the level of discovery (i.e. you need to configure it) is
fine for the work the WG has adopted and the recursive resolver scope we're
working on. It is the normal approach for a web service.

While I don't see a lot of value in starting a separate new work item on
discovery I don't have a strong opinion on whether the wg should do that
beyond my suspicion that it wouldn't be widely used.

On Wed, Mar 7, 2018 at 4:49 PM, Paul Hoffman <> wrote:

> See above. In the edge case that I hear that my bank runs this secure DNS
> server but I don't know my bank's hostname, I am out of luck with DOH.
> That's fine.
I don't understand why we are talking about your bank's DNS server.  I
presume you mean that in context only with your interactions with the bank?

I know you mentioned some use cases around the browser using it to resolve
http urls instead of its global recursive resolver, but that's not
something that is in scope for the DoH WG (that would imo best be a HTTPbis
item - as it is how to route HTTP requests.. for which one possibility
among many is to define a discovery algorithm for a DoH endpoint based on
first party and define the scope of the result from that endpoint.. but
that's speculative and nobody is chartered to do that work.)

> OS configuration for DNS service has always been based on IP addresses
> because using a domain name to identify a server causes a pretty obvious
> chicken-and-egg problem. How is that relevant for DOH, which is based on
> URLs that already have a hostname in them?

it is relevant here because your proposal effectively maps a hostname to a
URL. It kinda looks like it maps it to N URLs but because there is no
useful way to discriminate between them other than configuration (which
could just use the URL), it is effectively just one. Your example did use
redundant servers, which wouldn't really need discrimination other than
perf/reachability, but the web already has plenty of ways of building
redundancies into unique urls and its ideal if the url descirbes the
resource, not the routing,


> Correct. This proposal is to make configuration easier. Are you objecting
> to making configuration easier, or to the notion that the DNS API server
> URL should be discoverable, or ...?
I'm definitely saying the DoH protocol doc does not need to further define