Re: [DNSOP] IETF meeting prep and what

Vladimír Čunát <> Wed, 23 June 2021 16:28 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 308163A3CEA for <>; Wed, 23 Jun 2021 09:28:15 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.238
X-Spam-Status: No, score=-2.238 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, NICE_REPLY_A=-0.338, 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 PccnbXA3zkeM for <>; Wed, 23 Jun 2021 09:28:12 -0700 (PDT)
Received: from ( [IPv6:2001:1488:800:400::400]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 176183A3CE7 for <>; Wed, 23 Jun 2021 09:28:11 -0700 (PDT)
Received: from [IPv6:2a02:768:2d1c:226::a2e] (unknown [IPv6:2a02:768:2d1c:226::a2e]) by (Postfix) with ESMTPSA id C654D140A03 for <>; Wed, 23 Jun 2021 18:28:04 +0200 (CEST)
References: <> <>
From: Vladimír Čunát <>
Message-ID: <>
Date: Wed, 23 Jun 2021 18:28:04 +0200
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.11.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
X-Virus-Scanned: clamav-milter 0.102.2 at mail
X-Virus-Status: Clean
Archived-At: <>
Subject: Re: [DNSOP] IETF meeting prep and what
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: IETF DNSOP WG mailing list <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Wed, 23 Jun 2021 16:28:15 -0000

On 18/06/2021 19.40, Peter van Dijk wrote:
> aname can go; I trust the WG feels SVCB will supersede it.

Yes, please.

> I propose replacing rfc5011-security-considerations with a short document deprecating 5011 in its entirety. I am happy to write text for that, if there is an appetite - when the WG queue is small enough!

I agree that 5011 doesn't seem really useful (anymore).

We have it in Knot Resolver but recommend not to use it, because it's 
just more trouble than worth in practice.  Notably, (all) resolver 
software needs much more frequent updates than the rate of root KSK 
rollovers, so it's easier to distribute root DS within the updates; some 
Linux distros even package these separately and share them among 
different resolver packages.  Even if you're conservative and use BIND 
ESV or similar, I believe it's a better approach than 5011.  For 
non-root keys there doesn't seem much point nowadays, as getting a chain 
from root is better.

(By the way, an "interesting" example: router with DNSSEC validation and 
factory reset / rollback, commonly shelved for a year, unreliable clock,