Duane, It isn’t so much that I find the report lacking, rather in my mind, it raises the question of whether the goal of RSSAC-001 E.3.6-A to "assure the community that the RSOs take implementation diversity seriously and provide a collective view of implementation choices within the root server system” is realistic/feasible given the current structure of the RSS. In a quick search related to RSSAC-001, I see https://root-servers.org/rssac001/ has had four reports, two by Verisign, one by Netnod and ICANN respectively (maybe there are others not on that site?), posted since RSSAC-001 came out in Dec 2015 (ICANN’s says theirs is a living document, but it doesn’t have a change log so it’s difficult to determine how frequently it has been updated). While having a periodically published aggregated report is likely preferable to (in theory) twelve different reports, (IMHO) none of those reports or the report you just published provides sufficient detail (Netnod’s, explicitly so) to derive any (additional) assurance related to diversity of implementation — in fact, it might raise more questions/concerns than it answers. I suspect I’m aware of (some of) the perhaps intractable challenges in implementation of E.3-6-A. While I appreciate the intent and effort, without information related to (at least) distribution of technology diversity, this feels a bit like a box checking exercise. But perhaps that’s just me. Regards, -drc

On Apr 16, 2025, at 5:16 PM, Wessels, Duane <dwessels@verisign.com> wrote:

Hi David,

Thanks for the feedback.

As you probably know already, technical diversity is something the RSOs have long discussed internally, but this is the first time providing a public report. In going through the process the group discussed the right level of detail to provide and ended up settling on a high-level and simple approach that everyone could agree to for the first report.

I understand from your message that you find it lacking. I am happy to take that feedback to the group as input to the next technical diversity report that comes out.

DW

...

On Apr 15, 2025, at 11:41 AM, David Conrad <david.conrad@layer9.tech <mailto:david.conrad@layer9.tech>> wrote:

Duane,

Thanks for this. In that document, I note the following:

"Information presented here is a result of that analysis and has been aggregated across all RSOs with no attempt to convey the relative distribution of each technology."

Given this, I’m unsure of the value of this report or how exactly it helps "assure the community that the RSOs take implementation diversity seriously” (from RSSAC-001v2). Without any knowledge of the distribution of the various components mentioned, how is the community to derive any assurance that (to take absurd scenarios) all RSOs but one isn’t running (say) NetBSD, the vast majority of DNS queries aren't handled by (say) Atlas, the majority of all root server traffic isn't routed through (say) CVE-2025-21590 vulnerable JunOS, etc.

Thanks, -drc

...

On Apr 11, 2025, at 12:17 PM, Wessels, Duane via rssac-caucus <rssac-caucus@icann.org> wrote:

Expectation E.3.6-A of RSSAC001v2 says: The RSOs are expected to collectively publish aggregated implementation diversity reports from time-to-time.

I’m pleased to say that this has been done and you can read the report at https://secure-web.cisco.com/1kF-clvN23gJEwalfliUqIprJYpYKqLxZq4GcS1184XFE6I...

DW

_______________________________________________ rssac-caucus mailing list -- rssac-caucus@icann.org <mailto:rssac-caucus@icann.org> To unsubscribe send an email to rssac-caucus-leave@icann.org <mailto:rssac-caucus-leave@icann.org>

_______________________________________________ By submitting your personal data, you consent to the processing of your personal data for purposes of subscribing to this mailing list accordance with the ICANN Privacy Policy (https://secure-web.cisco.com/1-puFXaQ-M64Mow3LWDf7CwO-bcieZ94Wfgb0Mt_LEKPJuS...) and the website Terms of Service (https://secure-web.cisco.com/1-cMWIU8lt_xBpSjjc7WLocnAkBE8sleNAmtnbh2WpWIKm5...). You can visit the Mailman link above to change your membership status or configuration, including unsubscribing, setting digest-style delivery or disabling delivery altogether (e.g., for a vacation), and so on.

Hi Ray, Thanks. Interestingly, Cloudflare’s proprietary DNS server isn’t among the four name server implementations listed in the 2025 Technical Diversity Report. Out of curiosity, is there some reason there isn’t a link to that report (or the report isn’t published) on https://root-servers.org/ rssac001/? Regards, -drc

On Apr 17, 2025, at 11:11 AM, Ray Bellis via rssac-caucus <rssac-caucus@icann.org> wrote:

On 17/04/2025 19:06, David Conrad via rssac-caucus wrote:

...

In a quick search related to RSSAC-001, I see https://root-servers.org/ rssac001/ <https://root-servers.org/rssac001/> has had four reports, two by Verisign, one by Netnod and ICANN respectively (maybe there are others not on that site?),

https://www.isc.org/docs/isc-froot-rssac001.pdf

Ray

_______________________________________________ rssac-caucus mailing list -- rssac-caucus@icann.org To unsubscribe send an email to rssac-caucus-leave@icann.org

_______________________________________________ By submitting your personal data, you consent to the processing of your personal data for purposes of subscribing to this mailing list accordance with the ICANN Privacy Policy (https://www.icann.org/privacy/policy) and the website Terms of Service (https://www.icann.org/privacy/tos). You can visit the Mailman link above to change your membership status or configuration, including unsubscribing, setting digest-style delivery or disabling delivery altogether (e.g., for a vacation), and so on.

On Thu, 17 Apr 2025 11:06:18 -0700, David Conrad via rssac-caucus wrote:

It isn’t so much that I find the report lacking, rather in my mind, it raises the question of whether the goal of RSSAC-001 E.3.6-A to "assure the community that the RSOs take implementation diversity seriously and provide a collective view of implementation choices within the root server system” is realistic/ feasible given the current structure of the RSS.

In a quick search related to RSSAC-001, I see https://root-servers.org/rssac001/ has had four reports, two by Verisign, one by Netnod and ICANN respectively (maybe there are others not on that site?), posted since RSSAC-001 came out in Dec 2015 (ICANN’s says theirs is a living document, but it doesn’t have a change log so it’s difficult to determine how frequently it has been updated). While having a periodically published aggregated report is likely preferable to (in theory) twelve different reports, (IMHO) none of those reports or the report you just published provides sufficient detail (Netnod’s, explicitly so) to derive any (additional) assurance related to diversity of implementation — in fact, it might raise more questions/concerns than it answers.

I suspect I’m aware of (some of) the perhaps intractable challenges in implementation of E.3-6-A. While I appreciate the intent and effort, without information related to (at least) distribution of technology diversity, this feels a bit like a box checking exercise. But perhaps that’s just me.

David, thanks for the feedback. I suspect it will prompt multiple RSOs to review and update their reporting. I've already seen some changes on https://root-servers.org/rssac001/ There is an important aspect that I think your note doesn't fully reflect: There is a REAL TRADE-OFF between how many operational details RSOs provide to help the community understand its diversity and robustness, and how much those details help potential adversaries. (For example, I don't think we will be asking RSOs to share their passwords so we can ensure they sufficiently diverse!) The threshold one prefers for this trade-off is something about which different technical people will reasonably disagree. I hope the community will recognize the _RSS 2025 Technical Diversity Report_ as progress, even if it's not everything you hope for. And, just speaking personally, for me, the statement that a diversity report is useless without a distribution feels a bit extreme. While knowing 48.4% of servers run bind-9.18.36 might answer some very specific questions, such a factoid would be out of date tomorrow. But to try and directly address your question: If one wanted a bounds on the distribution, it seems fair to assume that at least one RSO operators one of each of the configurations given in the report. Would something like that statement address some of your concern? If so, perhaps a future report will reflect this discussion and be at least that specific. -John ("starts with pass...", wait wait) Heidemann

Regards, -drc

On Apr 16, 2025, at 5:16 PM, Wessels, Duane <dwessels@verisign.com> wrote:

Hi David,

Thanks for the feedback.

As you probably know already, technical diversity is something the RSOs have long discussed internally, but this is the first time providing a public report. In going through the process the group discussed the right level of detail to provide and ended up settling on a high-level and simple approach that everyone could agree to for the first report.

I understand from your message that you find it lacking. I am happy to take that feedback to the group as input to the next technical diversity report that comes out.

DW

On Apr 15, 2025, at 11:41 AM, David Conrad <david.conrad@layer9.tech> wrote:

Duane,

Thanks for this. In that document, I note the following:

"Information presented here is a result of that analysis and has been aggregated across all RSOs with no attempt to convey the relative distribution of each technology."

Given this, I’m unsure of the value of this report or how exactly it helps "assure the community that the RSOs take implementation diversity seriously” (from RSSAC-001v2). Without any knowledge of the distribution of the various components mentioned, how is the community to derive any assurance that (to take absurd scenarios) all RSOs but one isn’t running (say) NetBSD, the vast majority of DNS queries aren't handled by (say) Atlas, the majority of all root server traffic isn't routed through (say) CVE-2025-21590 vulnerable JunOS, etc.

Thanks, -drc

On Apr 11, 2025, at 12:17 PM, Wessels, Duane via rssac-caucus <rssac-caucus@icann.org> wrote:

Expectation E.3.6-A of RSSAC001v2 says: The RSOs are expected to collectively publish aggregated implementation diversity reports from time-to-time.

I’m pleased to say that this has been done and you can read the report at https://secure-web.cisco.com/1kF-clvN23gJEwalfliUqIprJYpYKqLxZq4GcS1184XFE6I...

DW

_______________________________________________ rssac-caucus mailing list -- rssac-caucus@icann.org To unsubscribe send an email to rssac-caucus-leave@icann.org

_______________________________________________ By submitting your personal data, you consent to the processing of your personal data for purposes of subscribing to this mailing list accordance with the ICANN Privacy Policy ( https://secure-web.cisco.com/1-puFXaQ-M64Mow3LWDf7CwO-bcieZ94Wfgb0Mt_LEKPJuS... ) and the website Terms of Service ( https://secure-web.cisco.com/1-cMWIU8lt_xBpSjjc7WLocnAkBE8sleNAmtnbh2WpWIKm5... ). You can visit the Mailman link above to change your membership status or configuration, including unsubscribing, setting digest-style delivery or disabling delivery altogether (e.g., for a vacation), and so on. _______________________________________________ rssac-caucus mailing list -- rssac-caucus@icann.org To unsubscribe send an email to rssac-caucus-leave@icann.org

_______________________________________________ By submitting your personal data, you consent to the processing of your personal data for purposes of subscribing to this mailing list accordance with the ICANN Privacy Policy (https://www.icann.org/privacy/policy ) and the website Terms of Service (https://www.icann.org/privacy/tos ). You can visit the Mailman link above to change your membership status or configuration, including unsubscribing, setting digest-style delivery or disabling delivery altogether (e.g., for a vacation), and so on.

After spending a significant number of years thinking about how to describe the diversity of the RSS, I find myself walking away quickly from the current approach. (Having an air gap has probably helped that!) It doesn't matter how many OS's or hardware types are used. Each and every unique item across the entire ecosystem is important from network card, to bios, to cpu, to OS version/release, to switch, router, management code (puppet, anisible, teraform etc), and nameserver software version (get the idea?) When you can count every unique component in the entire RSS ecosystem, yes, all RSO's should participate to the single dataset (perhaps on a census date - this can be automated surely!) and use a uniform methodology to establish a diversity index, I think that alone will be a more useful indicator for the 'diversity provides resiliency' narrative. (and provided the methodology is published, the per RSO details are then much less important) Maybe think about using the ecological diversity indices such as Shannon, Simpson's, or Margalef's. (all solid mathematical approaches used outside of tech) In fact, I would suggest that the diversity index is only part of the story, it's the longer baseline of an annually recorded index that could be then discussed in whatever governance framework eventuates. Great questions can then be asked about variations in the diversity index (up, down, same) set against observed resiliency of the RSS, performance, cost .. etc Cheers, Terry -- Mobile device, don't expect grammar.

On 22 Apr 2025, at 9:32 am, David Conrad via rssac-caucus <rssac-caucus@icann.org> wrote:

Hi John,

Thanks for the response.

...

On Apr 21, 2025, at 1:41 PM, John Heidemann <johnh@isi.edu> wrote: David, thanks for the feedback. I suspect it will prompt multiple RSOs to review and update their reporting. I've already seen some changes on https://root-servers.org/rssac001/

Yep. Good to see the additional participation.

...

There is a REAL TRADE-OFF between how many operational details RSOs provide to help the community understand its diversity and robustness, and how much those details help potential adversaries.

To be honest, I was a bit surprised at the level of info that was provided in the report. For example, for the purposes of evaluating diversity, while it is obviously important that it is noted that 3 different OSes are being used, what those specific OSes are would seem to me to be only of limited value and would provide hints to potential attackers. Of course, the counter argument is that in an Internet full of continuous background radiation of automated anonymous probes of pretty much every CVE ever published, not publishing OSes is just a form of attempted security by obscurity but that’s a separate issue.

Speaking personally, I’d think it’d be sufficient to say something like:

OS A: 15% of all root server instances OS B: 47% of all root server instances OS C: 33% of all root server instances Other: 15% of all root server instances

I.e., there’s no need to get into what OS A, B, C, and “other" are in a public report (although they could be mentioned without the mapping to A, B, C), just that those OSes are different (perhaps in the future, a report to the RSS Governance Structure could provide a higher level of detail if there’s interest?)

...

I hope the community will recognize the _RSS 2025 Technical Diversity Report_ as progress, even if it's not everything you hope for.

I agree it is a good start — apologies if my input was taken to suggest otherwise.

...

And, just speaking personally, for me, the statement that a diversity report is useless without a distribution feels a bit extreme. While knowing 48.4% of servers run bind-9.18.36 might answer some very specific questions, such a factoid would be out of date tomorrow. But to try and directly address your question: If one wanted a bounds on the distribution, it seems fair to assume that at least one RSO operators one of each of the configurations given in the report.

Personally, I’d think it would be of significant interest to most if 48.4% of root server instances one day stopped responding to queries due to (say) a packet of death.

The point I was trying to make is that without distribution information, it is difficult if not impossible for “interested members of the community” to gain assurance that they aren’t at risk of delay/loss of root resolution due to a PoD (or whatever), which is what I assume is the point of the diversity report. Saying “at least one RSO” is running X (which presumably isn’t vulnerable to the PoD) doesn’t provide that assurance since it _could_ mean exactly one RSO has a box running X in the bottom of a locked filing cabinet stuck in a disused lavatory with a sign on the door saying 'Beware of the Leopard”.

But perhaps I have the wrong assumption about the intent of the diversity report.

Regards, -drc

_______________________________________________ rssac-caucus mailing list -- rssac-caucus@icann.org To unsubscribe send an email to rssac-caucus-leave@icann.org

_______________________________________________ By submitting your personal data, you consent to the processing of your personal data for purposes of subscribing to this mailing list accordance with the ICANN Privacy Policy (https://www.icann.org/privacy/policy) and the website Terms of Service (https://www.icann.org/privacy/tos). You can visit the Mailman link above to change your membership status or configuration, including unsubscribing, setting digest-style delivery or disabling delivery altogether (e.g., for a vacation), and so on.