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

Paul Vixie <> Fri, 16 August 2019 20:30 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 1B8ED12008B for <>; Fri, 16 Aug 2019 13:30:53 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.899
X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id eydMRaREMexT for <>; Fri, 16 Aug 2019 13:30:51 -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 3F677120018 for <>; Fri, 16 Aug 2019 13:30: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 D4F90892E8 for <>; Fri, 16 Aug 2019 20:30:50 +0000 (UTC)
From: Paul Vixie <>
Date: Fri, 16 Aug 2019 20:30:49 +0000
Message-ID: <5555002.tMPyTYP4cW@linux-9daj>
Organization: none
In-Reply-To: <>
References: <> <7458927.46QQVHFPpo@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 20:30:53 -0000

On Friday, 16 August 2019 20:25:39 UTC Erik Sy wrote:
> ...
> > does this mean an link occuring inside a object
> > would require a real DNS lookup, and that any DNS data included
> > in the link would be ignored by a correctly implemented
> > browser?
> > 
> Let's assume, the user visits the website This website
> requires the resource Furthermore, the
> connection with pushes a DNS record for to the
> client. Now, the client can use the provided DNS record to retrieve
> However, if the server authentication with
> fails, this requires the client to evaluate a fallback DNS lookup.

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 limit it to 
same-origin policy? web publishers wishing to take advantage of whatever 
benefits "resolverless dns" would offer them, can easily rename their linked 
objects to fit a same-origin policy similar to the one used for cookie 

> Expanding this scenario, we can assume file1 requires to retrieve
> and the connection with also pushes the
> corresponding DNS record for Now, the browser can use the DNS
> record for to retrieve file2 because these connection occur within
> the context of the same website assuming a successful server authentication.
> ...

thank you for clarifying that; i redouble my earlier (above) ask that this NOT 
be done.