Re: [Doh] WG Review: DNS Over HTTPS (doh)

Eliot Lear <> Fri, 15 September 2017 17:24 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 9F330133050; Fri, 15 Sep 2017 10:24:45 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -14.501
X-Spam-Status: No, score=-14.501 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_HI=-5, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (1024-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id qEl8IxAnscL6; Fri, 15 Sep 2017 10:24:44 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 9588F13309D; Fri, 15 Sep 2017 10:24:43 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple;;; l=4082; q=dns/txt; s=iport; t=1505496283; x=1506705883; h=subject:to:cc:references:from:message-id:date: mime-version:in-reply-to; bh=jLXmHlk8uGFwzaoOS6dlNVHJcjBiRzUF1Ji5Z7dTi+Y=; b=DHEQ/X/yxbUrV2ADOeHNWBf/6JABdJ6AlYmNhvsJkJHWdDdP7Zuvkf22 VpDRnUjlMD45oKuBk/jcQ8J8GPs5hYXmaOGbC8H5yTT9w/cm/Qz5LfMOc ZNsUI9q4D3rKWyRi6usNKD3f6abpcxAiTarEfojP1bF+0ZirPX7FU0KE3 E=;
X-Files: signature.asc : 481
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-AV: E=Sophos;i="5.42,398,1500940800"; d="asc'?scan'208";a="697215963"
Received: from (HELO ([]) by with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 15 Sep 2017 17:24:27 +0000
Received: from [] ([]) by (8.14.5/8.14.5) with ESMTP id v8FHOQE9001663; Fri, 15 Sep 2017 17:24:26 GMT
References: <>
From: Eliot Lear <>
Message-ID: <>
Date: Fri, 15 Sep 2017 19:24:34 +0200
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.12; rv:52.0) Gecko/20100101 Thunderbird/52.3.0
MIME-Version: 1.0
In-Reply-To: <>
Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="cV2fCVtPUQS9CCHmuk7WX4PuBdPcfSa6B"
Archived-At: <>
X-Mailman-Approved-At: Fri, 15 Sep 2017 11:46:42 -0700
Subject: Re: [Doh] WG Review: DNS Over HTTPS (doh)
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: Fri, 15 Sep 2017 17:24:46 -0000


I have no objection to a WG forming, but I have some concerns about the

On 9/15/17 5:44 PM, The IESG wrote:
> This working group will standardize encodings for DNS queries and responses
> that are suitable for use in HTTPS. This will enable the domain name system
> to function over certain paths where existing DNS methods (UDP, TLS, and DTLS)
> experience problems.

There is a fundamental question that is left open in the charter: is the
HTTPS server intended to be a substitute for a resolver, or is intended
to provide name service for domains related to the authority section of
the URL used to connect to the current service?  There is some hint
along the lines of the latter in the draft, and I see nothing wrong with
that use, and could see quite a bit of benefit, because the browser
would be following the express intent of the origin.

On the other hand, if this is intended to be used as a full scale
replacement of a resolver, the placement of that resolver and more
precisely locality would become a big operational issue for all sorts of
reasons, such as anti-malware protection, split dns behavior, split
personalities across applications that might impact non-participating
web services, and more.  And yet..
> The working group will coordinate with the DNSOP and INTAREA working groups
> for input on DNS-over-HTTPS's impact on DNS operations and DNS semantics,
> respectvely. In particular, DNSOP will be consulted for guidance on the
[nit - s/respectvely/respectively/]
> operational impacts that result from traditional host behaviors (i.e.,
> stub-resolver to recursive-resolver interaction) being replaced with the
> specified mechanism.
> Specification of how the DNS data may be used for new use cases, and
> the discovery of the DOH servers, are out of scope for the working group.

The last sentence seems to put the cart before the horse.  How about
letting the working group decide in consultation with dnsop and intarea
whether or not to handle discovery?  The fact is, you are not leaving
discovery out of scope.  You are making a decision that discovery will
take place either in a proprietary way, on an ad hoc basis, or via
manual configuration, but you are ruling out a standard discovery mechanism.


> The working group will use draft-hoffman-dispatch-dns-over-https as input.
> Milestones:
>   Apr 2018 - Submit specification for performing DNS queries over HTTPS to
>   the IESG for publication as PS