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

[Ted Hardie <[e-mail]>]

Howdy,

First, my apologies that this may be incoherent; I'm somewhat jet-lagged
and the issue that I'm trying to raise has been slippery to discuss in the
side conversations I've tried to have today.  Underneath that lack clarity,
though, is what I believe is a somewhat structural question.

Reading the doc on the way over, I found myself tumbling down a couple of
rat-holes on the interaction between the HTTP protocol mechanics and their
mapping to DNS semantics.  When I started talking to other folks about
those, a couple more DNS semantics mapping to HTTP semantics issues came
up.  Trying to work those through, I found myself grappling with this:

   The described approach is more than a tunnel over HTTP.  It
   establishes default media formatting types for requests and responses
   but uses normal HTTP content negotiation mechanisms for selecting
   alternatives that endpoints may prefer in anticipation of serving new
   use cases.  In addition to this media type negotiation, it aligns
   itself with HTTP features such as caching, proxying, and compression.

   The integration with HTTP provides a transport suitable for both
   traditional DNS clients and native web applications seeking access to
   the DNS.

What concerns me is that the appropriate methods for mapping between HTTP
and DNS semantics may not be quite the same for those two use cases.  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.

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

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.

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.

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.

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.

Whatever the cause, I believe that additional clarity here is important and
that some text specifically on the interplay in semantics would be useful.
I believe that this is particularly important for the traditional DNS
client use case, as there is an existing state machine there which will be
also be used with DNS over TLS, DNS over TCP, and DNS over UDP.  The more
consistency those clients have in the treatment of underlying transports,
the better life will be for them.

Again, my apologies if this is not clear, but I wanted to write something
before the meeting.

regards,

Ted