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

From: Ted Hardie <[email-masked]>
Date: Sat, 17 Mar 2018 10:42:08 -0700

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

---

From: Patrick McManus <[email-masked]>
Date: Sun, 18 Mar 2018 09:22:38 +0000

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 <[email-masked]> 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

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

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

> SRVFAIL) when these are implied by the HTTP exchange.
I hope the situation is a bit clearer that this - but yes this is closer.

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

---

From: Tony Finch <[email-masked]>
Date: Sun, 18 Mar 2018 10:11:41 +0000

Yesterday at the IETF 101 Hakathon I was working on a DoH server. I've
written up some notes at https://fanf.dreamwidth.org/123507.html for
those who might be interested.

I was going to send this as a separate thread, but it's basically the same
topic as Ted's message, so I'm sending it as a reply. The approach I have
taken is basically Ted's option (2). The rest of this message is what I
wrote before reading Ted's note...

One of the questions I bumped into was what kind of HTTP errors my
server should generate. I have had another quick look through the
draft but I couldn't see anything particularly addressing this issue.
So here are some sketchy suggestions.

In the following I say "browser-friendly" to mean `text/html` or
`text/plain` or something like that, but definitely not
`application/dns-udpwireformat`.

If the request is not HEAD/GET/POST, I return 405 Method Not Allowed
with a browser-friendly body.

For POST requests with an unknown Content-Type, or GET requests with
an unknown or missing `ct=` parameter, my server returns 415
Unsupported Media Type with a browser-friendly body.

If the `dns=` parameter is missing from a GET request, the best
response seems to be a browser-friendly 400 Bad Request. Sam Kington
(not an IETFer afaik) suggested 422 Unprocessable Entity, but that
implies the request is well-formed which isn't really the case. (My
server returns 418 I'm A Teapot for fun.) Bad `base64url` encoding
should produce the same response.

If the request's Accept: header doesn't allow
`application/dns-udpwireformat` then the response should be a
browser-friendly 406 Not Acceptable.

I think if the request passes these checks, the server knows it has a
request in DNS format and a client that wants a response in DNS
format, so it can just hand over to its DNS processing code.
Regardless of the DNS RCODE in the response, the HTTP status code
should be 200 OK.

My logic up to this point is to send a browser-friendly response if
the client seems to be unprepared to talk to a DoH server. There are
some other cases - e.g. HTTP authentication or redirects - which ought
to be handled by the HTTP layers before the request processing gets to
the DoH logic, so in these cases the response bodies will naturally be
browser-friendly. But perhaps it's worth noting them in the draft so
that DoH clients should be prepared to handle them gracefully.

Tony.
-- 
f.anthony.n.finch  <[email-masked]>  http://dotat.at/  -  I xn--zr8h punycode
Dover, Wight, Portland, Plymouth: Northeast, becoming cyclonic in Portland and
Plymouth, 6 to gale 8. Moderate or rough. Occasional snow. Moderate or good,
occasionally very poor.

---

From: Ben Schwartz <[email-masked]>
Date: Sun, 18 Mar 2018 06:19:21 -0400

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

> 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).
>
> same fashion as any other transport failure... e.g. UDP timing out, or TCP
> 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
> 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

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
> [email-masked]
> https://www.ietf.org/mailman/listinfo/doh
>
>

---

From: Patrick McManus <[email-masked]>
Date: Sun, 18 Mar 2018 10:33:45 +0000

> draft but I couldn't see anything particularly addressing this issue.

we should have a look at section 4.6 of bcp56bis - which warns against
defining a laundry list of error codes in application protocols like DoH.
For each of these cases HTTP has an appropriate code, which can be consumed
by other HTTP clients in the HTTP ecosystem to mean the same thing. There
might be more than one way to express something at the HTTP layer and, as
long as the consumers follow the HTTP definitions, that's ok and doesn't
need specification by DoH.

> with a browser-friendly body.
that seems reasonable to me.

> Unsupported Media Type with a browser-friendly body.
that seems reasonable to me

> 400 makes the most sense to me.

> this is probably a tad too strong.

First, the absence of a request header indicates the client will take
anything - I'm not sure if that is included in your definition of allow the
mti (maybe it does?).

Second, 7231 5.3.2 covers this case :

   If the header field is present in a request and none of the
available representations for
   the response have a media type that is listed as acceptable, the
   origin server can either honor the header field by sending a 406 (Not
   Acceptable) response or disregard the header field by treating the
   response as if it is not subject to content negotiation.

so the server certainly has the option of just returning 200+wireformat.
Realistically given the size of wireformat that's probably the right thing
to do both paths seem legal.

> Regardless of the DNS RCODE in the response, the HTTP status code
Thanks!

---

From: Tony Finch <[email-masked]>
Date: Sun, 18 Mar 2018 11:03:55 +0000

> need specification by DoH.

Right, that makes sense. Regarding "more than one way to express
something", the DoH draft describes two fairly specific ways to express a
DoH request, so it seems to me that it would be right to be equally
specific about the error cases, as well as the success case. Maybe there
is some way to explain what to do without being as verbose as I was :-)

> to do both paths seem legal.

Being lazy, I'm happy that you say I don't need to implement any Accept:
processing :-)

Thanks for the helpful reply!

Tony.
-- 
f.anthony.n.finch  <[email-masked]>  http://dotat.at/  -  I xn--zr8h punycode
Forties, Cromarty, Forth: East 5 to 7, backing northeast 4 or 5 later.
Moderate or rough, occasionally very rough at first except in Cromarty. Snow
showers. Good, occasionally poor.

---

From: Ted Hardie <[email-masked]>
Date: Sun, 18 Mar 2018 04:24:19 -0700

For some reason, I am seeing Ben's reply, but not Patrick's mail.  Replying
to this as a result.

On Sun, Mar 18, 2018 at 3:19 AM, Ben Schwartz <[email-masked]> wrote:

>> Hi Ted, thanks for writing this down. I think I understand it a bit
>> better now.
>>
Saying something in the document like "only 2xx response codes will carry
response bodies with DNS UDP wireformat" would be a short and sweet way of
saying that in the document, if there is working group consensus that this
is true.  Based on my conversations yesterday, I am not sure that there is
complete consensus on this point, though there may very well be rough
consensus.

However, I don't think this formulation is quite enough:

> failed.

A pure transport failure may result in a retry.  There are some of these
responses which strongly indicate that such a retry will result in failures
(e.g. 403).  If you do not synthesize some message to the DNS client about
the type of failure,  and the server does not provide one, what part of the
system avoids the retry?

Ted

---

From: Daniel Stenberg <[email-masked]>
Date: Sun, 18 Mar 2018 12:43:53 +0100 (CET)

> complete consensus on this point, though there may very well be rough 

I'm firmly in the only-2xx-carry-response-bodies-to-care-about camp. I don't 
even understand how it would work otherwise.

What other HTTP response codes could be used to transmit DNS responses?

> the type of failure, and the server does not provide one, what part of the 

For all 4xx HTTP response codes, the "fault" is in the client side (the 
request) so if you as a client decide to retry the request it doesn't at least 
make any sense to send an identical request again.

I don't think 4xx strictly avoids retries. It informs the client about the 
fact that the request, as-is, was denied. A retry would then have to change 
something in the request for it to be successful. 401 and 407 are good 
examples of this, for which clients often retry with a modified request (with 
added auth headers).

-- 

  / daniel.haxx.se

---

From: Patrick McManus <[email-masked]>
Date: Sun, 18 Mar 2018 12:19:10 +0000

On Sun, Mar 18, 2018 at 11:03 AM, Tony Finch <[email-masked]> wrote:

> specific about the error cases, as well as the success case.
>

The subtlety here is that the response the DoH client consumes is not
necessarily generated by the DoH server - it might be some other HTTP
server in the chain. For instance, a cache/LB front end like Apache Traffic
Server might, instead of routing directly to the DoH server, send back a
redirect or a 401 or a 5xx if its just overloaded beyond hope. That's all
valid HTTP behavior in reaction to valid HTTP request by an entity that
isn't particularly DoH aware (that's the point of using HTTP!) - so you
aren't going to get it to constrain its responses in anyway more specific
than HTTP itself requires.

---

From: Ted Hardie <[email-masked]>
Date: Sun, 18 Mar 2018 06:57:07 -0700

Howdy,

On Sun, Mar 18, 2018 at 4:43 AM, Daniel Stenberg <[email-masked]> wrote:

> I'm firmly in the only-2xx-carry-response-bodies-to-care-about camp. I
> don't even understand how it would work otherwise.
>
The 4xx ones, might, as I noted below.

> request) so if you as a client decide to retry the request it doesn't at
> least make any sense to send an identical request again.
>
>
I think you're thinking of a different layering than I am.  If the DNS
client is talking to the HTTP stack as if it were a transport, and it gets
nothing back (transport failure), it may construct and send the query again
(it might do that in the UDP transport case, for example, on the theory
that the network had dropped the response packet).  To avoid that, you
might want to send a DNS message that encodes the information that this
server will not fulfill this request over this transport.

regards,

Ted

> examples of this, for which clients often retry with a modified request
> (with added auth headers).
>
> --
>
>  / daniel.haxx.se
>

---

From: Stephane Bortzmeyer <[email-masked]>
Date: Sun, 18 Mar 2018 16:43:07 +0000

On Sat, Mar 17, 2018 at 10:42:08AM -0700,
 Ted Hardie <[email-masked]> wrote 
 a message of 182 lines which said:

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

That's an interesting example. If a DoH server replies 451, does it
mean that access to this DoH service is blocked, for policy reasons,
or that access to this specific DNS data is blocked, for policy
reasons? In other words, can a HTTP response from a DoH server depend
on the QNAME? (Or on the tuple {QCLASS, QTYPE, QNAME}?)

May be a way to address this issue would be to say "HTTP status code
depends only on the HTTP request and server, never (MUST NOT) on the
DNS question"?

---

From: Stephane Bortzmeyer <[email-masked]>
Date: Sun, 18 Mar 2018 16:53:57 +0000

On Sun, Mar 18, 2018 at 10:11:41AM +0000,
 Tony Finch <[email-masked]> wrote 
 a message of 62 lines which said:

> response seems to be a browser-friendly 400 Bad Request.

> browser-friendly 406 Not Acceptable.

I agree with all this (and my hackathon-developed server does the
same) but, to follow Patrick McManus' idea of not restating everything
which is in HTTP, may be this could go in a non-normative appendix
such as "Implementation suggestions for non-HTTP experts"? With
lowercase "should" (specially for the last one: today, all the DoH
servers completely ignore Accept:)

---

From: Patrick McManus <[email-masked]>
Date: Sun, 18 Mar 2018 18:18:29 +0000

> on the QNAME? (Or on the tuple {QCLASS, QTYPE, QNAME}?)
Unfortunately I don't think HTTP is going to clarify for you why HTTP is
giving the 451 - all you know is that the response body is not the answer
to your DoH request. The 451 could be based on anything in the HTTP request
- which includes the query params and the message body as well as the path
and origin. So you don't know what was wrong with the request in
particular. So it could imo be as general as the hostname or as specific as
a qtype.

But I can say concretely that the message body of the 451 isn't going to
clear that up in anything other than a human readable way.

-P

---

From: Ted Hardie <[email-masked]>
Date: Mon, 19 Mar 2018 02:49:40 -0700

In-line

> clear that up in anything other than a human readable way.
The message body may not be able to answer this question completely, but it
can clarify at the DNS level that this was REFUSED.  The semantics of that
are much closer to 451's meaning than producing no DNS-level response at
all (which maps to "query did not complete" if I understand it correctly).

Ted

---

From: Paul Hoffman <[email-masked]>
Date: Mon, 19 Mar 2018 10:12:39 +0000

On Mar 19, 2018, at 9:49 AM, Ted Hardie <[email-masked]> wrote:
> The message body may not be able to answer this question completely, but it can clarify at the DNS level that this was REFUSED.  The semantics of that are much closer to 451's meaning than producing no DNS-level response at all (which maps to "query did not complete" if I understand it correctly).

Hopping up one level, I think you are describing a DOH server that inspects queries or responses and chooses to change the HTTP response to use a non-2xx code. That seems fine, but it also seems like you are saying that the DNS response inside that HTTP response should be understood by the client, and in a code-specific way. Is that a fair summary?

--Paul Hoffman

---

From: Mike Bishop <[email-masked]>
Date: Mon, 19 Mar 2018 10:42:42 +0000

There's a reasonable argument that if Content-Type is application/dns-udpwireformat, it should be processed by the DNS client regardless of the HTTP status code.  (And that a 200 with any other Content-Type is an error.)

-----Original Message-----
From: Doh <[email-masked]> On Behalf Of Paul Hoffman
Sent: Monday, March 19, 2018 10:13 AM
To: Ted Hardie <[email-masked]>
Cc: DoH WG <[email-masked]>
Subject: Re: [Doh] [Ext] A question on the mix of DNS and HTTP semantics

--Paul Hoffman

---

From: Ted Hardie <[email-masked]>
Date: Mon, 19 Mar 2018 04:03:53 -0700

On Mon, Mar 19, 2018 at 3:42 AM, Mike Bishop <[email-masked]> wrote:

> There's a reasonable argument that if Content-Type is
> application/dns-udpwireformat, it should be processed by the DNS client
> regardless of the HTTP status code.  (And that a 200 with any other
> Content-Type is an error.)
>
>
I think this makes sense.

Ted

> > The message body may not be able to answer this question completely, but
> it can clarify at the DNS level that this was REFUSED.  The semantics of
> that are much closer to 451's meaning than producing no DNS-level response
> at all (which maps to "query did not complete" if I understand it
> correctly).
>
> Hopping up one level, I think you are describing a DOH server that
> inspects queries or responses and chooses to change the HTTP response to
> use a non-2xx code. That seems fine, but it also seems like you are saying
> that the DNS response inside that HTTP response should be understood by the
> client, and in a code-specific way. Is that a fair summary?
>
> --Paul Hoffman

---

From: Patrick McManus <[email-masked]>
Date: Mon, 19 Mar 2018 11:15:02 +0000

there is a really fine line here. You can process a message body from a 4xx
anyway you want - its trying to communicate information to you and the
content-type is going to tell you how to go about trying to process it.
But, very clearly, that message body is not the answer to the DNS query
that was part of the HTTP request. If you can interpret it in some way that
makes your DNS gateway code richer, that's fine.. but its not a requirement
this protocol can, imo, put on a non success response beyond what is
already defined. I don't think the message body has any practical
epigrammatic interop value.

On Mon, Mar 19, 2018 at 11:03 AM, Ted Hardie <[email-masked]> wrote:

>> > The message body may not be able to answer this question completely,
>> but it can clarify at the DNS level that this was REFUSED.  The semantics
>> of that are much closer to 451's meaning than producing no DNS-level
>> response at all (which maps to "query did not complete" if I understand it
>> correctly).
>>

---

From: Dave Lawrence <[email-masked]>
Date: Mon, 19 Mar 2018 07:17:54 -0400

Ted Hardie writes:
> but it can clarify at the DNS level that this was REFUSED.  The
> semantics of that are much closer to 451's meaning

Well, yes and no.  REFUSED is hopelessly overloaded, with only one of
its meanings being semantically in the neighborhood or 451.  It is
also used to signal lame delegations, and even rejecting an EDNS
option.  Thus we have a draft for extended errors in DNS responses to
make things clearer.

---

From: Stephane Bortzmeyer <[email-masked]>
Date: Mon, 19 Mar 2018 15:09:58 +0000

On Mon, Mar 19, 2018 at 10:42:42AM +0000,
 Mike Bishop <[email-masked]> wrote 
 a message of 24 lines which said:

> application/dns-udpwireformat, it should be processed by the DNS
> client regardless of the HTTP status code.

It can be dangerous, no? If the status code is 500, it means there was
a serious problem in the server, the content may be, for instance,
truncated.

> (And that a 200 with any other Content-Type is an error.)

No, because we want to be future-proof (allow application/dns+json in
the future).

---

From: Andrew Sullivan <[email-masked]>
Date: Mon, 19 Mar 2018 11:21:27 -0400

> a serious problem in the server, the content may be, for instance,

If it were actually truncated, wouldn't the message have a TC bit set?
If the message contained is short of the full UDP message, wouldn't
the client-side processor be able to tell because the counts of actual
RRs wouldn't match the header section counters?

Best regards,

A
-- 
Andrew Sullivan
[email-masked]

---

From: Stephane Bortzmeyer <[email-masked]>
Date: Mon, 19 Mar 2018 15:39:58 +0000

On Mon, Mar 19, 2018 at 11:21:27AM -0400,
 Andrew Sullivan <[email-masked]> wrote 

> If it were actually truncated, wouldn't the message have a TC bit

Truncated for HTTP reasons (error 500 : the server crashed), not for
DNS reasons.

If the DNS answer is truncated for DNS reasons (EDNS buffer size too
small), I would expect the HTTP status code to be 200.

---

From: Patrick McManus <[email-masked]>
Date: Mon, 19 Mar 2018 16:03:04 +0000

I agree with Stephane. DNS information in non-successful HTTP responses
(i.e. not a 2xx) is not the answer to the question you asked in the HTTP
request. I can't tell you what it is - its normally just defined as human
readable explanation. It may certainly be generated by HTTP servers that do
not understand DoH.

---

From: Ted Hardie <[email-masked]>
Date: Mon, 19 Mar 2018 21:05:40 +0000

> readable explanation. It may certainly be generated by HTTP servers that do

I think the point of saying that udp wire format responses should be passed
to the dns sever, though, is that those will have been generated by a DNS
aware system.

Ted

---

From: Andrew Sullivan <[email-masked]>
Date: Mon, 19 Mar 2018 18:11:16 -0400

> Truncated for HTTP reasons (error 500 : the server crashed), not for

That's what I assumed, but my point is that the rule could still be
that the client could be required to process it, because the client
would fail.  The truncated message would have a section count that was
higher than the records actually contained there (because of the
truncated message), so the client would have a partial message and
would eventually do whatever it would do in that case (in ordinary
DNS, time out).  

I think erro 500 would probably return faster, however.

> small), I would expect the HTTP status code to be 200.

Also ok with me.  But since it's a wire message, you still need a TC
bit set, right?  (Hard for the as-yet-unwritten cases where there are
no such header bits, though, so 200 is probably better.)

A

-- 
Andrew Sullivan
[email-masked]

---

From: Petr Špaček <[email-masked]>
Date: Mon, 19 Mar 2018 23:38:18 +0100

On 19.3.2018 17:03, Patrick McManus wrote:
> request. I can't tell you what it is - its normally just defined as
> human readable explanation. It may certainly be generated by HTTP
> servers that do not understand DoH.

I agree, if there is a valid DNS message in the reply it should be HTTP
200 and anything else should be a HTTP-specific, e.g. Gateway Timeout
when DNS server/proxy timed out.

Attempting to mix HTTP and DNS semantics opens can of worms. If there is
a taste/need for something new and fancy, let's design new protocol for
stub-recursive communication with a proper REST interface from scratch.

I believe that attempts to HTTP-ify current DNS (beyond plain
encapsulation) are going to end up with epic fail... let's see.

Petr Špaček  @  CZ.NIC

> 
> 
> 
> 
> On Mon, Mar 19, 2018 at 3:39 PM, Stephane Bortzmeyer <[email-masked]
> <mailto:[email-masked]>> wrote:
> 
>      Andrew Sullivan <[email-masked]
>     <mailto:[email-masked]>> wrote

---

From: Paul Hoffman <[email-masked]>
Date: Tue, 20 Mar 2018 07:51:33 +0000

On Mar 19, 2018, at 10:11 PM, Andrew Sullivan <[email-masked]> wrote:
> bit set, right?  

Yes. The transport (in HTTPS, in TLS, in SomeFutureTransport) should not affect this.

--Paul Hoffman