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

Paul Vixie <paul@redbarn.org> Fri, 16 August 2019 15:35 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 C5471120824 for <resolverless-dns@ietfa.amsl.com>; Fri, 16 Aug 2019 08:35:49 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level:
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 mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PS8A1G4VI8Oz for <resolverless-dns@ietfa.amsl.com>; Fri, 16 Aug 2019 08:35:48 -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 860E212080A for <resolverless-dns@ietf.org>; Fri, 16 Aug 2019 08:35:48 -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 52B03892E8 for <resolverless-dns@ietf.org>; Fri, 16 Aug 2019 15:35:48 +0000 (UTC)
From: Paul Vixie <paul@redbarn.org>
To: resolverless-dns@ietf.org
Date: Fri, 16 Aug 2019 15:35:47 +0000
Message-ID: <22057767.kxZJMFVDak@linux-9daj>
Organization: none
In-Reply-To: <20190816152532.z1q1S%steffen@sdaoden.eu>
References: <67d6cd75-ca8d-06cf-dd7a-b52d1416ab3f@informatik.uni-hamburg.de> <1E5934E0-3A30-436F-B127-75F985DEFFF9@fugue.com> <20190816152532.z1q1S%steffen@sdaoden.eu>
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/I1qQPIkeLBdUUhBqxMl8KkAD2NM>
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 15:35:50 -0000

On Friday, 16 August 2019 15:25:32 UTC Steffen Nurpmeso wrote:
> ...
> 
> I do not understand, and never (~18 years) did, why the complexity
> of DNS is increased so much; instead of moving over to secure
> transport that is.

DNS over TLS (note, this is not the same as DNS over HTTPS) is such a 
transport. however, transport security doesn't assure data authenticity. 
therefore the another complexity (DNSSEC) was added first. and, neither of 
these protocols can be used to express permission, so another complexity 
(TSIG) was added before either of the others.

> And if you want to sign data bundles, then
> those keys could also be used, they have the potential for it, do
> they.

no. both for reasons of caching and reasons of policy and monitoring, most DNS 
transactions are bounced through relays called "full resolvers". if you try to 
design these out, your system will lose vital properties compared to DNS 
itself.

> Repeatedly connect up to the root domain of your URL in
> question, and collect certificates along the way, unless you have
> the complete chain, which you can cache locally.  Especially if
> you now even pump the data as such over an already open HTTP
> channel.  But in general this looked to me the much more elegant
> resolution (once i looked at DNSSEC and TSIG and said "no
> (hopefully not)").  And much easier to implement, and by using
> facilities of libraries which see many eyes.  And keeping the core
> protocol clean.

the losses from this approach would be, as stated above, vital.

the web isn't by far the only app running on the internet, and while it will 
grow, the internet is larger will grow faster.

-- 
Paul