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

Paul Vixie <paul@redbarn.org> Fri, 16 August 2019 19:50 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 5D08E1200D6 for <resolverless-dns@ietfa.amsl.com>; Fri, 16 Aug 2019 12:50:19 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.799
X-Spam-Level:
X-Spam-Status: No, score=-1.799 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, URIBL_BLOCKED=0.001, URI_HEX=0.1] autolearn=no 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 jZzLcrwxCzeQ for <resolverless-dns@ietfa.amsl.com>; Fri, 16 Aug 2019 12:50:17 -0700 (PDT)
Received: from family.redbarn.org (family.redbarn.org [24.104.150.213]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 45EFC120090 for <resolverless-dns@ietf.org>; Fri, 16 Aug 2019 12:50:17 -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 AEBA9892E8 for <resolverless-dns@ietf.org>; Fri, 16 Aug 2019 19:50:16 +0000 (UTC)
From: Paul Vixie <paul@redbarn.org>
To: resolverless-dns@ietf.org
Date: Fri, 16 Aug 2019 19:50:15 +0000
Message-ID: <7458927.46QQVHFPpo@linux-9daj>
Organization: none
In-Reply-To: <4bb74759-804e-bdb5-faa2-cee682c56905@informatik.uni-hamburg.de>
References: <CAHbrMsBhR1yaLxQk7wZk54Jdf5nvkS03KC3UTae0Famu2+SV8g@mail.gmail.com> <CA+9kkMBLJPzgadJN3sFVoRKB7Zb=z0-Sxm3t2F1Pv8RM0PGoAA@mail.gmail.com> <4bb74759-804e-bdb5-faa2-cee682c56905@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/-HWur9nJEbE8wHhfvznM9Tib-Qg>
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 19:50:19 -0000

On Friday, 16 August 2019 18:40:43 UTC Erik Sy wrote:
> ...
> 
> Beyond this, I describe in Section 3.2.2 of the paper restrictions for
> DNS records retrieved via resolver-less DNS. Here, it is recommended
> that user agents restrict the use of unvalidated DNS records retrieved
> via resolver-less DNS within the context of the same website or possibly
> the same browser tab. This measure prevents the described leaks beyond
> the applied context of a website or browser tab. Thus, I do not agree
> that resolver-less DNS contributes to the described increase in the
> attack surface.
> 
> Erik

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?

i ask, because of this:

> ;; ANSWER SECTION:
> www.microsoft.com.  CNAME  www.microsoft.com-c-3.edgekey.net.
> www.microsoft.com-c-3.edgekey.net. CNAME www.microsoft.com-
c-3.edgekey.net.globalredir.akadns.net.
> www.microsoft.com-c-3.edgekey.net.globalredir.akadns.net. CNAME 
e13678.dspb.akamaiedge.net.
> e13678.dspb.akamaiedge.net. A 23.197.97.139

my stub resolvers trust this from their recursive servers. but such CNAME 
chains are ignored by recursive servers, since the authority can only speak 
for one zone at a time. i'd like to be sure that i understand the rules you 
are proposing for the web equivalent of all this.

-- 
Paul