[NCAP-Discuss] Root Zone Change Rates

[James Galvin]

Excellent additional details to include in our report.  I agree that we 
should not try to rank the risks, as both are important.  They are 
simply different risks.

With respect to DNSSEC, I have a recollection of at least one 
conversation where I remember us saying we should not sign the zones at 
this time, as a subjective point of view not a technical one.  
Personally, I would prefer we choose to sign because in general we 
should, although I’m not absolutely committed to it as I recognize 
that perhaps for now, operationally, it might be better to start without 
signing and seek to move to it as quickly as practicable.

I’ll support whatever our majority believes.

Jim


On 14 Sep 2023, at 10:25, Jeff Schmidt wrote:

> Thinking a little more about this on my second cup of coffee. The two 
> RZCR “types” present different risk profiles. One isn’t 
> “more” or “less” risky than the other – they’re just 
> different. More different than I initially thought. And they both 
> “grow” the root zone as measured in kilobytes.
>
> First entry into root (delegation to TRT):
> + Increases net size of root database
> + Likely fewer net records due to “research quality” delegation 
> (~2 NS)
> + Likely to add glue (~2 A, ~2 AAAA)
> + No DNSSEC? (*)
> + NSEC, RRSEC (+1 each)
>
> Re-delegation from TRT to Registry:
> + No new string added to root database
> + Likely to add glue (~4 A, ~4 AAAA)
> + Likely additional net records due to “production quality” 
> delegation (~4 NS)
> + DNSSEC (large records, most common error mode, ~2 DS)
> + NSEC, RRSEC (recalculated)
>
> There’s no free lunch here. Both types present risks. The root zone 
> “grows” during both types – in the first, it “grows” in 
> units of “database entries” (there’s a new TLD string) and 
> associated kilobytes. In the second, while there isn’t a new TLD 
> string, the root zone will still “grow” in records and kilobytes 
> due to addition of production quality records and DNSSEC.
>
> Jeff
>
> (*) Have we discussed signing these TRT delegations?
>
>
> From: NCAP-Discuss <ncap-discuss-bounces at icann.org> on behalf of Jeff 
> Schmidt via NCAP-Discuss <ncap-discuss at icann.org>
> Date: Thursday, September 14, 2023 at 8:27 AM
> To: James Galvin <galvin at elistx.com>, ncap-discuss at icann.org 
> <ncap-discuss at icann.org>
> Subject: Re: [NCAP-Discuss] Root Zone Change Rates
> Jim said:
>
>> 2. We all agree that root zone changes are serious business. Looking 
>> at
>> the two changes that will need to be done it is important to note 
>> that
>> only one of them, the first one, is related to the root scaling 
>> concerns.
>> It is that first change that will add the applied for TLD string to 
>> the root
>> zone. The second change is not an addition, it is changing existing
>> information. We need to separate these points of concern.
>
> Agree they are different. The first is adding the TLD, which is net 
> new entries into the root. The second is a re-delegation which 
> doesn’t change the size of the root, but represents a unit of work 
> for IANA-Verisign, requires review, and presents opportunity for 
> errors. The RSSAC report mentions a concern about “churn” (the 
> latter type) in addition to net size growth (the former type). Root 
> zone changes are not zero risk.
>
> Timing will get interesting in the 2030(?) round. Some applications 
> (existing Registry using pre-evaluated RSP) could go quite fast 
> because they need little to no 2012-style evaluation. While evaluation 
> was the long pole in 2012, these collisions and IANA/root scaling 
> limitations may be the long pole in future rounds. Which means there 
> will be additional scrutiny.
>
> Thanks,
> Jeff
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mm.icann.org/pipermail/ncap-discuss/attachments/20230914/e69714f6/attachment.html>