Hi Matthias Just read this. Many thanks for bringing it to our attention. Many of us have been advocating for FOSS for various applications, ever since its emergence as a distinct mode of software co-production, distribution, maintenance, and use. SAC132 brings out the role of FOSS specifically in the context of the DNS--a role that is often invisible and unacknowledged. Thanks again to SSAC for highlighting this role. It would be very useful if this document--and in particular sections #6 and #7--is shared widely with different communities around the world, as it has the potential to support FOSS advocates and activists who are fighting lonely battles for FOSS in their own contexts. With kind regards satish -- Satish Babu Member, ALAC Chair, Software Freedom Law Centre India (https://sflc.in) On Fri, Oct 3, 2025 at 9:35 AM Matthias M. Hudobnik via ALAC <alac@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
matthias@hudobnik.at
@mhudobnik _______________________________________________ ALAC mailing list -- alac@icann.org To unsubscribe send an email to alac-leave@icann.org
At-Large Online: http://www.atlarge.icann.org ALAC Working Wiki: https://community.icann.org/display/atlarge/At-Large+Advisory+Committee+(ALA...) _______________________________________________ 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.