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

Christian Elmerot <> Wed, 10 November 2021 13:18 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 2C6573A0FCB; Wed, 10 Nov 2021 05:18:57 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -5.429
X-Spam-Status: No, score=-5.429 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, NICE_REPLY_A=-3.33, SPF_PASS=-0.001, SPOOF_COM2OTH=0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (1024-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id iMQHbnx_Q-JF; Wed, 10 Nov 2021 05:18:52 -0800 (PST)
Received: from ( []) by (Postfix) with ESMTP id 0F9DB3A0FC5; Wed, 10 Nov 2021 05:18:51 -0800 (PST)
Received: from [] (unknown []) by (Postfix) with ESMTPSA id 01E6A1CA74; Wed, 10 Nov 2021 13:18:19 +0000 (UTC)
DKIM-Filter: OpenDKIM Filter v2.10.3 01E6A1CA74
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple;; s=mail; t=1636550300; bh=dv/8f8aGwEWqVoIRKBEZ3Avpi+zwksERCi3023KASYw=; h=Date:Subject:To:Cc:References:From:In-Reply-To; b=wLedACg5XR09VEsXlQnQa7HPxQrbOD9OiZyhmx9z9MZXzBONi2+ZfBtP4MbKui3TZ znQLhLfQS4AG1/cHtfat02qR6WWk4Nm6voTZ/EJ/fUph2gkKHIlZwVv8ij2JW+O9Bh s9cjghp64ISXs2FX7B1y87RT5EOUZ/WrQtsmjJ7M=
Message-ID: <>
Date: Wed, 10 Nov 2021 14:18:17 +0100
MIME-Version: 1.0
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:91.0) Gecko/20100101 Thunderbird/91.2.1
Content-Language: en-US
To: Paul Wouters <>, Peter Thomassen <>
Cc: Paul Wouters <>, " WG" <>,
References: <> <> <> <> <> <> <> <> <>
From: Christian Elmerot <>
In-Reply-To: <>
Content-Type: text/plain; charset="UTF-8"; format="flowed"
Content-Transfer-Encoding: 8bit
Archived-At: <>
Subject: Re: [DNSOP] [DNSSEC-Bootstrapping] 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: Wed, 10 Nov 2021 13:18:57 -0000

Coming a bit late to the discussion

On 2021-11-09 22:53, Paul Wouters wrote:
> On Tue, 9 Nov 2021, Peter Thomassen wrote:
>> Let's consider the bootstrapping namespace under
>> There would usually be NS/DS records at this name.
>> However, it should be possible to introduce zone cuts underneath that
>> name, so operators can control the size and churn of the zones involved
>> in bootstrapping.  This idea madeit into the draft based on feedback
>> by John Levine, who pointed out that scalability should be a very
>> strong priority.
>> So, there may be additional NS/DS rrsets at, or
> But then you are most certainly better of without hashing, because then
> you can make a zone for each <tld> Or when you see
> that foo.tld is a generic domain too that is becoming too large, create
> a zone for
> Whereas with hashes, you just have an unpredictable flat 
> <blob> zone.

<implementer hat on>
Without hashing involved it would be possible to delegate the 
bootstrapping zone(s) to a live service. Hashing requires 
precomputation, which would detract and delay implementation. It would 
be simple to map on top of

> In a way, this is just the same as me publishing IN 
> CDS [...]. No one will ever
> ask for the record since there is no NS for So there is
> no way for "current deployed software" to do anything wrong. In your
> document, you could simply say "no bootraps are allowed under a _boot"
> delegation.

I agree. This would be a clarification of CDS/CDNSKEY records since this 
work is already adding additional use of the records beyond 
child->parent signalling.

> We disagree. I think the boostrap should only extend the validation path
> from a parent zone to the child zone. It should not try to skip a
> zonecut in the hierarchy. Yes this causes a delay to deploy, but you
> need some delay for security anyway and people won't be deploying 7
> delegations deep dnssec bootstraps, or if they do, a 7*1 day delay is
> fine.

I agree.

> I don't think it helps scaling either because large zones are pretty
> trivial these days and all these records are fairly short lived
> (days). I doubt we will see 60M of these on 1 nameserver. Can you (or
> John) explain what you think is the scale that would no longer work on
> a DNSSEC system? And how would that scaling compare to the CPU/disk
> required to generate new DNSKEYs for all those new DNSSEC domains,
> signing the domains and creating CDNSKEY/CDS records for them?

I'd like to think that any such a large number would be easiest served 
by a "live" non-hashed implementation. Adding delegations is far messier

> I think it only helps prevent hitting the theoretical but non-real
> FQDN limit of 255, but as I said before, anything that prepends an
> _underscore prefix will always have a limit under 255. Not using hashes
> would reduce the max length to 128 minues the _boot prefix length versus
> 255 - 64 (length of base64(sha256)) - _boot prefix length.  So more or
> less reduce support of FQDNs from ~200 to ~128. This already requires a
> minimum of 3 subdelegations, but since most TLDs dont exceed ~10 to
> ~20, would require 4+ delegations. At which point you should really be in
> part of the DNS tree where you control all parties to provision zones
> without needing the bootstrap, that is mainly aimed at Registrar - DNS
> Operator limitations. Eg you would be using catalog zones with your
> nameservers that would be able to do CDS -> DS because of existing XFR
> or NSUPDATE based trust relationships, or would even run on the same
> nameserver to completely automated DS updates when hosting both child
> and parent.
> Anyway, just to reflect, I _do_ like and this idea, but strongly 
> prefer no
> hashing and not using it to go two delegations deep over unsigned 
> parents.

Hashing complicates matters more than the issue it solves. A quick (but 
not exhaustive) check suggests that none of the zones we (Cloudflare) 
would be using this for would be affected. It also complicates 
implementations and debugging for all zones while solving the 
bootstrapping issue for a minute number of zones with long names.