Subject: [Doh] Use Cases

From: Mark Nottingham <[email-masked]>
Date: Thu, 16 Nov 2017 15:53:59 +0800

In the meeting, I said that it might be helpful to have an explicitly defined use case. Paul mentioned the document already covers this:

"""
3.  Use Cases

   There are two primary use cases for this protocol.

   The primary use case is to prevent on-path network devices from
   interfering with native DNS operations.  This interference includes,
   but is not limited to, spoofing DNS responses, blocking DNS requests,
   and tracking.  HTTP authentication and proxy friendliness are
   expected to make this protocol function in some environments where
   unsecured DNS ([DNS]) or DNS directly on TLS ([RFC7858]) would not.

   A secondary use case is web applications that want to access DNS
   information.  Standardizing an HTTPS mechanism allows this to be done
   in a way consistent with the cross-origin resource sharing security
   model of the web [CORS] and also integrate the caching mechanisms of
   DNS with those of HTTP.  These applications may be interested in
   using a different media type than traditional clients.
"""

That speaks to the motivations, but not how it will actually be achieved using this protocol. I suggest:

"""
3. Use Cases

There are two initial use cases for this protocol.

The primary use case is to prevent on-path network devices from interfering with DNS operations. This interference includes, but is not limited to, spoofing DNS responses, blocking DNS requests, and tracking. 

In this use, clients -- whether operating systems or individual applications -- will be explicitly configured to use a DOH server as a recursive resolver by its user (or administrator). They might use the DOH server for all queries, or only for a subset of them. The specific configuration mechanism is out of scope for this document.

A secondary use case is allowing web applications to access DNS information, by using existing APIs in browsers to access it over HTTP. 

This is technically already possible (since the server controls both the HTTP resources it exposes and the use of browser APIs by its content), but standardisation might make this easier to accomplish. 

Note that in this second use, the browser does not consult the DOH server or use its responses for any DNS lookups outside the scope of the application using them; i.e., there is (currently) no API that allows a Web site to poison DNS for others.
"""

--
Mark Nottingham   https://www.mnot.net/

---

From: "Paul Hoffman" <[email-masked]>
Date: Thu, 16 Nov 2017 18:17:01 +0800

On 16 Nov 2017, at 15:53, Mark Nottingham wrote:

> interfering with DNS operations. This interference includes, but is 
> not limited to, spoofing DNS responses, blocking DNS requests, and 
> tracking.
>
> In this use, clients -- whether operating systems or individual 
> applications -- will be explicitly configured to use a DOH server as a 
> recursive resolver by its user (or administrator). They might use the 
> DOH server for all queries, or only for a subset of them. The specific 
> configuration mechanism is out of scope for this document.
>
> A secondary use case is allowing web applications to access DNS 
> information, by using existing APIs in browsers to access it over 
> HTTP.
>
> This is technically already possible (since the server controls both 
> the HTTP resources it exposes and the use of browser APIs by its 
> content), but standardisation might make this easier to accomplish.
>
> Note that in this second use, the browser does not consult the DOH 
> server or use its responses for any DNS lookups outside the scope of 
> the application using them; i.e., there is (currently) no API that 
> allows a Web site to poison DNS for others.
> """

This seems like a good replacement.

--Paul Hoffman

---

From: Tony Finch <[email-masked]>
Date: Thu, 16 Nov 2017 12:04:16 +0000

> using this protocol. I suggest:

I like this suggestion - very clear.

Tony.
-- 
f.anthony.n.finch  <[email-masked]>  http://dotat.at/  -  I xn--zr8h punycode
Hebrides, Bailey: West 7 to severe gale 9. Very rough or high. Squally
showers. Good.