Re: DNSSEC architecture vs reality

Nico Williams <> Mon, 12 April 2021 23:19 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 85B353A1606 for <>; Mon, 12 Apr 2021 16:19:03 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.119
X-Spam-Status: No, score=-2.119 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (1024-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id vCURuDO4Cv32 for <>; Mon, 12 Apr 2021 16:18:59 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 0FA643A1605 for <>; Mon, 12 Apr 2021 16:18:58 -0700 (PDT)
X-Sender-Id: dreamhost|x-authsender|
Received: from (localhost []) by (Postfix) with ESMTP id 84144342E09; Mon, 12 Apr 2021 23:18:57 +0000 (UTC)
Received: from (100-96-11-78.trex.outbound.svc.cluster.local []) (Authenticated sender: dreamhost) by (Postfix) with ESMTPA id 190E6342E49; Mon, 12 Apr 2021 23:18:57 +0000 (UTC)
X-Sender-Id: dreamhost|x-authsender|
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384) by (trex/6.1.1); Mon, 12 Apr 2021 23:18:57 +0000
X-MC-Relay: Neutral
X-MailChannels-SenderId: dreamhost|x-authsender|
X-MailChannels-Auth-Id: dreamhost
X-Tangy-Thread: 19c7d8aa381d6228_1618269537338_146448295
X-MC-Loop-Signature: 1618269537337:3738655229
X-MC-Ingress-Time: 1618269537337
Received: from (localhost []) by (Postfix) with ESMTP id C3B218AAE6; Mon, 12 Apr 2021 16:18:56 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed;; h=date :from:to:cc:subject:message-id:references:mime-version :content-type:in-reply-to;; bh=6AT8P39MAxxzWx 5wRE/zHJnVybg=; b=Iw0HaIjNiI5T4Rg1S3Xd/mF8SMxvJ2Z6Jh1rBiYReu6061 aW/E0+Tituow/QD1qnhweEE8BkT9YcW1C2jXR9LPgKAefsbhqxW0xCYLA6t/W+56 6UDkNjPHBCFGD5rKfMMM6NAszMh4hyJJI22+V1eAkq/v9EzVY7VVc8OPKVO6Y=
Received: from localhost (unknown []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) (Authenticated sender: by (Postfix) with ESMTPSA id 3C5417E5FC; Mon, 12 Apr 2021 16:18:53 -0700 (PDT)
Date: Mon, 12 Apr 2021 18:18:51 -0500
X-DH-BACKEND: pdx1-sub0-mail-a47
From: Nico Williams <>
To: Michael Thomas <>
Subject: Re: DNSSEC architecture vs reality
Message-ID: <20210412231850.GA9612@localhost>
References: <> <> <> <> <> <> <20210412221435.GV9612@localhost> <> <20210412222748.GW9612@localhost> <>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <>
User-Agent: Mutt/1.9.4 (2018-02-28)
Archived-At: <>
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: IETF-Discussion <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Mon, 12 Apr 2021 23:19:04 -0000

On Mon, Apr 12, 2021 at 03:43:31PM -0700, Michael Thomas wrote:
> The one thing that bugs me about DANE is its use of a native RR type. This
> is a well trodden argument of doing it proper and doing it in a deployable
> way. We know what happens when you do it the "right way" which is usually
> nothing at all. If it started to get popular, we could gin up a TXT record
> alternative though, I suppose. When we were doing DKIM at Cisco, our IT
> folks were incredibly accommodating, but implementing a new RR type in their
> infrastructure would have probably been a bridge too far. Heck, I wouldn't
> be surprised if Mark at Y! got told the same thing :)

Hmm, well, as they say, "new RR types are cheap", though more
importantly document authors get forced to use new RR types rather than
use TXT RRs.  But tooling for hosting sites and such is a problem, yes,
even if it isn't for servers and clients.  But this is water under the
bridge now.  And if anything, the IETF is tripling down on more new RR