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

Patrick McManus <> Sun, 18 March 2018 10:33 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id CDAAD1275F4 for <>; Sun, 18 Mar 2018 03:33:49 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.234
X-Spam-Status: No, score=-1.234 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, SPF_SOFTFAIL=0.665] autolearn=no autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id qdBs9Y3OTrQR for <>; Sun, 18 Mar 2018 03:33:47 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id A2270127599 for <>; Sun, 18 Mar 2018 03:33:47 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTPSA id 506AC3A021 for <>; Sun, 18 Mar 2018 06:33:46 -0400 (EDT)
Received: by with SMTP id 71so651601oie.12 for <>; Sun, 18 Mar 2018 03:33:46 -0700 (PDT)
X-Gm-Message-State: AElRT7Ea1lvfnIXua0qXpMXsa1gUCLkWLU9+2Qa4zYY7vMg6i4+a2yuE ZWFZs66fywOWM2ss7i5GZMEm41tTMomen7D54/o=
X-Google-Smtp-Source: AG47ELsu/08JEmSIBBTrQZIBdNrbKhhPvi8flGTZuveCAzQgyKp1CzNKJKcy6ndkRnOfcMomXHSSotU+60RzIy0y5mg=
X-Received: by with SMTP id s126mr4561690oib.155.1521369225983; Sun, 18 Mar 2018 03:33:45 -0700 (PDT)
MIME-Version: 1.0
Received: by with HTTP; Sun, 18 Mar 2018 03:33:45 -0700 (PDT)
In-Reply-To: <>
References: <> <>
From: Patrick McManus <>
Date: Sun, 18 Mar 2018 10:33:45 +0000
X-Gmail-Original-Message-ID: <>
Message-ID: <>
To: Tony Finch <>
Cc: Ted Hardie <>,
Content-Type: multipart/alternative; boundary="001a113d51604980050567ad60ec"
Archived-At: <>
Subject: Re: [Doh] A question on the mix of DNS and HTTP semantics
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: DNS Over HTTPS <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Sun, 18 Mar 2018 10:33:50 -0000

On Sun, Mar 18, 2018 at 10:11 AM, Tony Finch <> wrote:

> server should generate. I have had another quick look through the
> 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.

> If the request is not HEAD/GET/POST, I return 405 Method Not Allowed
> with a browser-friendly body.
that seems reasonable to me.

> 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.
that seems reasonable to me

> 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.
> 400 makes the most sense to me.

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

> 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  <>  -  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.
> _______________________________________________
> Doh mailing list