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

Tom Pusateri <pusateri@bangj.com> Tue, 21 August 2018 19:24 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 DE422130ED0 for <dnsop@ietfa.amsl.com>; Tue, 21 Aug 2018 12:24:24 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level:
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 mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id n_JWwDa8ASsE for <dnsop@ietfa.amsl.com>; Tue, 21 Aug 2018 12:24:22 -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 27A4F130E8E for <dnsop@ietf.org>; Tue, 21 Aug 2018 12:24:22 -0700 (PDT)
Received: from [10.244.195.212] (unknown [71.69.162.195]) (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 C436023C7; Tue, 21 Aug 2018 15:20:18 -0400 (EDT)
Content-Type: text/plain; charset=utf-8
Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\))
From: Tom Pusateri <pusateri@bangj.com>
In-Reply-To: <5B7C5FDF.9040501@redbarn.org>
Date: Tue, 21 Aug 2018 15:24:19 -0400
Cc: David Conrad <drc@virtualized.org>, Vittorio Bertola <vittorio.bertola@open-xchange.com>, dnsop WG <dnsop@ietf.org>
Content-Transfer-Encoding: quoted-printable
Message-Id: <384B3B82-8423-45AA-8CC8-14C5D8DE9678@bangj.com>
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> <5B7C5FDF.9040501@redbarn.org>
To: Paul Vixie <paul@redbarn.org>
X-Mailer: Apple Mail (2.3445.9.1)
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/ZAYlvVVtP0fNgDNDU9FLb0z4Npo>
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 19:24:37 -0000


> On Aug 21, 2018, at 2:54 PM, Paul Vixie <paul@redbarn.org> wrote:
> 
> 
> 
> 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

Ok, so as Vladimír said, getting back to DHCP…

1. You obviously don’t need a DoH URI option for DHCP.
2. You’re comfortable with DNS over UDP/53 as long as DNS Cookies are present and using the existing DHCP DNS options
3. You seem happy with the Android approach of just trying DoT with the IP address learned via standard DHCP DNS options

Why do you care about additional DHCP options?

Thanks,
Tom