[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 [127.0.0.1]) 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-Level:
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 ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (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 10.202.63.132 with SMTP id m126mr3856315oia.45.1521308558433; Sat, 17 Mar 2018 10:42:38 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.74.7.27 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
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
- [Doh] A question on the mix of DNS and HTTP seman… Ted Hardie
- Re: [Doh] A question on the mix of DNS and HTTP s… Patrick McManus
- Re: [Doh] A question on the mix of DNS and HTTP s… Patrick McManus
- Re: [Doh] A question on the mix of DNS and HTTP s… Tony Finch
- Re: [Doh] A question on the mix of DNS and HTTP s… Ben Schwartz
- Re: [Doh] A question on the mix of DNS and HTTP s… Tony Finch
- Re: [Doh] A question on the mix of DNS and HTTP s… Ted Hardie
- Re: [Doh] A question on the mix of DNS and HTTP s… Daniel Stenberg
- Re: [Doh] A question on the mix of DNS and HTTP s… Patrick McManus
- Re: [Doh] A question on the mix of DNS and HTTP s… Ted Hardie
- Re: [Doh] A question on the mix of DNS and HTTP s… Stephane Bortzmeyer
- Re: [Doh] A question on the mix of DNS and HTTP s… Stephane Bortzmeyer
- Re: [Doh] A question on the mix of DNS and HTTP s… Patrick McManus
- Re: [Doh] A question on the mix of DNS and HTTP s… Ted Hardie
- Re: [Doh] [Ext] A question on the mix of DNS and … Paul Hoffman
- Re: [Doh] [Ext] A question on the mix of DNS and … Mike Bishop
- Re: [Doh] [Ext] A question on the mix of DNS and … Ted Hardie
- Re: [Doh] [Ext] A question on the mix of DNS and … Patrick McManus
- Re: [Doh] A question on the mix of DNS and HTTP s… Dave Lawrence
- Re: [Doh] [Ext] A question on the mix of DNS and … Stephane Bortzmeyer
- Re: [Doh] [Ext] A question on the mix of DNS and … Andrew Sullivan
- Re: [Doh] [Ext] A question on the mix of DNS and … Stephane Bortzmeyer
- Re: [Doh] [Ext] A question on the mix of DNS and … Patrick McManus
- Re: [Doh] [Ext] A question on the mix of DNS and … Ted Hardie
- Re: [Doh] [Ext] A question on the mix of DNS and … Andrew Sullivan
- Re: [Doh] [Ext] A question on the mix of DNS and … Petr Špaček
- Re: [Doh] [Ext] A question on the mix of DNS and … Paul Hoffman