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

Paul Vixie <paul@redbarn.org> Sat, 17 August 2019 05:39 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 786D812012C for <resolverless-dns@ietfa.amsl.com>; Fri, 16 Aug 2019 22:39: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, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, 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 h1NdPfjDB7cJ for <resolverless-dns@ietfa.amsl.com>; Fri, 16 Aug 2019 22:39:58 -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 17321120113 for <resolverless-dns@ietf.org>; Fri, 16 Aug 2019 22:39:58 -0700 (PDT)
Received: from linux-9daj.localnet (vixp1.redbarn.org [24.104.150.140]) (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 26EC5892E8; Sat, 17 Aug 2019 05:39:56 +0000 (UTC)
From: Paul Vixie <paul@redbarn.org>
To: resolverless-dns@ietf.org, sy@informatik.uni-hamburg.de
Date: Sat, 17 Aug 2019 05:39:55 +0000
Message-ID: <6216510.zdPCGfSLMl@linux-9daj>
Organization: none
In-Reply-To: <71662803-f194-a921-84da-b8c9e8e32cb5@informatik.uni-hamburg.de>
References: <CAHbrMsBhR1yaLxQk7wZk54Jdf5nvkS03KC3UTae0Famu2+SV8g@mail.gmail.com> <16840451.Gnsi7N2eSB@linux-9daj> <71662803-f194-a921-84da-b8c9e8e32cb5@informatik.uni-hamburg.de>
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/z4QmsAzEs2eptqDeh0Uu2OUSD7Y>
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: Sat, 17 Aug 2019 05:40:00 -0000

On Friday, 16 August 2019 21:52:40 UTC Erik Sy wrote:
> On 8/16/19 23:02, Paul Vixie wrote:
> > * * *
> > 
> > i'm also waiting to see a problem statement that justifies resolverless
> > dns, and if we get past that, i'll want to see how the network operator's
> > policies for dns monitoring and filtering will be reliably detected, and
> > respected.
> Clients using a traditional DNS resolver do not care about a validation
> of those DNS records.

i have significant evidence to the contrary.

> Resolver-less DNS changes this practice and
> applies validation strategies for DNS records to improve the clients
> security.

your reinvention will not be universally welcomed as a saviour.

> In this thread, we talked about possible privacy drawbacks of
> resolver-less DNS. However, did we talk about the privacy risks of using
> a traditional DNS resolver? They can monitor the entire browsing
> activities of a user and present the real privacy problem.

DoT (RFC 7858) corrects that privacy problem and is being deployed.

> Finally, DNS lookups introduce additional delay to connection
> establishments on the web. Especially, for clients on high-latency
> access networks this delay is quite significant. In my view, user and
> service provider benefit from resolver-less DNS as it reduces that delay
> and contributes to an accelerated retrieval of websites.

you are not the first designer to prioritize performance over safety and 
correctness, or to offer one-off solutions which do not help to create a 
unified architecture where each part leverages the whole.

please respect the network operator's wishes if local DNS policy filtering 
and/or monitoring is a requirement.

please do not define a protocol which offers, or accepts, non-same-origin 
data.

i will be happy to meet you on a teleconference to discuss these matters.

-- 
Paul