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

Paul Vixie <> Fri, 16 August 2019 21:02 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id D796512007C for <>; Fri, 16 Aug 2019 14:02:52 -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 kIs3G86-Dl4h for <>; Fri, 16 Aug 2019 14:02:51 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 895B0120018 for <>; Fri, 16 Aug 2019 14:02:51 -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 1A855892E8; Fri, 16 Aug 2019 21:02:50 +0000 (UTC)
From: Paul Vixie <>
Date: Fri, 16 Aug 2019 21:02:49 +0000
Message-ID: <16840451.Gnsi7N2eSB@linux-9daj>
Organization: none
In-Reply-To: <>
References: <> <5555002.tMPyTYP4cW@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: Fri, 16 Aug 2019 21:02:53 -0000

On Friday, 16 August 2019 20:50:05 UTC Erik Sy wrote:
> > quite aside from my concerns about the lack of monitoring and control
> > by the local network operator (who may have DNS policies which no
> > standard ought to ignore or bypass), this seems wrong on the face of it.
> Can you please explain your concern and why you think that a limitation
> to a same-origin policy is required?

nothing which can be abused won't be. your design has at least one flaw that a 
red team would find for you if you had one. instead you've got us.

there is no reason for a web client to trust a web server to provide correct 
information about dns outside of its same-origin. that data could be stale, 
accidentally wrong, or purposefully wrong. this problem is why dnssec exists.

i believe i've seen you argue elsewhere in this thread as to the authenticity 
guarantees of the TLS (HTTPS) path from the web client to the web server. i 
don't agree with that view, and the DANE (TLSA RR) approach is necessary.

however, even if i agreed, i would decline a design which called for the 
client to trust the server to have accurate information about any domain 
outside of the same-origin policy which we already trust for cookie coverage.

* * *

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.