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

Paul Vixie <paul@redbarn.org> Tue, 21 August 2018 18:54 UTC

Return-Path: <paul@redbarn.org>
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 C66D1130E9C for <dnsop@ietfa.amsl.com>; Tue, 21 Aug 2018 11:54:27 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.901
X-Spam-Level:
X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham 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 dL6bvY3s_5MM for <dnsop@ietfa.amsl.com>; Tue, 21 Aug 2018 11:54:26 -0700 (PDT)
Received: from family.redbarn.org (family.redbarn.org [24.104.150.213]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F07ED130E85 for <dnsop@ietf.org>; Tue, 21 Aug 2018 11:54:25 -0700 (PDT)
Received: from [IPv6:2001:559:8000:c9:9061:ce0d:93bf:336d] (unknown [IPv6:2001:559:8000:c9:9061:ce0d:93bf:336d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client did not present a certificate) by family.redbarn.org (Postfix) with ESMTPSA id E1467892C6; Tue, 21 Aug 2018 18:54:25 +0000 (UTC)
Message-ID: <5B7C5FDF.9040501@redbarn.org>
Date: Tue, 21 Aug 2018 11:54:23 -0700
From: Paul Vixie <paul@redbarn.org>
User-Agent: Postbox 5.0.25 (Windows/20180328)
MIME-Version: 1.0
To: David Conrad <drc@virtualized.org>
CC: Vittorio Bertola <vittorio.bertola@open-xchange.com>, dnsop WG <dnsop@ietf.org>
References: <CAC=TB13mUH2SDxFb4c3rOz0-Z6PE_r9i84_xK=dmLxiVr45+tA@mail.gmail.com> <CAC=TB11tG4o0dkavXGb20=DGBCrmVoRP60bpzsvq5=Q0zFjhDg@mail.gmail.com> <CAPt1N1kj7Y0dPLeDk=PMqQEpAd-Mvds6VLT8XUC1BYOfdyUbJA@mail.gmail.com> <CAC=TB125M81nwiCTNr8Vbee+Z7Fh_3L+6EdZ8evXVzP-2ji4fg@mail.gmail.com> <CAPt1N1n9hDUZQ-Ltvs73T20=fpG-FR_j-t4m0kMapDiv2Us1kw@mail.gmail.com> <5B78BFB9.40103@redbarn.org> <47508D79-0D49-4F31-9BA6-6DC80C38F1DE@cable.comcast.com> <ad1f6dff-ebcc-97a9-6f4b-1ed683827cc7@dougbarton.us> <1313743534.13562.1534765718802@appsuite.open-xchange.com> <9AFE57A7-1D27-4F86-9013-E3C63E63C582@hopcount.ca> <5B7AE322.3020201@redbarn.org> <CAPt1N1m-Xd-7rvgmk8GOsx34=1hsu76nmTgW-8krC3JF7i57KQ@mail.gmail.com> <265867956.15518.1534783313366@appsuite.open-xchange.com> <CAPt1N1myrdOywur35rXRab2QCrhFiJ0vS4wnT_Pof0epdOPz7A@mail.gmail.com> <471139805.18285.1534847636363@appsuite.open-xchange.com> <FBE862C5-6999-4D2F-A877-4ACDF1F5FBF1@virtualized.org>
In-Reply-To: <FBE862C5-6999-4D2F-A877-4ACDF1F5FBF1@virtualized.org>
Content-Type: text/plain; charset="windows-1252"; format="flowed"
Content-Transfer-Encoding: 8bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/hP7C6GPDmYx7rqF4EV28Lt2vshU>
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: Tue, 21 Aug 2018 18:54:28 -0000


David Conrad wrote:
> Vittorio,
>
> ...
>
> Perhaps I’m misunderstanding: are you saying the folks who provide
> resolution services in a DoH world would have incentive to not follow
> basic security measures?

noting that i am not vittorio, i will punch in as follows.

i do not expect CF to block resolution of its free-tier of CDN 
pseudo-customers; if they thought those folks didn't deserve DNS, they 
would probably think they didn't deserve CDN services either.

i block quite a few free-tier CF CDN pseudo-customers here, because that 
service tier is widely abused. since the addresses associated with these 
low-value pseudo-customers are shared by their paying customers, i can't 
block them at the IP layer. so i block them using DNS RPZ. (i do not 
publish this RPZ because in 1997 or so i got tired of lawsuits.)

anyhow, this is but one of many reasons why i don't want control-plane 
information injected into my network, bypassing my security perimeter. 
while CF is a special case, the general case is where my policies are 
aligned somewhat differently than the user's policies or the content 
provider's policies or the "public DoH" server operator's policies.

my network, my rules. one rule is, no bot-on-bot violence in my house.

-- 
P Vixie