Barrack, gladly!
It will also be presented at ICANN84 in various cross-community sessions, including ALAC/SSAC.
Have a nice evening!
Best,
Matthias
________________________________
Ing. Mag. Matthias M. Hudobnik
FIP • CIPP/E • CIPT • DPO • CIS LA
Von: Barrack Otieno [mailto:otieno.barrack@gmail.com]
Gesendet: Freitag, 03. Oktober 2025 09:23
An: Matthias M. Hudobnik
Cc: At-Large Worldwide
Betreff: Re: [At-Large] SSAC has published SAC132: The Domain Name System Runs on Free and Open Source Software (FOSS)
Many thanks Matthias,
Interesting feedback on the role of FOSS
Thank you
On Fri, Oct 3, 2025 at 7:07 AM Matthias M. Hudobnik via At-Large <at-large@icann.org> wrote:
Hi colleagues, the SSAC has published SAC132.
### SSAC has published SAC132: The Domain Name System Runs on Free and Open Source Software (FOSS):
Overview
• The Domain Name System (DNS) is critical infrastructure, mapping names to IP addresses for nearly all online activity.
• Research confirms the DNS overwhelmingly relies on FOSS.
o 9 of 12 root server operators use FOSS exclusively.
o 9 of the 10 largest TLD providers use FOSS.
• FOSS dominance comes from its economic efficiency, transparency, collaborative security, and resilience.
• FOSS is not inherently more or less secure than proprietary software; outcomes depend on processes and maintenance.
• However, the FOSS development model differs fundamentally from proprietary supply chains, raising unique risks.
1. Introduction
• Policymakers are increasingly intervening in software security (UK voluntary code, US attestation, EU Cyber Resilience Act and NIS2, China’s IT plan).
• Risk: regulations designed for proprietary models may harm critical Internet infrastructure if applied to FOSS without adaptation.
• Aim: provide context to policymakers to recognize FOSS’s role and avoid destabilizing interventions.
2. DNS Primer
• DNS = “address book of the Internet.”
• Functions:
o Registration: registries manage the authoritative database of domain names.
o Publication: authoritative servers publish DNS records.
o Resolution: resolvers fetch IP addresses for users.
• Structure: Root → TLDs → individual domains.
• Resolvers answer ~90% of queries from cache; authoritative servers publish definitive records.
3. The FOSS Model: Characteristics and Implications
• Key roles:
o Maintainers: guide project direction.
o Contributors: submit code/docs/bug fixes.
o Operators: deploy and run software.
• Four freedoms: use, study, share, change.
• Unique characteristics:
o Global collaborative development.
o No contractual relationships.
o Funding decoupled from use.
o Often no single responsible legal entity.
• Proprietary systems also depend on FOSS components.
• Strengths:
o Transparency & collaborative security .
o Stability & long-term support by non-profits/companies.
o Resilience via software diversity.
o Enabler of innovation and digital autonomy.
• Risks :
o Financial sustainability & maintainer burnout.
o Shared dependency risks.
o No warranties or support guarantees.
o Operational risks in deployment.
4. Prevalence of FOSS in DNS
• Registration: Platforms like FRED, Nomulus, CoCCA widely used. Large registries use proprietary extensions but built atop FOSS.
• Publication: Root and TLD servers overwhelmingly use FOSS. 9 of 12 root operators rely on FOSS.
• Resolution: BIND, Unbound, Knot Resolver, CoreDNS common. ISPs, enterprises, and cloud resolvers widely deploy FOSS.
5. Contemporary Cases in FOSS Regulation
• Policymakers are adapting rules to reflect FOSS realities.
• Examples:
o US 2023 Cybersecurity Strategy: exempts volunteer maintainers; responsibility on deployers.
o UK 2025 Code of Practice: voluntary guidance.
o EU CRA/NIS2: introduces “FOSS steward” role, avoids treating maintainers as suppliers, harmonizes obligations.
• Policy lessons:
1. Allocate responsibility to those best able to act.
2. Incentivize cross-industry collaboration on maintenance.
3. Avoid supply chain assumptions based on proprietary models.
4. Avoid conflicting regional obligations.
6. Key Findings
1. FOSS is the foundation of DNS; proprietary is the exception.
2. FOSS model is fundamentally different from proprietary software supply chains.
3. FOSS is not inherently more/less secure; security depends on processes.
4. DNS FOSS strengths: transparency, collaborative security, diversity, long-term stability.
5. Risks: sustainability, burnout, shared dependencies — not solvable by proprietary regulations.
6. Traditional liability is ill-suited: imposing burdens risks discouraging maintainers and harming infrastructure.
7. FOSS enables autonomy and innovation: lowers entry barriers, supports local industry, diversifies markets, reduces cloud dependence.
7. Actionable Guidelines for Policymakers
1. Acknowledge the Critical Role of FOSS
o Explicitly recognize in law/regulation that critical infrastructure depends on FOSS; treat it as a strength to preserve.
2. Consult the FOSS Community
o Engage maintainers, contributors, non-profits, and companies in policymaking.
3. Make Use of Contemporary Cases
o Apply lessons: responsibility on deployers not maintainers, support FOSS steward models, avoid proprietary assumptions, prevent conflicting regional regimes.
4. Incentivize FOSS Sustainability
o Promote public/private funding of critical FOSS projects as investments in shared goods.
5. Address Systemic Risks Collectively
o Fund ecosystem-wide resilience (dependency tooling, research, security initiatives) instead of overburdening individuals.
Conclusion
The SSAC concludes:
• The DNS runs on FOSS, a global public good central to Internet stability.
• Policymakers must avoid treating FOSS with proprietary assumptions.
• Following the five guidelines — acknowledge, consult, learn, incentivize, collaborate — ensures security and sustainability of DNS and the Internet as a whole.
Link to the report: https://itp.cdn.icann.org/en/files/security-and-stability-advisory-committee-ssac-reports/sac132-25-09-2025-en.pdf.
Have a nice day!
Best,
Matthias
______________________________
Ing. Mag. Matthias M. Hudobnik
FIP • CIPP/E • CIPT • DPO • CIS LA
@mhudobnik
_______________________________________________
At-Large mailing list -- at-large@icann.org
To unsubscribe send an email to at-large-leave@icann.org
At-Large Official Site: http://atlarge.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.
--
Barrack O. Otieno
+254721325277
+254733206359
Skype: barrack.otieno
PGP ID: 0x2611D86A