Re: [dispatch] New proposed work: DNS over HTTPS

Mark Nottingham <> Sun, 18 June 2017 02:10 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id BD2E0124BE8 for <>; Sat, 17 Jun 2017 19:10:31 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.721
X-Spam-Status: No, score=-2.721 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key) header.b=es/2lCRY; dkim=pass (2048-bit key) header.b=B25+P9hc
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id OcZKjv3xZZU9 for <>; Sat, 17 Jun 2017 19:10:29 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 54D7A1201F2 for <>; Sat, 17 Jun 2017 19:10:29 -0700 (PDT)
Received: from compute3.internal (compute3.nyi.internal []) by mailnew.nyi.internal (Postfix) with ESMTP id BC80DAF5; Sat, 17 Jun 2017 22:10:28 -0400 (EDT)
Received: from frontend2 ([]) by compute3.internal (MEProxy); Sat, 17 Jun 2017 22:10:28 -0400
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; h=cc :content-transfer-encoding:content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-me-sender :x-me-sender:x-sasl-enc:x-sasl-enc; s=fm1; bh=c0lmjU+SRY4nn3E6iK Xoac/xU1BdZjE6uKPtPCqfZ9w=; b=es/2lCRY5k6dAc4stO1nD2T+mRLpL8AtK/ 3BbLV7mOZ2lF3BkxLerV0ql3LUq5cxxZaHJxlA8IibteO0+KBoyHUHe+UlYfREe5 FF78/s6NpYQ1YCB2oO/uZw3q2PQI7UpNF63wjHSpNwFhmRmAGD6vgqnS7E3YO7jQ 5JJDWH/JROH0Hu6AlgC0k5MRz2jd2n0g0vfH3+bXZ9hGeL9yHkI1n4uhR5HNNip5 cMfgBBVTMZeReER3RsoRgJNZp9iaG/s6mIHzgNckM40Kqq99kSksk0jPSswrUeP6 ojV2bbVIb1L6jVWyPXrBptA/OOdLMqNuNJIHIKXcoPzQEBidwaJg==
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=; h=cc:content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-me-sender:x-me-sender:x-sasl-enc:x-sasl-enc; s= fm1; bh=c0lmjU+SRY4nn3E6iKXoac/xU1BdZjE6uKPtPCqfZ9w=; b=B25+P9hc 6OZ0utZh781gP2HrHj15keMYyrwl/rTqmx5A+rveGDjZ6eu1L5yTHRRnWwvXNo2G mUc50TBZcQdOLTIEvKoOInbpOcsNFMlLxh9J28TA7aLdqTtYkpsfUyzmBwkxNMdw pL/+QBv8cynxAP1wDQkD9Ng28yUJFP+Px7vIUqjjVmCPhcrqumkOEnzdSUmo4fRs WKCIYxgW/xREGVos98ZstpwDQHHaWSvmS2tMhSrnAOy3R/drcm/7QYYzcOYKz/w1 JAUXeMhe1AGX5ouH8EaNCb8OkXgi/KZ87WtaElrPzucsnLGVSM9AzBpUrR62GNUP 5VQyUet/IwDzyw==
X-ME-Sender: <xms:FOFFWSNtUL0BFSVb21SCX4HSAOm-S2lW_Jh4uIlqdqaF8UBRD1Fhbg>
X-Sasl-enc: uEi+wD8YqeFczpeouuF3cnWxKXAQsh4pTznIsJIIIera 1497751827
Received: from [] ( []) by (Postfix) with ESMTPA id 1A66D24998; Sat, 17 Jun 2017 22:10:26 -0400 (EDT)
Content-Type: text/plain; charset=us-ascii
Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\))
From: Mark Nottingham <>
In-Reply-To: <>
Date: Sun, 18 Jun 2017 12:10:24 +1000
Cc: Paul Hoffman <>, "" <>
Content-Transfer-Encoding: quoted-printable
Message-Id: <>
References: <> <>
To: Richard Barnes <>
X-Mailer: Apple Mail (2.3273)
Archived-At: <>
Subject: Re: [dispatch] New proposed work: DNS over HTTPS
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: DISPATCH Working Group Mail List <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Sun, 18 Jun 2017 02:10:32 -0000

+1 to everything Richard says.

> On 17 Jun 2017, at 8:37 am, Richard Barnes <> wrote:
> Assuming we keep this bounded to the question of how to map DNS request/response pairs to HTTP request/response pairs, with a little bit of JSON syntax to make programming nice, this seems like a nicely bounded piece of work that would be well-suited to a small working group.
> Looking back at that the Bar BoF, however, I would be *very* wary of scope creep, so the charter should be written very tightly and enforced by the chairs and ADs.
> On Fri, Jun 16, 2017 at 4:34 PM, Paul Hoffman <> wrote:
> Greetings. We would like to propose that the work on DNS over HTTPS that is  currently embodied in the individual draft be dispatched at IETF 99.
> The work has been discussed for the last nine months on the IETF-sponsored mailing list at and was at the core of a bar bof in Seoul attended by around 80 people with a general consensus that standardization would benefit this space. I understand the draft should be resubmitted with the dispatch naming convention and will be very soon.
> This seems to us to be an Application protocol, but the httpbis WG generally does not take on how-to-use HTTP (that is, "foo over HTTP" work items), so dispatch's help in progressing the work would be appreciated. We emphasize that we seek work consistent with the goals of this previous work (and believe it to be a strong starting point), but the actual protocol specification is of course a matter of IETF consensus not pre-determined by that draft.
> As a bit of background, the Internet of course does not always provide good end-to-end reachability for DNS transport and this is especially true when using confidential and integrity transports for DNS. On-path network devices may spoof DNS responses, block DNS requests, track DNS activity, or just redirect DNS queries to different DNS servers that give less-than-honest answers.
> This work focuses on interacting with DNS servers, not just using encapsulation as a tunnel. Using secure HTTPS provides an alternative transport option and also provides a mechanism for obtaining and using DNS data in web browsers, both natively and in security contexts governed by the Same-Origin security policy.
> Another clear goal of the approach is to be a good fit for the HTTP protocol: good answers for caching, support for an ecosystem of different media types (such as both traditional DNS framing and more web-friendly things like JSON), and leverage of the multiplexing and prioritization schemes modern HTTP can provide.
> Use of HTTPS is very common, of course, and the ability to use an established connection to carry DNS information can provide both performance and confidentiality benefits over other approaches in circumstances when HTTPS is the prominent transport available. This proposal should not be considered exclusive or competitive with the valuable mechcanisms of the drive WG.
> Paul and Patrick
> _______________________________________________
> dispatch mailing list
> _______________________________________________
> dispatch mailing list

Mark Nottingham