Re: [Resolverless-dns] Paper on Resolver-less DNS

Paul Vixie <paul@redbarn.org> Fri, 16 August 2019 21:45 UTC

Return-Path: <paul@redbarn.org>
X-Original-To: resolverless-dns@ietfa.amsl.com
Delivered-To: resolverless-dns@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 347DC120071 for <resolverless-dns@ietfa.amsl.com>; Fri, 16 Aug 2019 14:45:11 -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, SPF_HELO_NONE=0.001, 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 jBCQh8fGDw43 for <resolverless-dns@ietfa.amsl.com>; Fri, 16 Aug 2019 14:45:09 -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 3FC2B120018 for <resolverless-dns@ietf.org>; Fri, 16 Aug 2019 14:45:09 -0700 (PDT)
Received: from linux-9daj.localnet (50-255-33-26-static.hfc.comcastbusiness.net [50.255.33.26]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by family.redbarn.org (Postfix) with ESMTPSA id 14594892E8; Fri, 16 Aug 2019 21:45:09 +0000 (UTC)
From: Paul Vixie <paul@redbarn.org>
To: resolverless-dns@ietf.org
Cc: Anne Bennett <anne@encs.concordia.ca>
Date: Fri, 16 Aug 2019 21:45:08 +0000
Message-ID: <9323236.5EVOHOzQma@linux-9daj>
Organization: none
In-Reply-To: <27027.1565991325@vindemiatrix.encs.concordia.ca>
References: <CAHbrMsBhR1yaLxQk7wZk54Jdf5nvkS03KC3UTae0Famu2+SV8g@mail.gmail.com> <16840451.Gnsi7N2eSB@linux-9daj> <27027.1565991325@vindemiatrix.encs.concordia.ca>
MIME-Version: 1.0
Content-Transfer-Encoding: 7Bit
Content-Type: text/plain; charset="us-ascii"
Archived-At: <https://mailarchive.ietf.org/arch/msg/resolverless-dns/GUtsrFrELv6PNdZ27iqRZgNuZRA>
Subject: Re: [Resolverless-dns] Paper on Resolver-less DNS
X-BeenThere: resolverless-dns@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Resolverless DNS <resolverless-dns.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/resolverless-dns>, <mailto:resolverless-dns-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/resolverless-dns/>
List-Post: <mailto:resolverless-dns@ietf.org>
List-Help: <mailto:resolverless-dns-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/resolverless-dns>, <mailto:resolverless-dns-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 16 Aug 2019 21:45:11 -0000

On Friday, 16 August 2019 21:35:25 UTC Anne Bennett wrote:
> Paul Vixie <paul@redbarn.org> writes:
> > i'll want to see how the network operator's policies for
> > dns monitoring and filtering will be reliably detected,
> > and respected.
> 
> I would think this to be an impossible task; if I as a network
> operator am redirecting all port 53 traffic to my resolvers,
> which use various filtering policies to, for example, redirect
> queries for known phishing and malware sites to my local
> "don't be phished" web page, what on earth mechanism could
> possibly exist that could mirror my policies in this context?

this draft in another wg appears to be an attempt at such:

https://datatracker.ietf.org/doc/draft-sah-resolver-information/

i don't know if it can meet the "reliably detected" threshold though.

> While I believe in the bona fide of the people advocating for
> resolverless DNS, and I don't doubt that there are performance
> bottlenecks that could be alleviated with such a scheme, as a
> sysadmin I feel almost as if these designs were specifically
> created to prevent me from protecting my users.  :-(

i know that feeling. but i think what's happened is the next generation of 
internet technologists have taken an interest in dns, without ever having 
tried to secure it or defend it, or its applications. not knowing what they 
don't know, their proposals seem more reasonable to them than to me.

see also:

http://dnstap.info/

and:

https://dnsrpz.info/

-- 
Paul