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 HYPERLINK "mailto:matthias@hudobnik.at"matthias@hudobnik.at HYPERLINK "http://www.hudobnik.at/"http://www.hudobnik.at HYPERLINK "https://twitter.com/mhudobnik"@mhudobnik 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 <HYPERLINK "mailto:at-large@icann.org"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.... Have a nice day! Best, Matthias ______________________________ Ing. Mag. Matthias M. Hudobnik FIP • CIPP/E • CIPT • DPO • CIS LA HYPERLINK "mailto:matthias@hudobnik.at"matthias@hudobnik.at http://www.hudobnik.at @mhudobnik _______________________________________________ At-Large mailing list -- HYPERLINK "mailto:at-large@icann.org"at-large@icann.org To unsubscribe send an email to HYPERLINK "mailto:at-large-leave@icann.org"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