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

Paul Hoffman <> Sun, 05 November 2017 15:57 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 7DA0613FBB2 for <>; Sun, 5 Nov 2017 07:57:51 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -4.201
X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id GvNF-D52DUZZ for <>; Sun, 5 Nov 2017 07:57:50 -0800 (PST)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id EF03713FBB1 for <>; Sun, 5 Nov 2017 07:57:49 -0800 (PST)
Received: from ( by ( with Microsoft SMTP Server (TLS) id 15.0.1178.4; Sun, 5 Nov 2017 07:57:47 -0800
Received: from ([]) by PMBX112-W1-CA-1.PEXCH112.ICANN.ORG ([]) with mapi id 15.00.1178.000; Sun, 5 Nov 2017 07:57:47 -0800
From: Paul Hoffman <>
To: "" <>
Thread-Topic: [Ext] [Doh] DOH bypassing protection mechanisms
Thread-Index: AQHTVk2G6fE5avEYsUuvAF4TGD9ExaMGdyUA
Date: Sun, 5 Nov 2017 15:57:46 +0000
Message-ID: <>
References: <>
In-Reply-To: <>
Accept-Language: en-US
Content-Language: en-US
x-ms-exchange-messagesentrepresentingtype: 1
x-ms-exchange-transport-fromentityheader: Hosted
x-originating-ip: []
Content-Type: text/plain; charset="us-ascii"
Content-ID: <>
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
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 15:57:51 -0000

> On 5 Nov 2017, at 0:30, Eliot Lear wrote:
>>   * Use of DoH will bypass protection mechanisms commonly used to
>>     efficiently detect and prevent access to known malware-infested
>>     sites.  There are two mitigation mechanisms available, but one is
>>     incomplete:  deployments make use of in-path blocking methods such
>>     as IP access lists.  This is partial because there is a
>>     performance/memory impact in doing so, and the query itself can
>>     indicate that the device itself is infected.  The other mitigation
>>     here is to have a configuration mechanism to turn on/off DoH in
>>     order to use the existing infrastructure.  This has the least impact
>>     on surrounding infrastructure (and takes the least text ;-).

On 5 Nov 2017, at 7:48, tjw ietf wrote:

> in the case of detect and prevent access to known malware-infested
> sites, could;n't DoH deploy an RPZ like mechanism?

Yes. A DOH server is just like any DNS recursive resolver that a user might choose (such as from DHCP). It could use RPZ, it could offer anti-malware, it could be be malicious itself, ...

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.

--Paul Hoffman