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

Viktor Dukhovni <> Thu, 29 August 2019 15:34 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id C027A1208B1 for <>; Thu, 29 Aug 2019 08:34:46 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -4.2
X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id V2cwzAcgAUAP for <>; Thu, 29 Aug 2019 08:34:45 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id D41631208AD for <>; Thu, 29 Aug 2019 08:34:44 -0700 (PDT)
Received: from [] ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPSA id 1AF884C874 for <>; Thu, 29 Aug 2019 11:34:44 -0400 (EDT)
Content-Type: text/plain; charset="us-ascii"
Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\))
From: Viktor Dukhovni <>
In-Reply-To: <>
Date: Thu, 29 Aug 2019 11:34:42 -0400
Content-Transfer-Encoding: quoted-printable
Message-Id: <>
References: <> <4568720.uvMTqBdgP4@linux-9daj> <> <34813218.VKkrhzyXsx@linux-9daj> <> <> <> <> <> <> <> <> <> <>
X-Mailer: Apple Mail (2.3445.104.11)
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: Thu, 29 Aug 2019 15:34:47 -0000

> On Aug 29, 2019, at 10:36 AM, Erik Sy <> wrote:
> On 8/27/19 23:39, Viktor Dukhovni wrote:
>> Of course I am OK with a security mechanism that may deny access,
>> that's not the right question.
> I disagree, that this question is flawed. It assumes that DNSSEC + DANE
> is an optional security mechanism in the context of web browsers.

Do or don't, there is no "try".  Optional security mechanisms are
largely pointless.  Presently browsers don't support DANE, some
day they may.  In any case, the issue at hand is DNS(SEC) bypass,
not DANE.

Resolver-less DNS as proposed disregards long-standing defenses
against address forgery by third parties, breaks geo load-balancing,
breaks local filters that protect networks against known bad actors,
and IDS systems that detect compromised nodes.

It introduce a new cache-poisoning channel, and surprising differences
between the IP addresses a browser might use to reach a site from cold
start vs. after visiting some unrelated site.

In the case of IPv6 it can be used to fingerprint and track clients by
giving them ephemeral client-specific addresses (in the server's /64
or broader prefix) for third-party servers, and then proxying their
connections (at layer 4) to the real server, while tracking the
client's access to each site.
> At least the given mechanism needs also to provide a significant
> security benefit. In my view, the additional benefit of DNSSEC+ DANE
> compared to Certificate Transparency + Strict Transport Security (HSTS
> or MTA-STS) is for the majority of server operators or users not relevant.

Let's not mix up HTTP and MTA-to-MTA SMTP.  In SMTP, DANE has significantly
broader deployment (protected domains) than MTA-STS.  The latter covers more
users of the big three centralized free email providers, but I am not a fan
of over-centralization of the Internet, and prefer open federated architectures.

> In my view, supporting DNSSEC + DANE TLSA in resolver-less DNS makes
> only sense if the server provides a full DNSSEC validation chain because
> everything else seems to introduce significant delays.

In any case, the issue at hand is DNS, not DANE.  A client that wants TLSA
records is not going to obtain them via resolver-less DNS, which IIRC is
just about IP addresses.