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

Paul Vixie <paul@redbarn.org> Fri, 16 August 2019 20:30 UTC

Return-Path: <paul@redbarn.org>
X-Original-To: resolverless-dns@ietfa.amsl.com
Delivered-To: resolverless-dns@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1B8ED12008B for <resolverless-dns@ietfa.amsl.com>; Fri, 16 Aug 2019 13:30:53 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.899
X-Spam-Level:
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 mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eydMRaREMexT for <resolverless-dns@ietfa.amsl.com>; Fri, 16 Aug 2019 13:30:51 -0700 (PDT)
Received: from family.redbarn.org (family.redbarn.org [IPv6:2001:559:8000:cd::5]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3F677120018 for <resolverless-dns@ietf.org>; Fri, 16 Aug 2019 13:30:51 -0700 (PDT)
Received: from linux-9daj.localnet (50-255-33-26-static.hfc.comcastbusiness.net [50.255.33.26]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by family.redbarn.org (Postfix) with ESMTPSA id D4F90892E8 for <resolverless-dns@ietf.org>; Fri, 16 Aug 2019 20:30:50 +0000 (UTC)
From: Paul Vixie <paul@redbarn.org>
To: resolverless-dns@ietf.org
Date: Fri, 16 Aug 2019 20:30:49 +0000
Message-ID: <5555002.tMPyTYP4cW@linux-9daj>
Organization: none
In-Reply-To: <6836f7e2-c71d-1460-8d53-b3960633a1db@informatik.uni-hamburg.de>
References: <CAHbrMsBhR1yaLxQk7wZk54Jdf5nvkS03KC3UTae0Famu2+SV8g@mail.gmail.com> <7458927.46QQVHFPpo@linux-9daj> <6836f7e2-c71d-1460-8d53-b3960633a1db@informatik.uni-hamburg.de>
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"
Archived-At: <https://mailarchive.ietf.org/arch/msg/resolverless-dns/d3-g4WdKY0GRJcl77bn-F42z6tw>
Subject: Re: [Resolverless-dns] Paper on Resolver-less DNS
X-BeenThere: resolverless-dns@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Resolverless DNS <resolverless-dns.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/resolverless-dns>, <mailto:resolverless-dns-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/resolverless-dns/>
List-Post: <mailto:resolverless-dns@ietf.org>
List-Help: <mailto:resolverless-dns-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/resolverless-dns>, <mailto:resolverless-dns-request@ietf.org?subject=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 fbcdn.net link occuring inside a facebook.com object
> > would require a real DNS lookup, and that any fbcdn.net DNS data included
> > in the facebook.com link would be ignored by a correctly implemented
> > browser?
> > 
> Let's assume, the user visits the website facebook.com. This website
> requires the resource https://fbcdn.net/file1. Furthermore, the
> connection with facebook.com pushes a DNS record for fbcdn.net to the
> client. Now, the client can use the provided DNS record to retrieve
> https://fbcdn.net/file1. However, if the server authentication with
> fbcdn.net 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 
coverage.

> Expanding this scenario, we can assume file1 requires to retrieve
> https://a.com/file2 and the connection with fbcdn.net also pushes the
> corresponding DNS record for a.com. Now, the browser can use the DNS
> record for a.com 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.

-- 
Paul