Re: [Doh] Use cases and URLs

Martin Thomson <> Wed, 07 March 2018 22:03 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 70E2912D95A for <>; Wed, 7 Mar 2018 14:03:29 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.699
X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id W1VlhqYaGnho for <>; Wed, 7 Mar 2018 14:03:25 -0800 (PST)
Received: from ( [IPv6:2607:f8b0:4003:c06::22d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 2C47212E036 for <>; Wed, 7 Mar 2018 14:03:25 -0800 (PST)
Received: by with SMTP id c83so2902152oib.1 for <>; Wed, 07 Mar 2018 14:03:25 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=VOrhiKW++3YGIe5Bb8WA3N0B7lLkNIUIu2zYrVpR3g0=; b=XIQQ1qS4aw7cI4j0X3il+jkuflX3s+uJHL0vA+V6JmKjEiQSaQKtP1Lw654BYwQEZz UV4q0yPLufcpiYXdU06QVSYQ4QdxSxsfBZKrTmdExI538BzFpXCe9uDrIFrh9HAiQXTR XDf6wGrUcW1LV05A3AZHCVkRTimDc1qOHRNUM2svMQhaeWwln288XvgwjzsRUx7W8rKY tdo3GEVDarq4eXlyjFZQ/KJUkoXjRfreJKsLfB2RYIQIAaqD81RB0GDorDAKnTWMtI7J MYiQ5GpnYLj4eWuksTR9fr1f3ANR3lZYhSuuCKdMsIbQXtOua1Ej5XZfdLEQgH+bfQ2Z Pimw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=VOrhiKW++3YGIe5Bb8WA3N0B7lLkNIUIu2zYrVpR3g0=; b=DjtPAXBohgwY9CBvOcHPqz3xF6FoanqQYa+C4aabAjyWOcTBSNTd0WnOeh5S3hwJgl ksYYJErfGqIa8sqQlzoNosIYZ47YUfkd2aMeFlkEo2ftecjApf/QnCWOFxMGZEK9J+k2 Ux+NL94uOOsmy8l+MxAwyqvR7itYvJb6gllNw8luBbRlg84VCMk4i5OxHaTeqU8fY2TJ lwpFL0RR9haI2OcBbdSP1DiYC1zBOKweUbWVIOnSlOeCOa1uhvfXGzC/H4OP+XGsJizi Jl0hVN6izWEEYGESVHliJABTN8nlQq7/3fHnClwyf6hcnh8jKMVrz1yf5vGH+YuzindH P4rg==
X-Gm-Message-State: AElRT7F1xm2UnVRxfQr3iEQ7JxvkQek6E6lTYO0KcYYYbD75SCG3O/cV PEj4m6xtYaI9rNEiqHtc7WsHAlOLv6mt0bjeH+huNg==
X-Google-Smtp-Source: AG47ELuxQojZvf1K7AS5y8axxawbiuYfJ8cRnuLNYW8fo3a+gEPoe2yLGOrzqKDkTe2CqNG/co+z0Qi4KFVDsnjO7JM=
X-Received: by with SMTP id 8mr15581454oin.272.1520460204437; Wed, 07 Mar 2018 14:03:24 -0800 (PST)
MIME-Version: 1.0
Received: by with HTTP; Wed, 7 Mar 2018 14:03:24 -0800 (PST)
In-Reply-To: <>
References: <>
From: Martin Thomson <>
Date: Thu, 8 Mar 2018 09:03:24 +1100
Message-ID: <>
To: Paul Hoffman <>
Cc: "" <>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Archived-At: <>
Subject: Re: [Doh] 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 22:03:29 -0000

Still having trouble with this.  Think about how you interact with a
browser.  You might type "" knowing that this gets you ICANN,
and that is magically turned into "" (yeah, the
missing 's' remains an embarrassing omission, but that's harder to fix
than it seems).  Fewer people do that than you think, because that's
the role that search engines fill now.  You might also type
"", but even fewer do that.

Why do you believe that servicing this market in this way is such an
imperative?  Search the web, find the string you want, copy and paste.
In fact, it serves the point of separation very effectively.  If your
configuration lists "" or "dns.provider.example", then the
string "https://dns.provider.example/" might signify an important
difference in how the software uses that string.  Note the huge
difference in those last two examples does not - in my opinion -
motivate the architectural violence you advocate for.

On Wed, Mar 7, 2018 at 2:49 PM, Paul Hoffman <> wrote:
> Greetings again. In the discussions in the last month since draft-ietf-doh-dns-over-https-03 came out, particularly at the DNS Privacy Workshop at NDSS, it has become clear that there are a lot of use cases that are related to the two given in Section 3 of the draft, but are not called out explicitly. They fall under the sentence "They might use the DOH server for all queries, or only for a subset of them."
> Some that I have heard are (approximately):
> - Use the preferred DNS API server for all DNS lookups in the browser whenever the browser is running (start the TLS session with the DNS API when the browser starts).
> - If a tab/window for the origin of a configured DNS API server is open, use the configured API server for all DNS lookups.
> - If a tab/window for the origin of a configured DNS API server is open, use the configured API server for DNS lookups that are in that origin only.
> - If a tab/window for the origin of a configured DNS API server is open, and the configured API server pushes DNS information, accept it.
> (Note that you might like or dislike some of these; that's fine.)
> In addition, there has been the assumption by many people that they could add new DNS API servers to the list of configured servers in the browser based on various out-of-band information (articles, word-of-mouth, ...). That is, people want the additional DNS privacy through a somewhat-trusted web site rather than no privacy from the who-knows-where they are getting now. (Don't forget that the vast, vast majority of users are doing DNS lookups using resolvers they have no idea about.)
> The ability to add new DNS APIs servers leads to the question of the URL being used for a particular DNS API server. In early drafts, we used "https://<origin>/.well-known/dns-query?..." as the standard URL, but it was pointed out that such a standard is prohibited by RFC 5785. The current draft says that there is no standard, and every origin will have its own URL for the API. This makes it much harder for a user to add new configured DNS API servers and thus reduces the chance that some of their DNS queries will be private, based on which of the use cases get implemented.
> A protocol point between "here is the fixed URL" and "every origin has its own URL" is "discover the policy for an origin to serve as a DNS API server". That is, use the RFC 5785 ".well-known" scheme as a way to find out what the origin's policy is. That way, a user can configure new servers in their browser only knowing the origin name (which is all they really understand anyway...).
> A first guess of a proposal would be that "https://<origin>/.well-known/dns-query/" returns a JSON object that looks like:
>    { "has-DNS-API": true, "DNS-API-URLs":
>       [ "https://<origin>/admin-dns/?", "https://<origin>/backup-dns/?" ] }
> This uses the .well-known for what it is supposed to be used for, and gives each origin a chance to pick their own URL scheme. Getting no response or "{ "has-DNS-API": false }" both tell the user that origin's policy as well, of course.
> Thoughts?
> --Paul Hoffman
> _______________________________________________
> Doh mailing list