Re: [Doh] A question on the mix of DNS and HTTP semantics

[Patrick McManus <[e-mail]>]

Hi Ted, thanks for writing this down. I think I understand it a bit better
now.

I think the most relevant point is that DoH is the use of HTTP as a
substrate. As a user of HTTP RFC7231 is very relevant (HTTP status codes)


On Sat, Mar 17, 2018 at 5:42 PM, Ted Hardie <[e-mail]> wrote:

>   In particular, the HTTP semantics for redirection (e.g. HTTP response
> 307 or 308) and client error (e.g. HTTP response 403 or 451) may be
> difficult to map back into DNS errors when the target is a traditional DNS
> client.
>
>
7231 defines 2xx as success. If your code is not 2xx then your DoH request
did not succeed and you can feel confident in saying that you do not have a
dns response to the dns request that was made in the http request.
Conversely, a 2xx response needs to carry a DNS reply to your DNS request.
(now that can be a DNS failure - nxdomain, etc, but the 2xx at the HTTP
level is saying a valid DNS response to your request is contained therein..
i.e. DoH has succeeded).

non 2xx levels of response do not carry the answer to the DNS query. The
message in those responses is basically just FYI. HTTP allows you to put
any media type you want in there, so I'm not going to tell you you cannot
put DNS information in the body of a 404 if you think that's good FYI, but
I am going to say the body of a 4xx is not the dns answer to the DoH
request that generated it.

A client may or may not be able to go further based on the response code.
e.g. a 3xx code can obviously be taken further with another request, as can
401, or maybe even 405. There is a general expectation that clients that
can act on http response codes other than 2xx do so, but its their
decision. So I would say all HTTP clients, including DoH clients but not in
any special way, are expected to follow redirects within the scope of how
the particular redirect is defined, and the message body of the [345]xx is
not very interesting.

As noted above, if you don't end this process with a 2xx you don't have a
DNS response to the DNS query of the original request - the transport has
failed. I would say you should map that into the traditional DNS in the
same fashion as any other transport failure.. e.g. UDP timing out, or TCP
generating RST, or TLS failing verification. An HTTP non-success isn't
going to give you rich DNS information.. if the failure is at the DNS level
and not the DOH level, then the DNS failure can be carried in a 2xx HTTP
response.

I hope all that helps. I hope that's what things like BCP56bis are aimed at
- we don't want to write down all the HTTP rules for every application that
uses HTTP as a substrate each time. And of course I would expect that new
DoH clients would reuse old HTTP stacks where possible as they should
already encapsulate these rules.


> To take an example from the redirection side, if a client has configured
> an ordered list of recursive resolvers and gets a redirect from the DOH
> server, it could theoretically either follow the redirect or move down its
> own list (treating the redirect as an offered member for the list, but
> sorted below the current list).  The behavior for that might be influenced
> by the body included in the response. A 307 with a response body containing
> the UDP wire format DNS response for SRVFAIL, for example, might cause the
> DNS client to move down the ordered list, where a 307 with no response body
> might be handled entirely within HTTP's semantics, prior to returning a
> message to the DNS client code.  (Note that the choice between these two
> may result in different privacy considerations, especially if resolvers
> later in the list do not use DOH or DNS over TLS).
>

The udp body in the 307 that you posit is not the dns response to the
original dns question it is just FYI and doesn't have a programmatic
interpretation in the way the 307 and the Location response header do. The
expectation is that if you would like to complete that original request you
should make a new request to the redirected location. Aborting or pushing a
new approach on top of the stack is fine, but I feel like you feel you're
getting more information from that 307 than you really are. All you know is
its in progress and how to continue.



> Similarly, it was not clear to me whether a response like 451 could
> contain a UDP wireformat body and, if so, what it would be.  If it contains
> no body, the DNS implementation might continue attempting to query for the
> information..  If it contains a REFUSED RCODE, in contrast, it would see a
> policy-based error.  The document simply provides very little guidance on
> how to handle cases like these.
>
>
Similarly to above, 451 is defined by 7225. DoH seeks to _not_ restate all
the existing HTTP definitions, it just seeks to use them. If DoH was doing
something inconsistent with 7225 that would imo probably be a doh bug. In
the case of 451 In this case 7225 defines the response body as a human
readable description of the censorship - so I don't think wireformat would
be a good choice. (7225 doesn't make an exception for non human clients, of
which there have always been many). It is interesting to note how the code
itself is indeed actionable - the DoH client might choose to repeat the
same query of a VPN or Tor knowing this information.



> There appear to be two extreme positions possible:
>
> 1) DOH servers should, as much as possible, encode all the semantics in
> UDP wireformat DNS messages and return appropriate messages when using
> HTTP's redirection, authorization, or caching semantics.  Clients can then
> act on the DNS messages within a structure that may include other recursive
> resolvers.
>

I hope this message has shed some light on this. wireformat in a non 2xx
response, while legal, is not the response to the dns query in the http
request. I would say its probably not a good idea either, but ymmv.


> 2) DOH clients should use HTTP semantics as faithfully as possible,
> returning UDP wireformat DNS messages only after the full HTTP protocol
> mechanics have been worked out and synthesizing DNS messages (such as
> SRVFAIL) when these are implied by the HTTP exchange.
>
>
I hope the situation is a bit clearer that this - but yes this is closer.


> The document leans more toward 2 than 1, but does not do so in a way that
> makes it mandatory; you would appear to be able to write a conformant
> server or client using either theory (or much in between).  I suspect that
> leaning is due to the web application use case's presumed popularity
> compared to the traditional DNS client use case, but I could be wrong.
>
> I think I disagree here. While you can indeed stick wireformat into all
kinds of non 2xx responses, I do not believe it means what you thought it
meant when you wrote this :)



> Whatever the cause, I believe that additional clarity here is important
> and that some text specifically on the interplay in semantics would be
> useful.
>

The text you cited in the top of your mail (which I've trimmed here
prematurely) was meant to be part of that, but more important the "over
HTTP" parts are meant to make it clear that HTTP semantics carry the DNS
semantics.

I'm certainly happy to add a sentence or two to help make that more clear
(suggestions?) but I don't want to start defining/reiterating HTTP
semantics in the DoH doc - we've already got lots of documents (i.e.
rfc723x.. which are all included normatively by 7230 which doh includes
normatively) that do that and its not in doh's charter to mess those things
anyhow.


>