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

Ted Hardie <ted.ietf@gmail.com> Sat, 17 March 2018 17:42 UTC

Return-Path: <ted.ietf@gmail.com>
X-Original-To: doh@ietfa.amsl.com
Delivered-To: doh@ietfa.amsl.com
Received: from localhost (localhost []) by ietfa.amsl.com (Postfix) with ESMTP id D35E212711E for <doh@ietfa.amsl.com>; Sat, 17 Mar 2018 10:42:41 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.699
X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
Received: from mail.ietf.org ([]) by localhost (ietfa.amsl.com []) (amavisd-new, port 10024) with ESMTP id CjgWZ8tCU7te for <doh@ietfa.amsl.com>; Sat, 17 Mar 2018 10:42:39 -0700 (PDT)
Received: from mail-oi0-x236.google.com (mail-oi0-x236.google.com [IPv6:2607:f8b0:4003:c06::236]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 99F8712025C for <doh@ietf.org>; Sat, 17 Mar 2018 10:42:39 -0700 (PDT)
Received: by mail-oi0-x236.google.com with SMTP id p66so1196986oia.12 for <doh@ietf.org>; Sat, 17 Mar 2018 10:42:39 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:from:date:message-id:subject:to; bh=8SpCnJRqquV0fqVphvl3QCP+ePbn4nyS2t9GWS2kMXA=; b=pqe5axlmgWqHVOIDQVFs0w0P5UxpBXDysMa+b1sJ2lHyThWGgi3v1Ed4RkHh90vrnq D8TJ5dISkBzh4sChgd2Hx5bwgjXsWVWZlj4/sRyrObWppjkJXvPOn1CdM//mOpzAxWrO qVjgNsNBZo9Wb64ALHzCVrsJJSqBK1wGYbVQ16q9MA4Gf7BHqcp9yI+f0orH/hMSRjdO hunSEaOHcIjduuIjggJQrX5g14Da3Y/ak/YyrEQtEjJw+JocbqUdmUCAO8zN+PrdVWsv FyV0YtDAdPN88t3DzfJl/iFeE/B0UCHv8oJuTLQhtvGXTvWFYXQPsSQfUukWF7hUg0UY vKMA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=8SpCnJRqquV0fqVphvl3QCP+ePbn4nyS2t9GWS2kMXA=; b=tBuMBIgKDc7JO8Gu2ssm/DKYk2nm0WU3d61agkaDVjpvR1ATxUmGydpx5Guxq+gBbk DJgKpg4lKBUSTLjgL5JlbEi8zCPRD02hwMhtaDKT1v8yz8fd6Urc5fi81Pax5o3XQQn6 Zy0fJ/dGiiGW8nOpe9Yd2G+MgMI9eP/KtbayBNfILhiP0d8M2J6N+fdDeqVPr/k4l86t tnEUOZD1T8kLvkdjj2xY9sZ7LnV5B6jNa1KM1XBp81Jjk1hzKjFj5jnzK0EE+rkIuLZX RM7vthJcEUGoTpmA6oAQsehUU2Jtx3uEGkAMpgDsQRW+nwgY7EErSAyDQ2Jyhr32eaVm AJSg==
X-Gm-Message-State: AElRT7EbmHTxQ6QRt3rYck7we3PRFR8uzHl4kscL2k8jpFJXqbl/ARbJ 19DcooGvJlWQDT83SmpjXjNoX0QYv9h2BAvSESjcIA==
X-Google-Smtp-Source: AG47ELvT6liAyoQQ9TXdlGrW0pAePX+Xpi7VlvCfAekLd6vqBP1XapdWFWE5JZsqGOLqsZZHZSwQqDEo/OzTh+gA41Y=
X-Received: by with SMTP id m126mr3856315oia.45.1521308558433; Sat, 17 Mar 2018 10:42:38 -0700 (PDT)
MIME-Version: 1.0
Received: by with HTTP; Sat, 17 Mar 2018 10:42:08 -0700 (PDT)
From: Ted Hardie <ted.ietf@gmail.com>
Date: Sat, 17 Mar 2018 10:42:08 -0700
Message-ID: <CA+9kkMB7awRfW9jUmY9Q-1p+w3VLtpG5DxhF3s7Q58nEMZeX3w@mail.gmail.com>
To: doh@ietf.org
Content-Type: multipart/alternative; boundary="001a113d660a38237205679f4015"
Archived-At: <https://mailarchive.ietf.org/arch/msg/doh/KUeXHOXARoCysALE9hwI1B7yYas>
Subject: [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: Sat, 17 Mar 2018 17:42:42 -0000


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

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.