Subject: [DNSSEC-Bootstrapping] Sharding?

From: Peter Thomassen <[email-masked]>
Date: Tue, 19 Oct 2021 15:05:32 +0200

Hi all,

In my other email, I mentioned an open question about the protocol format. Here you go.

So far, the owner name of the signaling record for example.co.uk hosted on ns1.provider.net is: example.hash(co.uk)._boot.ns1.provider.net

For a given second label such as hash(co.uk), the first label will indicate all the (bootstrappable) domains that the DNS operator manages under that ancestor.

In case of the .com zone, I can imagine this to be a number that is potentially very high. (The concern does not apply to the second label, as many domains will have the same ancestor.)

1.) Do you think that this will be a problem for anyone, such as at the scale of Cloudflare?
2.) If yes: What could be done about it?
	a. One migiation could be to synthesize signaling records ad hoc, but that requires auth support.
	b. Another way would be to introduce some kind of sharding (= splitting the first label into several, possibly based on a few hash digits).
	c. ...?

I am not sure this is really a problem at all, but an approach like 2.b) would be a protocol change, so it will be hard to do it later. That's why I'm interested in your opinions. (If nobody thinks this is a problem, we can close it right away.)

Cheers,
Peter

-- 
Like our community service? 💛
Please consider donating at

https://desec.io/

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

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

---

From: Steve Crocker <[email-masked]>
Date: Tue, 19 Oct 2021 12:27:48 -0400

Peter,

The sentence

For a given second label such as hash(co.uk), the first label will indicate
all the (bootstrappable) domains that the DNS operator manages under that
ancestor.

raises a question of nor only whether the number is too large but also how
frequently it changes.  How accurate does this have to be?  If it's
supposed to be completely accurate, this will likely be out of date very
quickly for a large domain.

Thanks,

Steve

On Tue, Oct 19, 2021 at 9:05 AM Peter Thomassen <[email-masked]> wrote:

> So far, the owner name of the signaling record for example.co.uk hosted
> on ns1.provider.net is: example.hash(co.uk)._boot.ns1.provider.net
>
> For a given second label such as hash(co.uk), the first label will
> indicate all the (bootstrappable) domains that the DNS operator manages
> under that ancestor.
>
> In case of the .com zone, I can imagine this to be a number that is
> potentially very high. (The concern does not apply to the second label, as
> many domains will have the same ancestor.)
>
>         b. Another way would be to introduce some kind of sharding (=
> splitting the first label into several, possibly based on a few hash
> digits).
>         c. ...?
>
> I am not sure this is really a problem at all, but an approach like 2.b)
> would be a protocol change, so it will be hard to do it later. That's why
> I'm interested in your opinions. (If nobody thinks this is a problem, we
> can close it right away.)
>
> Cheers,
> Peter
>
> --
> DNSSEC-Bootstrapping mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dnssec-bootstrapping
>

---

From: Brian Dickson <[email-masked]>
Date: Tue, 19 Oct 2021 11:10:34 -0700

I think the preferred model is to have the bootstrapping zone reflect only
pending bootstrap domains, i.e. that need to go secure but have not yet
gone secure.
Once a zone is securely delegated, the operator should remove the bootstrap
entries.
It is basically the same logic as CDS/CDNSKEY.
Thus, the size of a given operators bootstrap zone would reflect the rate
of new zones going secure, not the total number of zones that are secure.
(This scales really well for large and small operators, I believe.
Especially with automation involved.)

Brian

---

From: Peter Thomassen <[email-masked]>
Date: Wed, 20 Oct 2021 18:21:19 +0200

Hi Brian, Christian,

On 10/19/21 8:10 PM, Brian Dickson wrote:
> I think the preferred model is to have the bootstrapping zone reflect only pending bootstrap domains, i.e. that need to go secure but have not yet gone secure.
> Once a zone is securely delegated, the operator should remove the bootstrap entries.

I agree with your sentiment that the bootstrapping zone should only contain pending bootstrappable domains, and that records should be cleaned up once corresponding delegations have been secured. That's also what the draft is saying.

However, if the parental agent (registry/registrar) does not support the mechanism, bootstrapping records may remain in place more or less indefinitely, until the parent changes their mind (or DS records are provisioned manually). In that case, a large number of records could accumulate under certain hash(ancestor) labels.

Do DNS operators think this is a problem that needs to be addressed?

> It is basically the same logic as CDS/CDNSKEY.

Yeah. In fact, those may also stay for quite a while, but they are in different zones, and keeping them doesn't cause any harm.

> Thus, the size of a given operators bootstrap zone would reflect the rate of new zones going secure, not the total number of zones that are secure.
> (This scales really well for large and small operators, I believe. Especially with automation involved.)

The derivative of the bootstrapping zone's size reflects the rate of new zones going secure (assuming a constant set of zones), but the size itself also has a constant offset that reflects lack of support at the parent.

On a different note: What's your take on Steve's concern?

Thanks,
Peter

> Brian
> 
> On Tue, Oct 19, 2021 at 6:05 AM Peter Thomassen <[email-masked] <mailto:[email-masked]>> wrote:
> 
>     Hi all,
> 
>     So far, the owner name of the signaling record for example.co.uk <http://example.co.uk> hosted on ns1.provider.net <http://ns1.provider.net> is: example.hash(co.uk <http://co.uk>)._boot.ns1.provider.net <http://boot.ns1.provider.net>
> 
>     For a given second label such as hash(co.uk <http://co.uk>), the first label will indicate all the (bootstrappable) domains that the DNS operator manages under that ancestor.
> 
>     https://desec.io/ <https://desec.io/>
> 
>     deSEC e.V.
>     Kyffhäuserstr. 5
>     10781 Berlin
>     Germany
> 
>     [email-masked] <mailto:[email-masked]>
>     https://www.ietf.org/mailman/listinfo/dnssec-bootstrapping <https://www.ietf.org/mailman/listinfo/dnssec-bootstrapping>
> 
> 

https://desec.io/

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

---

From: Brian Dickson <[email-masked]>
Date: Wed, 20 Oct 2021 10:21:26 -0700

> quickly for a large domain.
I think that is a non-issue, or orthogonal to the purpose of the zone(s).
Each zone would be basically internally integrated by the DNS operator, as
a service for their customers.
Each zone would basically operate like a queue for a backlog of zones known
to be possible to go secure.
There are multiple steps in going secure, via bootstrap:

   - Generate keys and sign the zone
   - Publish records in bootstrap zone
   - Parental agent pulls record from bootstrap and adds secure delegation
   - Clean-up of processed records for now-secure domains

So there are two places where some latency or queueing are likely to
happen: signing to publishing; and publishing to consumption.

Each DNS operator will have its own operational practices and
infrastructure. Each operator would need to do its own thing, including
setting expectations for customers, and ensuring things continue to work.

The aggregate behavior is fine even if some DNS operators drop the ball
occasionally. The market forces exert influence, i.e. customers can switch
operators if they are not happy with the performance.

Brian

---

From: Nils Wisiol <[email-masked]>
Date: Thu, 21 Oct 2021 10:26:03 +0200

On Wed, 2021-10-20 at 18:21 +0200, Peter Thomassen wrote:
> However, if the parental agent (registry/registrar) does not support
> the mechanism, bootstrapping records may remain in place more or less
> indefinitely, until the parent changes their mind (or DS records are
> provisioned manually). In that case, a large number of records could
> accumulate under certain hash(ancestor) labels.
> 
> 
> 

In this light, I believe it could make sense to support a potentially
large number of bootstrapping records. Otherwise, DNS operators are
forced to keep track which zone is located at supporting parental
agents and what the security status of each zone is. While this may be
good practice, it could increase the adoption barrier. On the other
hand, if large bootstrapping zones are supported, DNS operators can
still choose to keep track of supporting parental agents and zone
security status, but do not have to.

This is at the cost of everyone implementing sharding (or some other
mechanism) that allows for larger zones.

Nils

-- 
deSEC e.V. · Kyffhäuserstr. 5 · 10781 Berlin · Germany

---

From: Peter Thomassen <[email-masked]>
Date: Fri, 22 Oct 2021 19:01:58 +0200

On 10/21/21 10:26 AM, Nils Wisiol wrote:
> agents and what the security status of each zone is.

DNS operators should still clean up bootstrapping records for zones that have been secured, to keep bulk processing via NSEC walks or XFRs of the bootstrap zone efficient.

Given that no operator voiced concerns over the bootstrapping zone size, while it was argued that the protocol scales well even without sharding, I observe that there is currently no support/demand for a sharding mechanism.

I am going to rework some of the draft until Monday (IETF 112 draft submission deadline), mainly to make it relate better to RFC 8078. I am not currently planning to consider sharding in this iteration; if someone feels that is a mistake, please let me know.

Thanks,
Peter

PS: In case demand for sharding should come up later within the WG, we can revisit this (and then also discuss questions like how to do it, whether it should be configurable etc.).

https://desec.io/

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

---

From: Peter Thomassen <[email-masked]>
Date: Mon, 25 Oct 2021 18:07:09 +0200

Hi all,

> I am going to rework some of the draft until Monday (IETF 112 draft submission deadline), mainly to make it relate better to RFC 8078. I am not currently planning to consider sharding in this itera…

FYI, here is the draft I am planning to submit tonight:

Text: https://desec-io.github.io/draft-thomassen-dnsop-dnssec-bootstrapping/draft-thomassen-dnsop-dnssec-bootstrapping-02.txt
HTML: https://desec-io.github.io/draft-thomassen-dnsop-dnssec-bootstrapping/draft-thomassen-dnsop-dnssec-bootstrapping-02.html

Feel free to comment / PR until 11pm UTC if anything needs correction.

Thanks,
Peter

https://desec.io/

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