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

Paul Vixie <> Thu, 15 August 2019 19:22 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id BEB561200F8 for <>; Thu, 15 Aug 2019 12:22:20 -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 cEzw8PgWYBka for <>; Thu, 15 Aug 2019 12:22:19 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id F19A5120114 for <>; Thu, 15 Aug 2019 12:22:17 -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 B3977892E8; Thu, 15 Aug 2019 19:22:17 +0000 (UTC)
From: Paul Vixie <>
Date: Thu, 15 Aug 2019 19:22:16 +0000
Message-ID: <2017170.mVuLTY5bmt@linux-9daj>
Organization: none
In-Reply-To: <>
References: <20190815163938.CF9CB85D108@ary.local> <>
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: Thu, 15 Aug 2019 19:22:21 -0000

On Thursday, 15 August 2019 19:00:31 UTC Erik Sy wrote:
> Hi John,
> On 8/15/19 18:39, John Levine wrote:
> > I also like the paper but it misses the largest concern with
> > resolverless DNS: it circumvents DNS based access controls.
> Resolver-less DNS does not circumvent DNS-based access controls. First,
> clients can configure their user agent to filter the DNS records
> retrieved via resolver-less DNS to enforce such access controls.

how? right now network operators use DNS RPZ, implemented in their recursive 
name servers, to achieve multivendor threat intelligence based policy 
enforcement at the DNS level. i know of no similar protocol by which browsers 
could learn the network operator's policy. and in any case some of the policy 
rules expressed in RPZ are about name server names and name server addresses, 
neither of which a browser will know.

so, this _does_ circumvent, as written, and i suspect, by (poltiical) intent.

> Second,
> resolver-less DNS requires in some situations fallback DNS queries using
> the traditional resolver that may conduct DNS-based access controls.

that's small beer, irrelevant to the thread.