Re: [Doh] [Ext] DOH bypassing protection mechanisms

Adam Roach <> Sun, 05 November 2017 19:49 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 70FDF13FCDA for <>; Sun, 5 Nov 2017 11:49:11 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.879
X-Spam-Status: No, score=-1.879 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_SPF_HELO_PERMERROR=0.01, T_SPF_PERMERROR=0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 28xggxanz-1B for <>; Sun, 5 Nov 2017 11:49:10 -0800 (PST)
Received: from ( [IPv6:2001:470:d:1130::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id A2CBC13FB72 for <>; Sun, 5 Nov 2017 11:49:10 -0800 (PST)
Received: from Svantevit.local ( []) (authenticated bits=0) by (8.15.2/8.15.2) with ESMTPSA id vA5JmhkE062588 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Sun, 5 Nov 2017 13:48:45 -0600 (CST) (envelope-from
X-Authentication-Warning: Host [] claimed to be Svantevit.local
To: Paul Hoffman <>, Eliot Lear <>
Cc: "" <>
References: <> <> <> <>
From: Adam Roach <>
Message-ID: <>
Date: Sun, 5 Nov 2017 13:48:38 -0600
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:52.0) Gecko/20100101 Thunderbird/52.4.0
MIME-Version: 1.0
In-Reply-To: <>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 7bit
Content-Language: en-US
Archived-At: <>
Subject: Re: [Doh] [Ext] DOH bypassing protection mechanisms
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: Sun, 05 Nov 2017 19:49:11 -0000

[as an individual]

On 11/5/17 1:31 PM, Paul Hoffman wrote:
> On Nov 5, 2017, at 8:29 AM, Eliot Lear <> wrote:
>> On 11/5/17 4:57 PM, Paul Hoffman wrote:
>>> As to Eliot's main question: The policy to choose a DOH server is similar to the policy to choose a DNS resolver, it's just done in a different application. For the latter, the typical is "trust whatever DHCP tells you", but there are also commonly policies of "ignore DHCP, always use one of these". Both those policies could be mirrored in a browser for DOH.
>> That's the theory.  In reality, for the enterprise, you would be hard
>> pressed to find examples in which the enterprise itself doesn't control
>> where a query goes on a client (DHCP is not the only control function).
> It sounds like the operational document might say something like "an enterprise that cares about which DNS resolver its users access needs to also make that policy in DOH-enabled web clients".

s/web clients/DNS clients/, right? I don't get the impression that the 
use cases are intended to be restricted to web browsers as clients.