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

Paul Vixie <> Thu, 22 August 2019 03:08 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 1AAFE12003F for <>; Wed, 21 Aug 2019 20:08:33 -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, 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 T82EoL2Wp4kS for <>; Wed, 21 Aug 2019 20:08:32 -0700 (PDT)
Received: from ( [IPv6:2001:559:8000:cd::5]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 2969E120018 for <>; Wed, 21 Aug 2019 20:08:32 -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 02A91892E8; Thu, 22 Aug 2019 03:08:31 +0000 (UTC)
From: Paul Vixie <>
Cc: Ted Lemon <>,
Date: Thu, 22 Aug 2019 03:08:31 +0000
Message-ID: <1827562.zAUzFULyIp@linux-9daj>
Organization: none
In-Reply-To: <>
References: <1781914.51cSh5WzdD@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: Thu, 22 Aug 2019 03:08:33 -0000

On Thursday, 22 August 2019 02:39:37 UTC Ted Lemon wrote:
> So, for your use case it would be good if there were a way for authorized
> devices to know that they are connected to your network and use your
> resolvers, and a way to quarantine devices that have not been configured
> that way. Or you could just have always use your resolver if they are
> willing.

i don't love the term "use case" for this. the onus of justification is upon 
she who would change from the status quo.

what i've asked is that this behaviour rely on a secure and reliable signal 
from the system's resolver that it has no objections to the use of some other 
data path for DNS. if the system's resolver doesn't signal either way, then 
don't use any other data path for DNS.

its reasons may be filtering, or monitoring, or the principle of least 
astonishment, or moonshine. in other words its reasons don't matter.