Re: [DNSOP] Fwd: New Version Notification for draft-thomassen-dnsop-dnssec-bootstrapping-02.txt

Peter Thomassen <> Tue, 09 November 2021 00:29 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id BE70B3A0061; Mon, 8 Nov 2021 16:29:43 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -5.229
X-Spam-Status: No, score=-5.229 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, NICE_REPLY_A=-3.33, SPF_HELO_NONE=0.001, SPF_PASS=-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 uc9B_aLfihx8; Mon, 8 Nov 2021 16:29:39 -0800 (PST)
Received: from ( [IPv6:2a01:4f8:10a:1d5c:8000::8]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id B47583A0062; Mon, 8 Nov 2021 16:29:38 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed;; s=20170825; h=Content-Transfer-Encoding:Content-Type:In-Reply-To:MIME-Version :Date:Message-ID:Subject:From:References:Cc:To:Sender:Reply-To:Content-ID: Content-Description:Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc :Resent-Message-ID:List-Id:List-Help:List-Unsubscribe:List-Subscribe: List-Post:List-Owner:List-Archive; bh=LzJCG2K7Dj53D+pfPwZ79bH1os4WwDfe2AJZ1TCeElk=; b=DMhBsuS+dRlIv079tHUZ8oMIxS VyZUN/bbhIz24DTWZpdJeQ95/QkUQi08dIpbhdcbhfeOe+oOKUvUidBZQFgEWmJJm4DW3g0HqyDSA /BTbrtrcNUAY+iK4GZIv1hwJX8odUqzTVQzf180g7ZTQSdGcLRECfrY/Y4tvOwT+RDVG129wG0R3O x5bJAUnvcVrqmThVfkUqK7wG5sla9v667Se/2Y4yCJnWaNrVOOSLhntWF6K0AkDQP4nG//T9+Z+ow qiVpETWdOJWVLAMjDY8C+2/w2DjYISI4dRWjJ6sGuVRYcqm/LXOHuUNSN+D8Q9eo0W3hWXobi4Ucv YAKo+VXg==;
Received: from ([] helo=[]) by with esmtpsa (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from <>) id 1mkF15-0001TT-6Z; Tue, 09 Nov 2021 01:29:35 +0100
To: Paul Wouters <>
Cc: " WG" <>,
References: <> <> <>
From: Peter Thomassen <>
Message-ID: <>
Date: Tue, 09 Nov 2021 01:29:34 +0100
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.13.0
MIME-Version: 1.0
In-Reply-To: <>
Content-Type: text/plain; charset="utf-8"; format="flowed"
Content-Language: de-DE
Content-Transfer-Encoding: 8bit
Archived-At: <>
Subject: Re: [DNSOP] Fwd: New Version Notification for draft-thomassen-dnsop-dnssec-bootstrapping-02.txt
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: Tue, 09 Nov 2021 00:29:44 -0000

On 11/5/21 1:07 AM, Paul Wouters wrote:
> On Tue, 26 Oct 2021, Peter Thomassen wrote:
>> This draft introduces automatic bootstrapping of DNSSEC delegations. It uses an in-band method for DNS operators to publish information about the zones they host, per-zone and with authentication. With this protocol, DS provisioning can happen securely and without delay.
> I've read the draft, and it is an interesting idea. Some thoughts I had:
> - Is it really needed to do hashing? Do we really expect domain names to
>    hit the 63 or 255 limit ?

Regarding hitting length limits:

- IPv6 reverse DNS hostnames (under already have length 73.
   I wouldn't dare make a prediction about what kind of names could be
   introduced in the next decade (think of underscore labels for TLS
   identities, perhaps with other parameters encoded in front etc.).
   I'd rather be conservative on exhausting the available length limits.

Other technical considerations:

- Not hashing creates semantic collisions.  Practical example from our
   deployment at deSEC:  The list of delegations under is long
   and changes frequently, so we'd probably like to put bootstrapping
   records for children of into a separate zone.
   Without hashing, that zone would be<NS>.If we do
   that, then we can't use bootstrapping for itself, because<NS> would be an apex name.  This collides with the
   requirement that bootstrapping records MUST NOT occur at the apex
   (where they would signify *that* zone's own DS info).

- This problem generally occurs with public suffixes.  For example,
   when bootstrapping a TLD, you wouldn't be able to create a separate
   bootstrapping zone for its children.  Of course, that's an unlikely
   case, but I think the protocol should be agnostic about that.

- Clear datastructures simplify implementation (in my experience).
   Hashing leads to a very predictable data structure with always two
   labels in front of the underscore label.  Also, that label would be
   an ENT; all records live at the leaves of the tree.  This assumption
   cannot be made when the names are simply concatenated (see above).

- When bootstrapping a child with a private parent (e.g. in a corporate
   namespace), hashing the child's immediate ancestor gives a privacy
   benefit even when NSEC walking is allowed (for discovering pending
   bootstrappable names).  (Of course, the benefit is limited, and
   counterarguments similar to the ones against NSEC3 can be made.)

Are there any conceptual downsides of the hashed label that would
outweigh these points?

If not, then the draft should perhaps be more explicit about the above.

> - _boot seems too generic a name for this. _dsbootstrap would be better
>    and cause less clashing

Agreed, tracking here:

> - I would like to see some text on removing the records too once the
>    child gained its DS record.

There is text on that in the last paragraph on Section 4.1.  Should it
be expanded or moved to a more promiment place?

> - Should it be explicitly noted that in-bailiwick domains are not
>    supported?

I think that would be good. Tracking here:

> - It puts a constraint of the nameserver being in a zone that is DNSSEC
>    enabled. This is currently not required (though very often the case
>    anyway)

Yes, prevalence of that is surprisingly high (currently about 25% of
domains in the Tranco 1M toplist).  This protocol would be a reason to
increase that number, as are other protocols (such as parameters for
TLS between resolver and auth, as proposed elsewhere).

> In general, the problem is that we need to make it easier for the DNS
> hoster to enable DNSSEC when their customers are non-technical. I think
> this draft does properly extend RFC 8078 and even think this document
> could deprecate the "Accept after wait" method. However, I do think it
> should still impose a minimum length of publication before accepting,
> so that mistakes similar to the recent outage can be
> prevented. So change "accept after wait" to "verify, then accept after
> wait".

While I don't feel strongly, I wonder in how many cases somebody would
really look at that during that extra wait interval.  Also, CDS/CDNSKEY
processing already requires checking that updated DS records don't
break resolution.


Like our community service? 💛
Please consider donating at

deSEC e.V.
Kyffhäuserstr. 5
10781 Berlin

Vorstandsvorsitz: Nils Wisiol
Registergericht: AG Berlin (Charlottenburg) VR 37525