IETF Logo Mail Archive

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

Tony Finch <dot@dotat.at> Sun, 18 March 2018 10:11 UTC

Return-Path: <dot@dotat.at>
X-Original-To: doh@ietfa.amsl.com
Delivered-To: doh@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9BA791200A0 for <doh@ietfa.amsl.com>; Sun, 18 Mar 2018 03:11:59 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.2
X-Spam-Level:
X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8i2h9tE92HLW for <doh@ietfa.amsl.com>; Sun, 18 Mar 2018 03:11:57 -0700 (PDT)
Received: from ppsw-30.csi.cam.ac.uk (ppsw-30.csi.cam.ac.uk [131.111.8.130]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C26201275F4 for <doh@ietf.org>; Sun, 18 Mar 2018 03:11:43 -0700 (PDT)
X-Cam-AntiVirus: no malware found
X-Cam-ScannerInfo: http://help.uis.cam.ac.uk/email-scanner-virus
Received: from grey.csi.cam.ac.uk ([131.111.57.57]:38244) by ppsw-30.csi.cam.ac.uk (ppsw.cam.ac.uk [131.111.8.136]:25) with esmtps (TLSv1:ECDHE-RSA-AES256-SHA:256) id 1exVHy-000exR-eF (Exim 4.89_2) (return-path <dot@dotat.at>); Sun, 18 Mar 2018 10:11:42 +0000
Date: Sun, 18 Mar 2018 10:11:41 +0000
From: Tony Finch <dot@dotat.at>
To: Ted Hardie <ted.ietf@gmail.com>
cc: doh@ietf.org
In-Reply-To: <CA+9kkMB7awRfW9jUmY9Q-1p+w3VLtpG5DxhF3s7Q58nEMZeX3w@mail.gmail.com>
Message-ID: <alpine.DEB.2.11.1803181007050.16965@grey.csi.cam.ac.uk>
References: <CA+9kkMB7awRfW9jUmY9Q-1p+w3VLtpG5DxhF3s7Q58nEMZeX3w@mail.gmail.com>
User-Agent: Alpine 2.11 (DEB 23 2013-08-11)
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset="US-ASCII"
Archived-At: <https://mailarchive.ietf.org/arch/msg/doh/XAvUlLxrBfoAm_bvwJXeKtAs4sk>
Subject: Re: [Doh] A question on the mix of DNS and HTTP semantics
X-BeenThere: doh@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: DNS Over HTTPS <doh.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/doh>, <mailto:doh-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/doh/>
List-Post: <mailto:doh@ietf.org>
List-Help: <mailto:doh-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/doh>, <mailto:doh-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sun, 18 Mar 2018 10:11:59 -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  <dot@dotat.at>  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.

v2.23.0 | Report a Bug | By Email