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

Tom Pusateri <pusateri@bangj.com> Sun, 19 August 2018 18:35 UTC

Return-Path: <pusateri@bangj.com>
X-Original-To: dnsop@ietfa.amsl.com
Delivered-To: dnsop@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7A8B2130E90 for <dnsop@ietfa.amsl.com>; Sun, 19 Aug 2018 11:35:21 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.899
X-Spam-Level:
X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hVNlzfAPrgHb for <dnsop@ietfa.amsl.com>; Sun, 19 Aug 2018 11:35:19 -0700 (PDT)
Received: from oj.bangj.com (amt0.gin.ntt.net [129.250.11.170]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E1E5D130E8E for <dnsop@ietf.org>; Sun, 19 Aug 2018 11:35:18 -0700 (PDT)
Received: from [172.16.10.126] (unknown [107.13.224.116]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by oj.bangj.com (Postfix) with ESMTPSA id EE28F29E0; Sun, 19 Aug 2018 14:31:22 -0400 (EDT)
From: Tom Pusateri <pusateri@bangj.com>
Message-Id: <90828859-A7C0-462C-8772-58FB143A871A@bangj.com>
Content-Type: multipart/alternative; boundary="Apple-Mail=_8DC8F0E8-B0C4-473E-A633-C0A34C55C14F"
Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\))
Date: Sun, 19 Aug 2018 14:35:16 -0400
In-Reply-To: <5374C85A-D26B-4B20-817D-5363F9807C2B@cable.comcast.com>
Cc: bert hubert <bert.hubert@powerdns.com>, Ted Lemon <mellon@fugue.com>, dnsop <dnsop@ietf.org>, =?utf-8?Q?Marek_Vavru=C5=A1a?= <mvavrusa=40cloudflare.com@dmarc.ietf.org>
To: "Livingood, Jason" <Jason_Livingood@comcast.com>
References: <CAC=TB13mUH2SDxFb4c3rOz0-Z6PE_r9i84_xK=dmLxiVr45+tA@mail.gmail.com> <CAPt1N1=-792WkQmbTigPdqOh0dONykYycG0hheOecoQa4ai=Hw@mail.gmail.com> <20180818230319.GA32131@server.ds9a.nl> <5374C85A-D26B-4B20-817D-5363F9807C2B@cable.comcast.com>
X-Mailer: Apple Mail (2.3445.9.1)
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/HbzxrG9yz0-oCGMclFFH4g7q1Y4>
Subject: Re: [DNSOP] Draft for dynamic discovery of secure resolvers
X-BeenThere: dnsop@ietf.org
X-Mailman-Version: 2.1.27
Precedence: list
List-Id: IETF DNSOP WG mailing list <dnsop.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dnsop>, <mailto:dnsop-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/dnsop/>
List-Post: <mailto:dnsop@ietf.org>
List-Help: <mailto:dnsop-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dnsop>, <mailto:dnsop-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sun, 19 Aug 2018 18:35:21 -0000


> On Aug 19, 2018, at 9:29 AM, Livingood, Jason <Jason_Livingood@comcast.com> wrote:
> 
> On 8/18/18, 7:03 PM, "DNSOP on behalf of bert hubert" <dnsop-bounces@ietf.org on behalf of bert.hubert@powerdns.com> 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. 
> 
> JL

In the DRIU BOF, I mentioned establishing a reputation service for public DNS resolvers. With a JSON interface, this could lead to users conveying some trust of a public service or more likely, the inverse of trust for operating systems or stub resolvers to whitelist/blacklist public DNS resolvers.

I tried to summarize it here:

https://dnsdisco.com/reputation-post.html <https://dnsdisco.com/reputation-post.html>

Or you could go listen to the proceedings of the DRIU BOF.

Thanks,
Tom