Re: [Doh] assorted things

[Patrick McManus <[e-mail]>]

Hey Bert,

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

>
> Does this say "don't just use any URI"?  What are 'DNS resolution
> 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

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

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).



> 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?
>
>
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).