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

Eric Osterweil <> Sat, 31 August 2019 19:11 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 96534120122 for <>; Sat, 31 Aug 2019 12:11:22 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.9
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 ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id N1Wf-ec1qNul for <>; Sat, 31 Aug 2019 12:11:20 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 0E120120132 for <>; Sat, 31 Aug 2019 12:11:20 -0700 (PDT)
Received: by with SMTP id z4so11417881qtc.3 for <>; Sat, 31 Aug 2019 12:11:20 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=0Ak+kaP74xpDK6D0IRaV9u6WNroDjS1Ve7Ay1rhv64o=; b=rAKAG8wnKeuOr1ldQIOJWQmVoP2gSoiGBnHqOf9L8ynaOYW1ydegUwBZcfwD/M4U1S tHskVyTGwIgta8cRnX1ZYBHc79xw3KWpOIvbHp1/q5CO3iFMZX3OocJyZ/NHm8gOqyYT uSLQ3NzCq8r+od2FGPb9OhtHbRxIVsPSnlr7nakJ1QFAzQaUe39rK3nYydz2tO2P6RoR tyVPivHUMvA4FQmhFA3DN/+RY8WdqKpV2tOe+5Xo8LviSC9kLVezaKpA+BYbBljfrZrt S9ccFZBXTruVXlsmYHFiadPEzNl0VULOwhca8Us4LgatQzMg8t6DBZDizE3Ab8g02YyQ bxcQ==
X-Gm-Message-State: APjAAAXZEZe1HHXsd4nmypTeLDqZoG/mrzGJEnIWU4GJZbjtCgDkaL0P qtW3xpWcXeXooGiyjxJaUZGaOKdqA1I=
X-Google-Smtp-Source: APXvYqz5VbyIaHaLC0NdPacwzuBTSdCyz2NxSfZ0WWO7s+uUIqGfEPv6c5LkoBBGLrq8ZIY6GHhJlA==
X-Received: by 2002:a0c:fd91:: with SMTP id p17mr14193035qvr.170.1567278679073; Sat, 31 Aug 2019 12:11:19 -0700 (PDT)
Received: from [] ([]) by with ESMTPSA id h137sm4237664qke.51.2019. (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sat, 31 Aug 2019 12:11:18 -0700 (PDT)
Content-Type: text/plain; charset="utf-8"
Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\))
From: Eric Osterweil <>
In-Reply-To: <>
Date: Sat, 31 Aug 2019 15:11:17 -0400
Content-Transfer-Encoding: quoted-printable
Message-Id: <>
References: <> <4568720.uvMTqBdgP4@linux-9daj> <> <34813218.VKkrhzyXsx@linux-9daj> <> <> <> <> <> <> <> <>
X-Mailer: Apple Mail (2.3445.9.1)
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: Sat, 31 Aug 2019 19:11:30 -0000

Jumping back to this (focusing on just DNSSEC for a moment):

> On Aug 27, 2019, at 5:20 PM, Erik Sy <> wrote:
> Hi Eric and Viktor,
> On 8/25/19 22:40, Erik Sy wrote:
>> Here is a quote from Chris Palmer on this issue[1]:
>> "The strength of PKP ― run-time enforcement with hard-fail — is also
>> exactly its weakness. Some people are OK with the risk, but overall I
>> think the market has spoken: HPKP has seen close to no adoption. People
>> don't want to brick their sites.
>> As for DANE, it would at best have the same strength/weakness of HPKP,
>> but with the additional problems of DNSSEC."
>> In total, it seems like Chrome does not want to deploy DANE.
>> Erik
>> 1:
> It seems to me, that both of you are OK with the risk of DNSSEC + DANE
> TLSA leading to hard failures. I share the view of Chris Palmer, that
> the security improvements of Public Key Pinning (PKP) in browsers are
> not worth the caused usability issues.

Here’s a quote (and write-up) from Geoff Huston:
	``Failing to secure DNS is 'savage ignorance’’' -
ymmv ;)

> I like to point out, that resolver-less DNS can be extended to support
> DNSSEC + DANE TLSA as a validation mechanism for DNS records. Thus, in
> case browser vendors decide to support DNSSEC + DANE TLSA the browsers
> can receive the corresponding records also via resolver-less DNS.

To be a little more blunt (or maybe not): I think it’s false logic to treat this as a choice for new protocol development.
DNS is an infrastructure protocol.  In it, authorities and resolvers _both_ play a role (through their stated/deployed security postures) in how they want security to be enforced.  DNS' security extensions are part of how rightful resource holders (authoritative zones) express their desire and intent to secure their resources, separately from how resolvers verify security.  It seems to me to be poor engineering if a newer protocol encourages resolvers to ignore authorities' stated desire for security.  I’d posit that newer protocols that intend to _interoperate_ with the DNS can only correctly do so by conforming with that protocol’s specification (and those of its standards-track extensions), of which DNSSEC is one.  That is what protocols are for: interoperation of heterogeneous implementations/systems.  The idea that cherry-picking which part of DNS a new protocol suite wants to embrace is a suspicious approach to engineering protocols, imho.