Re: [DNSSEC-Bootstrapping] Sharding?

[Brian Dickson <[e-mail]>]

On Tue, Oct 19, 2021 at 9:30 AM Steve Crocker <[e-mail]> wrote:

> 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.
>
>
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


>
> On Tue, Oct 19, 2021 at 9:05 AM Peter Thomassen <[e-mail]> wrote:
>
>> 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
>>
>> --
>> DNSSEC-Bootstrapping mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/dnssec-bootstrapping
>>
> --
> DNSSEC-Bootstrapping mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/dnssec-bootstrapping
>