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

Paul Vixie <paul@redbarn.org> Thu, 22 August 2019 21:51 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 BD31C120C2F for <resolverless-dns@ietfa.amsl.com>; Thu, 22 Aug 2019 14:51:02 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.898
X-Spam-Level:
X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, 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 ZxDbbqO7V09k for <resolverless-dns@ietfa.amsl.com>; Thu, 22 Aug 2019 14:51:01 -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 42A6C12012E for <resolverless-dns@ietf.org>; Thu, 22 Aug 2019 14:51:01 -0700 (PDT)
Received: from linux-9daj.localnet (vixp1.redbarn.org [24.104.150.140]) (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 C2597892E8; Thu, 22 Aug 2019 21:50:59 +0000 (UTC)
From: Paul Vixie <paul@redbarn.org>
To: resolverless-dns@ietf.org, sy@informatik.uni-hamburg.de
Date: Thu, 22 Aug 2019 21:50:58 +0000
Message-ID: <34813218.VKkrhzyXsx@linux-9daj>
Organization: none
In-Reply-To: <fb12f102-714d-95cc-c6cc-0871a2df9f50@informatik.uni-hamburg.de>
References: <CAHbrMsBhR1yaLxQk7wZk54Jdf5nvkS03KC3UTae0Famu2+SV8g@mail.gmail.com> <4568720.uvMTqBdgP4@linux-9daj> <fb12f102-714d-95cc-c6cc-0871a2df9f50@informatik.uni-hamburg.de>
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="nextPart1763975.AAR2ODdUOy"
Content-Transfer-Encoding: 7bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/resolverless-dns/h4K-0G2M76Tq5PJW5UjaQnh8nAE>
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: Thu, 22 Aug 2019 21:51:03 -0000

On Thursday, 22 August 2019 21:11:58 UTC Erik Sy wrote:
> On 8/20/19 23:12, Paul Vixie wrote:
> >> I assume that by
> >> referring to DNSSEC and DANE, you do not want to claim that some popular
> >> client software is strictly enforcing a validation of DNS records using
> >> DNSSEC and DANE, right?
> > 
> > caching resolvers everywhere, do this.
> 
> This study shows that only about 12% of the resolvers use DNSSEC to
> validate the records [1].

i think that in 2017 when that report was published, their 12% was very well distributed, 
geographically and topologically, and that it represents a disproportionate share of 
lookup transactions.

> >  the economy depends on them doing so.
> 
> I find that only 0.9% of the .com domains are signed [2] and having a
> signature does not mean that they can be successfully validated.

i suggest you broaden your search for knowledge. for example, this web site may be of 
interest, along with the monthly reports posted to dns-operations@ by the same authors.

https://stats.dnssec-tools.org/[1] 

> > if RDNS isn't client software from your point of view, you'll dismiss
> > these assertions.
> 
> RDNS requires the client to trust the used recursive resolver.

not for DANE work flows. stub validation is not widely implemented or well supported by 
DNSSEC, but it works, and existing DANE TLSA clients do this.

> In my view, the client should be able to validate the DNS records
> independently of the recursive resolver.

we agree.

> I think there is a security
> benefit for clients in using TLS server authentication to validate DNS
> records at least in the context of web browsing.

we disagree, for reasons i won't repeat here a second time.

-- 
Paul

--------
[1] https://stats.dnssec-tools.org/