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

Paul Vixie <> Sat, 17 August 2019 05:39 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 786D812012C for <>; Fri, 16 Aug 2019 22:39:59 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.9
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 ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id h1NdPfjDB7cJ for <>; Fri, 16 Aug 2019 22:39:58 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 17321120113 for <>; Fri, 16 Aug 2019 22:39:58 -0700 (PDT)
Received: from linux-9daj.localnet ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by (Postfix) with ESMTPSA id 26EC5892E8; Sat, 17 Aug 2019 05:39:56 +0000 (UTC)
From: Paul Vixie <>
Date: Sat, 17 Aug 2019 05:39:55 +0000
Message-ID: <6216510.zdPCGfSLMl@linux-9daj>
Organization: none
In-Reply-To: <>
References: <> <16840451.Gnsi7N2eSB@linux-9daj> <>
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"
Archived-At: <>
Subject: Re: [Resolverless-dns] Paper on Resolver-less DNS
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Resolverless DNS <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-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 

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