Re: [DNSOP] Draft for dynamic discovery of secure resolvers

"Livingood, Jason" <> Sun, 19 August 2018 13:29 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id A0F83131048 for <>; Sun, 19 Aug 2018 06:29:53 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id qvdUz7H6VjtK for <>; Sun, 19 Aug 2018 06:29:51 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id C54DF127B92 for <>; Sun, 19 Aug 2018 06:29:51 -0700 (PDT)
X-AuditID: 60729ed4-ef86a70000006f94-0e-5b7970d279fa
Received: from ( []) (using TLS with cipher AES256-SHA256 (256/256 bits)) (Client did not present a certificate) by (SMTP Gateway) with SMTP id 45.6C.28564.2D0797B5; Sun, 19 Aug 2018 07:29:54 -0600 (MDT)
Received: from ( by ( with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1466.3; Sun, 19 Aug 2018 09:29:16 -0400
Received: from ([fe80::3aea:a7ff:fe36:8a94]) by ([fe80::3aea:a7ff:fe36:8a94%15]) with mapi id 15.01.1466.003; Sun, 19 Aug 2018 09:29:16 -0400
From: "Livingood, Jason" <>
To: bert hubert <>, Ted Lemon <>
CC: dnsop <>, Marek Vavruša <>
Thread-Topic: [DNSOP] Draft for dynamic discovery of secure resolvers
Thread-Index: AQHUNzjkIKTAOZaajEyS8xlT9z1SoqTGR9uAgAAcEICAAK7igA==
Date: Sun, 19 Aug 2018 13:29:16 +0000
Message-ID: <>
References: <> <> <>
In-Reply-To: <>
Accept-Language: en-US
Content-Language: en-US
user-agent: Microsoft-MacOutlook/
x-originating-ip: []
Content-Type: text/plain; charset="utf-8"
Content-ID: <>
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-CFilter-Loop: Forward
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFtrNKsWRmVeSWpSXmKPExsWSUDRnsu7lgspog+OSFjfO9bBZ3H1zmcXi zZojTBZrLs1ldGDxOLHsCqtH04Vl7B5Llvxk8vjVN4k9gCWqgdGmJKMoNbHEJTUtNa841Y5L AQPYJKWm5ReluiYW5VQGpeakJmJXBlKZkpqTWZZapI/VGH2s5iR0MWXM6fnIVNDCU7H30w72 BsY73F2MnBwSAiYSC44cZO1i5OIQEtjFJLFp30VmCKeFSeLp2ZNsEM5pRolXuz4xgbSwCZhJ 3F14hRnEFhHwkNi4bCVYnFkgU+Ls40Z2EFtYwEXiwYs/UDWuEqe/3ICynSR+b13F2MXIwcEi oCpxd68aSJgXqPzcnu1Quw4ySmxf/ZURJMEJdN6TRQvAZjIKiEl8P7UGape4xK0n85kgXhCQ WLLnPDOELSrx8vE/VpD5ogL6EtMuB0CEFSR6JkxnBgkzC2hKrN+lDzHFSmJOx1VGCFtRYkr3 Q3aIcwQlTs58wgLRKi5x+MgO1gmMkrOQLJ6FMGkWkkmzkEyahWTSAkbWVYx8lmZ6hoYmeoam FnpGhkabGMFJat6VHYyXp3scYhTgYFTi4VXKq4wWYk0sK67MPcQowcGsJMLb6gwU4k1JrKxK LcqPLyrNSS0+xCjNwaIkzvt4Ymm0kEB6YklqdmpqQWoRTJaJg1OqgTGysm5hXkLHb/e5oSev r9wY//71ey1mK4uC6w/sGhbwLTBbWrWtaXrIeU6+8+dLbn5dk8q/MP9q9NOeDy1RH5h33DCp tBfrMqn/xnMhZerWyXePVq8ysbo9643jmsSGe/HVnrdvzpX1dtu9fsZ7s/cxUaoiN8S+i7rr rKyxZd257kxBKr9KnoASS3FGoqEWc1FxIgDy8YB0TgMAAA==
Archived-At: <>
Subject: Re: [DNSOP] Draft for dynamic discovery of secure resolvers
X-Mailman-Version: 2.1.27
Precedence: list
List-Id: IETF DNSOP WG mailing list <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Sun, 19 Aug 2018 13:29:54 -0000

On 8/18/18, 7:03 PM, "DNSOP on behalf of bert hubert" < on behalf of> wrote:
    Especially when such a move will incidentally kill intranets, VPNs, split
    horizon, DNS monitoring & DNS malware detecion and blocking. 

It seems to me that the underlying protocol is separable from the operational implementation, and the latter case is likely where most of the concerns lie. Thus, the issue is likely less DoH itself but rather how it is likely to be deployed.

I am considering starting work on a draft along the lines of 'potential impacts of DoH deployment' to try to document some of this, if for nothing else than to organize my own thinking on the matter. This is because I also share concern, given the apparent deployment model, around what may break in enterprise networks, malware detection & remediation, walled garden portals during service provisioning, parental controls, and the impacts of eliminating other local policies. The CDN-to-CDN competition case is an interesting one as well, with respect to passing EDNS client subnet or not.