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

Paul Vixie <paul@redbarn.org> Sun, 19 August 2018 05:03 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 D145B130E27 for <dnsop@ietfa.amsl.com>; Sat, 18 Aug 2018 22:03:59 -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 9rMUQiRlEuQO for <dnsop@ietfa.amsl.com>; Sat, 18 Aug 2018 22:03:58 -0700 (PDT)
Received: from family.redbarn.org (family.redbarn.org [IPv6:2001:559:8000:cd::5]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5E06A130DFE for <dnsop@ietf.org>; Sat, 18 Aug 2018 22:03:58 -0700 (PDT)
Received: from [IPv6:2001:559:8000:c9:1c6f:2fd8:8c7b:9a62] (unknown [IPv6:2001:559:8000:c9:1c6f:2fd8:8c7b:9a62]) (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 20978892C7; Sun, 19 Aug 2018 05:03:55 +0000 (UTC)
Message-ID: <5B78FA39.1080406@redbarn.org>
Date: Sat, 18 Aug 2018 22:03:53 -0700
From: Paul Vixie <paul@redbarn.org>
User-Agent: Postbox 5.0.25 (Windows/20180328)
MIME-Version: 1.0
To: Ted Lemon <mellon@fugue.com>
CC: Marek Vavruša <mvavrusa@cloudflare.com>, dnsop <dnsop@ietf.org>
References: <CAC=TB13mUH2SDxFb4c3rOz0-Z6PE_r9i84_xK=dmLxiVr45+tA@mail.gmail.com> <CAPt1N1=-792WkQmbTigPdqOh0dONykYycG0hheOecoQa4ai=Hw@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> <CAPt1N1nEH86yPvtoNqJ+xM-OFunEqr2x8s2LV_yFU1fkVt9WUQ@mail.gmail.com> <5B78C60E.4010307@redbarn.org> <CAPt1N1kxspYrAHF_L57im+W_5qVV=gYjg4ObVMwpQj60ASnL4w@mail.gmail.com> <5B78CE86.8030004@redbarn.org> <CAPt1N1=Mx7Xc7+q2C=96WotJCY9FUVa=ivMRKOn4r9VS9rwRsQ@mail.gmail.com>
In-Reply-To: <CAPt1N1=Mx7Xc7+q2C=96WotJCY9FUVa=ivMRKOn4r9VS9rwRsQ@mail.gmail.com>
Content-Type: text/plain; charset="windows-1252"; format="flowed"
Content-Transfer-Encoding: 7bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/VcH4w0awM28QYOxPc841T4AAR38>
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 05:04:00 -0000


Ted Lemon wrote:
> Well, if that's true, Paul, then I guess DNS filter lists are totally
> unnecessary and you should stop working on that.   Maybe you already have?

see https://dnsrpz.info/ for more details on DNS Firewalls. of course, 
nominum was selling something like this ten years ago, and others have 
also developed similar capabilities in-house. this is a published spec 
so as to allow an unlimited number of subscribing defenders to choose 
from an unlimited number of publishing suppliers using one "language".

it's possible that others who have not begun to use RDNS as a perimeter 
defense do not understand why some of us can't allow every app or 
browser or user to transmit their own dns requests to outside servers. 
that is, we as network operators want to prevent some lookups from 
succeeding, in order to keep certain known-malicious activities frozen.

you may be excluding a middle in your analysis of what i've said. if a 
user or app can't get the DNS service they prefer, they should either 
use a different network, or shut off and go count mountain butterflies. 
in no event should they seek a bypass to the network operator's security 
policy. "their network, their rules."

-- 
P Vixie