Re: [Doh] operational issues with doh

Eliot Lear <> Sun, 05 November 2017 07:30 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 664C213FB59 for <>; Sun, 5 Nov 2017 00:30:14 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -14.499
X-Spam-Status: No, score=-14.499 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, URIBL_BLOCKED=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 2Q_q2_7DmIar for <>; Sun, 5 Nov 2017 00:30:12 -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 B6D2313FA6E for <>; Sun, 5 Nov 2017 00:30:11 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple;;; l=10387; q=dns/txt; s=iport; t=1509867011; x=1511076611; h=subject:to:cc:references:from:message-id:date: mime-version:in-reply-to; bh=GJf+ffnrvnAJ0R1TwB7+D1LVqFEci/AghS+NQtQMzCc=; b=W/cZMoRI+5b6W1hJ2T2k08vMKxVOBlpv7I4gAPkhoQVM12hTwjtI2yGX QxKBpPpSpGUgmj4mSDxChWgWCOBkRhU0ajzl3BrVyWvJYX83DSAu2qYh5 ilS+ManXj/pTFt3qmK9GeIOUgZrtDCp1m/YPOPWaZCn6eMg6MbzwbdZWp k=;
X-Files: signature.asc : 481
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0DvAADVvP5Z/xbLJq1cGQEBAQEBAQEBA?= =?us-ascii?q?QEBBwEBAQEBhBhuJ4N9ih90j3IJJohRiC+FRhCCAQcDGAEKhRgChRYYAQEBAQE?= =?us-ascii?q?BAQEBayhCEIRNAQEBAwEBIUIJCxALGCoCAiEGMAYBDAYCAQGKBwMVEKkUgicmh?= =?us-ascii?q?woNg0YBAQEBAQEBAQEBAQEBAQEBAQEBAQEOCgWDLoVsC4J2gmqBdAESAQmDK4J?= =?us-ascii?q?iBaFSPIRCgiOEaIQ2hHmLeIc8jRqIfIE5HziBA2k0IQgdFUmCZIRgQDaEAoU6g?= =?us-ascii?q?jUBAQE?=
X-IronPort-AV: E=Sophos;i="5.44,346,1505779200"; d="asc'?scan'208,217";a="30573"
Received: from (HELO ([]) by with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 05 Nov 2017 07:30:09 +0000
Received: from [] ([]) by (8.14.5/8.14.5) with ESMTP id vA57U9xG023563; Sun, 5 Nov 2017 07:30:09 GMT
To: Martin Thomson <>, tjw ietf <>
Cc: Patrick McManus <>,
References: <> <> <> <>
From: Eliot Lear <>
Message-ID: <>
Date: Sun, 5 Nov 2017 08:30:08 +0100
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.13; rv:52.0) Gecko/20100101 Thunderbird/52.4.0
MIME-Version: 1.0
In-Reply-To: <>
Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="RQUqWbJcAuBtwcHo3oi8NojhSwh1fMPGc"
Archived-At: <>
Subject: Re: [Doh] operational issues with 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: Sun, 05 Nov 2017 07:30:14 -0000

There are several:

  * Use of this mechanism can cause problems with split DNS, where the
    internal DNS is not the same as what is made available externally. 
    Many corporate networkers hide their internal topology from the
    external DNS.  If an end host queries an external DNS for an
    internal resource, the result would be NXDOMAIN.  To avoid this, at
    a minimum, the browser should have some configuration as to what is
    internal.  I conjecture that this would reflect what is commonly
    found in a proxy.pac file.
  * When an HTTP server offers this service for domains it is not
    responsible for, it has the potential to impact DNS-based load
    balancing by masking the IP address of the sender and substituting
    its own.  The remedy here is that any service offering DoH should
    sufficiently distributed as to minimize such an impact.
  * 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 11/3/17 11:33 PM, Martin Thomson wrote:
> Maybe someone can send an email outlining the operational concerns to
> the list and we can discuss them first.  I don't know what these
> concerns are.
> On Sat, Nov 4, 2017 at 7:16 AM, tjw ietf <> wrote:
>> Agree with Patrick, this should be more of an operational considerations
>> document.
>> On Tue, Oct 31, 2017 at 3:47 PM, Patrick McManus <>
>> wrote:
>>> I think I would prefer a separate document if people were interested in
>>> working on that.
>>> On Tue, Oct 31, 2017 at 2:57 PM, Eliot Lear <> wrote:
>>>> Hi everyone,
>>>> Just to follow up on the lengthy discussion that took place during
>>>> chartering, there are some operational issues that use of doh can
>>>> create, particularly with regard to load balancers and split DNS.  Do
>>>> those go into the draft or do they go into a separate doc?  It's quite
>>>> possible they can be mitigated against, and if they can be, and if the
>>>> text isn't too long, can I suggest that we start out by having some text
>>>> in the draft, and if it starts to get lengthy we split it off?
>>>> Eliot
>>>> _______________________________________________
>>>> Doh mailing list
>>> _______________________________________________
>>> Doh mailing list
>> _______________________________________________
>> Doh mailing list