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 _boot.ns1.desec.io.
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 com._boot.ns1.desec.io, or
dedyn.io._boot.ns1.desec.io.

But then you are most certainly better of without hashing, because then
you can make a zone for each <tld>._boot.ns1.desec.io. Or when you see
that foo.tld is a generic domain too that is becoming too large, create
a zone for foo.tld._boot.ns1.desec.io.

Whereas with hashes, you just have an unpredictable flat <blob>._boot.ns1.desec.io 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 example.com on top of example.com._boot.ns1.server.name


In a way, this is just the same as me publishing www.example.com IN CDS [...]. No one will ever
ask for the record since there is no NS for www.example.com. 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.

/Christian

_______________________________________________
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Reply via email to