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

[Ben Schwartz <[e-mail]>]

On Sun, Mar 18, 2018 at 5:22 AM, Patrick McManus <[e-mail]>
wrote:

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

Thanks for the very clear writeup, Patrick.  Indeed, it's not in our
charter to mess with any of that stuff.  However, it is worthwhile for us
to produce a document that is intelligible to DNS experts who do not have
deep experience in HTTP.  It seems we have some work to do there, and
restating relevant results from other drafts may be an appropriate way to
improve clarity.


>
>
>>
>
> _______________________________________________
> Doh mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/doh
>
>