Re: DNSSEC architecture vs reality

Keith Moore <> Mon, 12 April 2021 12:25 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 3FEA93A1BA3 for <>; Mon, 12 Apr 2021 05:25:16 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.918
X-Spam-Status: No, score=-1.918 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, NICE_REPLY_A=-0.001, RCVD_IN_DNSWL_BLOCKED=0.001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id W1a_Ri5vO1xM for <>; Mon, 12 Apr 2021 05:25:11 -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 044CE3A1BA2 for <>; Mon, 12 Apr 2021 05:25:10 -0700 (PDT)
Received: from compute1.internal (compute1.nyi.internal []) by mailout.nyi.internal (Postfix) with ESMTP id DE36B5C013C for <>; Mon, 12 Apr 2021 08:25:05 -0400 (EDT)
Received: from mailfrontend2 ([]) by compute1.internal (MEProxy); Mon, 12 Apr 2021 08:25:05 -0400
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=; h=content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-me-proxy:x-me-proxy:x-me-sender:x-me-sender :x-sasl-enc; s=fm2; bh=BONKZIf3YRK7NUHEccN5nCToOyc/IFW5gsLLV1dGm S8=; b=P+rlTCcA3AhLyN8F/BQxOqJQN3iUXPW8ZPLr2W3D0FabSJ8snfl0hTGgD vMKCi3u5HB++O0cQyTrRe6gHNiAcfZ/T4gu+EgC/FA+0U6ts8BF9koYh8gGOY6pq LGwWuaVXz0mvaFSoOoPZ9Vvj5Gvm/WzZKfHul+nqsPtQItJ82IIeT86xRmUTIuwj xIVxTs/adKLZlBbWOXsdR2pKMzsJOcRCY5H2i7qbO8s9QuUdN7dTILfQWvTGqA/G Oo/v1GVDVBip8Mupc78J9IfgFYVpgI0v7ZNK94V8v2D5FHcYUvy1JPJyHoBuQIXh qWN6XhnwARJ9jpj0wbdjQHS8qAsCA==
X-ME-Sender: <xms:ITx0YNt4FxPrL2_hv2RRTUWB306HygorgeMlswIl9Kmu8uoCqihqNA> <xme:ITx0YIeimQeLtj2n6Jjpt101nS-yFVHfEw_aAGc-2qgRzXyzRg37apTf-BB70DAlr 2-zMpcvciO4iw>
X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeduledrudekjedgheefucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucenucfjughrpefuvfhfhffkffgfgggjtgfgsehtke ertddtfeejnecuhfhrohhmpefmvghithhhucfoohhorhgvuceomhhoohhrvgesnhgvthif ohhrkhdqhhgvrhgvthhitghsrdgtohhmqeenucggtffrrghtthgvrhhnpeehhfeutdehfe fgfefghfekhefguefgieduueegjeekfeelleeuieffteefueduueenucfkphepvdefrddu vdegrddutddrudejtdenucevlhhushhtvghrufhiiigvpedtnecurfgrrhgrmhepmhgrih hlfhhrohhmpehmohhorhgvsehnvghtfihorhhkqdhhvghrvghtihgtshdrtghomh
X-ME-Proxy: <xmx:ITx0YKL-WJP-xySa1Oqb0DsUuXhX8UK3LT32yzSl1XHH6GZKgzlJ3g> <xmx:ITx0YGbsJowozQXxCr81_rzPe3yZtciIZcv5idFzzel5ib6iaIx2WA> <xmx:ITx0YFs4qchvuTOQB1NqUF9i6gBPGeJLVwFApV6R2sSRJRF_X6D97g> <xmx:ITx0YEZTqrpKn6DCQNQzToT2UvIDbY0yhiBXwi2oXU3ll8Ugah9QjA>
Received: from [] ( []) by (Postfix) with ESMTPA id 6B69D108006A for <>; Mon, 12 Apr 2021 08:25:05 -0400 (EDT)
Subject: Re: DNSSEC architecture vs reality
References: <> <> <> <> <> <> <> <> <> <> <>
From: Keith Moore <>
Message-ID: <>
Date: Mon, 12 Apr 2021 08:25:03 -0400
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.10.0
MIME-Version: 1.0
In-Reply-To: <>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 8bit
Content-Language: en-US
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 12:25:16 -0000


Thanks for the update.   It looks as if progress is indeed being made.   
Now I wonder: what is being done to publicize DNSSEC to try to get wider 


On 4/12/21 12:53 AM, Viktor Dukhovni wrote:
> On Sun, Apr 11, 2021 at 07:57:15PM -0400, Keith Moore wrote:
>> On 4/11/21 7:05 PM, Viktor Dukhovni wrote:
>>> There are of course pros/cons for CT and pros/cons for DNSSEC, but my
>>> take is that architecturally DNSSEC is better suited for securing the
>>> typical domain on the public Internet.
>> Architectural arguments are great, but pragmatically speaking there seem
>> to be significant deployment problems with DNSSEC.
> Historically, yes.  But substantial improvements have been made, and it
> is now much easier than it used to be.
>>> Adoption has been hampered by difficult KSK enrollment, rollover,
>>> immaturity of tooling and by habitual cynicism from plausibly
>>> authoritative voices.
>> These aren't the problems (except perhaps immaturity of tooling) that
>> most immediately come to mind.
>> Where is the easy to understand guide for how to sign your own RRs or
>> zone(s), and to verify that the signing is properly done?
> With BIND 9.16, just pick one of the stock policies, and BIND does the
> rest, generates keys, keeps the signatures current, periodically rolls
> the ZSK, even rolls the KSK and publishes CDS/CDNSKEY RRs, and I believe
> delays retiring the old KSK until the parent domain actually updates
> the DS RRs (whether via CDS, or manual update).  Try it!
>> Which registrars provide tools for signing, or do you have to operate
>> your own master DNS server in order to do that?
> If you're talking about registrars that sign zones for you, there are
> many.  Some of the ones hosting large numbers of signed domains are:
>      -
>      -
>      -
>      - Amazon Route 53
>      -
>      -
>      -
> Many others, those are just some of the larger ones.
>> How long does it take for the typical domain name owner to sign their
>> RRs for the first time?
> With BIND 9.16, just add a policy to the zone definition.  A few
> seconds.
>> What's the ongoing commitment in time for a domain owner to maintain
>> DNSSEC for their RRs?
> None, BIND keeps the zone signed.  Of course wether you're signing or
> not, service monitoring is highly recommended, to check signature
> validity I use
>      named-compilezone -i local -jD -f raw -o - $zone $zonedb |
>          ldns-verify-zone -e P0Y0M3DT3H23M54S -V1 -S /dev/stdin
>> What's the immediate benefit to the signer from signing one's own RRs?
>> (Note: if nothing is verifying signatures, the immediate benefit is zero.)
> Since "nothing is verifying" is simply false, the benefit is that
> verification indeed takes place.  The strongest case is hardening
> of CAA records and TLSA records.  Soon also HTTPS and SVCB records,
> which have security-relevant information, worth hardining IMHO.
>> And how do we close these (and doubtless other) gaps?
> My zone has been signed since ~2014, no gaps to report, but for more
> complex environments work is being done to address
>      - multi-provider signing (Shumon Huque, et. al. doing great work)
>      - CDS support by registries and registrars, .CZ, .ZA, soon
>        Godaddy...
> We're not standing still, lots of good activity to close the gaps both
> new and longstanding.
>> I'd love for the Internet to be able to make better use of DNSSEC and to
>> need to rely less on PKI.  But for all that I love about this idea, I
>> don't think this is going to happen until most of these problems are fixed.
> That's why lots of work is happening to address the remaining adoption
> barriers.