Subject: [Doh] assorted things

From: bert hubert <[email-masked]>
Date: Tue, 5 Jun 2018 14:35:41 +0200

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"?  What are 'DNS resolution
privileges'? Is this about disallowing javascript to send out random DNS
queries? 

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. Also,
it may be worth it to explicitly say if authentication is in our out of
scope. Here it is a bit uncertain if you'd ever prompt a user for a
username/password for doing DNS resolution. 

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?

	Bert

---

From: Daniel Stenberg <[email-masked]>
Date: Tue, 5 Jun 2018 15:19:06 +0200 (CEST)

On Tue, 5 Jun 2018, bert hubert wrote:

> scope.

Isn't all of this basically just how HTTP works and offers? RFC 7231 section 
6.4 explains redirects just fine I think and HTTP authentication is certainly 
a part of HTTP and is explained in RFC7235.

> Here it is a bit uncertain if you'd ever prompt a user for a 

To me that sounds more like a UI/program decision and not something we need to 
specify.

> seen yet?  And should a client do something with that?

Yes, basically. See RFC 75450 section 8.2.

> Or can it ignore the pushed records?

A HTTP/2 client can always opt to either not ever accept pushed resources or 
deny them when offered.

-- 

  / daniel.haxx.se

---

From: Paul Hoffman <[email-masked]>
Date: Tue, 5 Jun 2018 14:42:23 +0000

On Jun 5, 2018, at 5:35 AM, bert hubert <[email-masked]> wrote:
> 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.

> 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,

No, definitely not. Authentication is completely in scope.

> username/password for doing DNS resolution. 

HTTP authentication does not require a UI at all.

> seen yet?  And should a client do something with that?  Or can it ignore the

Yes; not "should" but "may"; yes. This is all well-defined in HTTP/2.

--Paul Hoffman

---

From: Patrick McManus <[email-masked]>
Date: Tue, 5 Jun 2018 16:46:51 +0200

Hey Bert,

On Tue, Jun 5, 2018 at 2:35 PM, bert hubert <[email-masked]>
wrote:

> privileges'

every DoH exchange has a URI - if the URI isn't one your client is cool
with - don't use it. e.g. when a DoH exchange arrives via push, check the
URI as your first filter.

> ? Is this about disallowing javascript to send out random DNS
> queries?
>
> no

 >. Naive implementations may decide to not

> scope

That non-normative text is just there to remind the reader, who may not be
that familiar with http, about the way http works. Specifically the group
wanted to emphasize that DNS errors are only carried in successful HTTP
responses, non-successful responses have HTTP semantics. This is a further
reminder that we say non-successful rather than failed because some codes
(like 3xx) can still be worked out successfully if the HTTP client wants to
try harder with another request.. but that's all governed by HTTP, not DoH
in particular. (And there are lots of these cases - so enumerating them
rather than just relying on HTTP semantics is probably not the right
thing.. a DoH implementation needs a full HTTP implementation - likely via
library or other tool).

> seen yet?  And should a client do something with that?  Or can it ignore
it can ignore them if it likes. It can cache them if it likes. In practice
it can even configure HTTP/2 to prevent or flow control them if it likes
(its an http feature, and we don't enumerate every knob http provides or
may evolve - we just stick to the semantics it provides).