Re: [Doh] Use cases and URLs

Still having trouble with this.  Think about how you interact with a
browser.  You might type "icann.org" knowing that this gets you ICANN,
and that is magically turned into "http://icann.org/" (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
"icann.org/dns", 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 "9.9.9.9" 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 <paul.hoffman@icann.org> 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
> Doh@ietf.org
> https://www.ietf.org/mailman/listinfo/doh