October 2025 - At-Large - lists.icann.org

SAC130: SSAC Comments on Name Collision Guidelines in the Proposed Language for the Draft Next Round Applicant Guidebook
by Matthias M. Hudobnik April 24, 2026

April 24, 2026

Dear Colleagues, The SSAC welcomes the opportunity to comment on ICANN's Draft Applicant Guidebook (AGB) for the New gTLD Program: Next Round. Our comments focus on improving Section 6.7 on Name Collisions, with an emphasis on risks arising from collisions between DNS and alternative naming systems (e.g., blockchain-based systems), as outlined in the Name Collision Analysis Project Study 2 Report (NCAP2). SUMMARY OF KEY RECOMMENDATIONS: * Clarify TRT's Role in Initial Assessments AGB §6.7.2 does not clearly state that the Technical Review Team (TRT) conducts the initial name collision risk assessment. NCAP2 indicates TRT is responsible from the outset. _Recommendation:_ Explicitly assign the initial assessment to the TRT. * Enable Pre-Delegation Action on High-Risk Strings Current language suggests high-risk strings are identified only after temporary delegation. NCAP2 supports action based on existing data. _Recommendation:_ Allow TRT to recommend withholding delegation if early analysis shows high risk. * Broaden TRT's Assessment Scope Beyond DNS Data Limiting analysis to DNS logs misses collisions from alternative namespaces that resolve via DNS (e.g., users accustomed to _.wallet_ from blockchain). _Recommendation:_ Permit use of OSINT, qualitative assessments, and external data sources per NCAP2. * Allow TRT Flexibility to Evolve Assessment Methods AGB cites four NCAP2 methods (NI, CI, VI, VIN), but doesn't state whether TRT may adopt new techniques. _Recommendation:_ Affirm TRT's discretion to evolve methods to address future risks. These updates will better align the AGB with NCAP2 and ICANN Board guidance, while improving transparency, security, and technical rigor in handling name collisions. The SSAC appreciates the efforts of the ICANN org and Subsequent Procedures IRT, and we are available for further discussion. Link: https://itp.cdn.icann.org/en/files/security-and-stability-advisory-committe…. Best, Matthias

1 1

Congratulations to Alfredo Calderón
by Justine Chew Nov. 3, 2025

Nov. 3, 2025

In case anyone has not picked up on this bit of news https://www.icann.org/en/announcements/details/alfredo-caldern-honored-with… Our newly appointed NextGen Mentor for ICANN85 - ICANN82, Alfredo Calderón has been awarded the 2025 Dr Tarek Kamel for Capacity Building. Congratulations, Alfredo! Kind regards, Justine ---------

18 21

Summary of the Amazon DynamoDB Service Disruption in Northern Virginia (US-EAST-1) Region
by Olivier MJ Crépin-Leblond Oct. 27, 2025

Oct. 27, 2025

AWS has published its summary of the Summary of the Amazon DynamoDB Service Disruption in Northern Virginia (US-EAST-1) Region which made the headlines on 20 October 2025: https://www.bbc.co.uk/news/articles/cev1en9077ro "...why did it make the internet fall apart" Perhaps the most surprising part of the reporting is how much noise was made about it, at least in the UK, sometimes equating to impending hyped doom reports of the "death of the net predicted" and mixing into a it a good measure of "it's always a DNS problem...". I'll spare you the links to the articles, just search for them on a search engine. What's more interesting is the actual AWS summary which they have published: https://aws.amazon.com/message/101925/ Having been around for long enough to have seen the 'net grow over the years, the first thing that struck me is the complexity of these cloud networks that now form most of the Internet. No longer is this just a simple server -> client scenario with a handful of routers and TCP/IP. The way by which the Heart of today's world works, aka the "back end" to all of our Apps and Web sites is way more complicated than I ever imagined. Yes, one of my companies is an AWS customer so I wasn't a total novice into the AWS instances, NLB, EC2 and Route 53. But the process by which this all works (supposedly like clockwork and sometimes not) surpassed my imagination. And this is where I discovered the "seamless scale" whereas you can keep track of the whole ecosystem of virtual machine instances and load balancers using a constantly updated dynamic DNS. I frankly do not know how to give it a name, but the times of manually inputting listings into a file at /var/named/data/example.hosts is long gone! So here's my question: is the DNS fit for purpose for the use AWS is making of it? I wonder whether we could ask if anyone on the SSAC could explain this to us in a few minutes during the ALAC meeting with the SSAC on Sunday? Kindest regards, Olivier

5 9

Vienna
by Roberto Gaetano Oct. 25, 2025

Oct. 25, 2025

Hi Matthias Will you be in Vienna in the first half of December? Cheers, Roberto

1 0

String Similarity Data for top-level domains, available for Public Comment
by Satish Babu Oct. 25, 2025

Oct. 25, 2025

Dear all Please see the message below on the availability of Unicode-based String Similarity Data, to be used for identifying similar top-level strings, for public comments. The public comment is open until 4 Dec 2025. With kind regards satish ---------- Forwarded message --------- From: Sarmad Hussain <sarmad.hussain(a)icann.org> Date: Sat, Oct 25, 2025 at 11:19 AM Subject: Public comment on String Similarity Data for top-level domains To: Satish Babu <sbabu(a)ieee.org> Cc: Heidi Ullrich <Heidi.Ullrich(a)icann.org> Dear Satish, Following up on discussion right now, please note that ICANN has recently developed the string similarity data <https://www.icann.org/sites/default/files/packages/lgr/sse/sse-data-overvie…> (Section 3) based on Unicode characters to help identify similar strings in top-level domain applications. This has been published for public comment <https://www.icann.org/en/public-comment/proceeding/string-similarity-evalua…> (open until 4 December 2025). The data covers the repertoire of the 27 scripts included in Root Zone Label Generation Rules <https://www.icann.org/resources/pages/root-zone-lgr-2015-06-21-en> (RZ-LGR). The data is strictly based on visual similarity and builds on top of the “same” characters already identified in RZ-LGR through variant relationship. The data has been collected by script experts and tagged at a level of similarity between levels 1-5 (levels 1-3 indicating probable similarity; 4-5 not considered similar enough). The data covers the following scripts: Arabic, Armenian, Bangla, Chinese (Han), Cyrillic, Devanagari, Ethiopic, Georgian, Greek, Gujarati, Gurmukhi, Hebrew, Japanese (Hiragana, Katakana, and Kanji [Han]), Kannada, Khmer, Korean (Hangul and Hanja [Han]), Lao, Latin, Malayalam, Myanmar, Oriya, Sinhala, Tamil, Telugu, Thaana, and Thai. We would invite the relevant ALAC team to take a look at the data and share any feedback. We would also request you to help share it in the relevant networks to seek further input from those interested. Regards, Sarmad

1 0

SSAC has published SAC132: The Domain Name System Runs on Free and Open Source Software (FOSS)
by Matthias M. Hudobnik Oct. 14, 2025

Oct. 14, 2025

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-committe…. Have a nice day! Best, Matthias ______________________________ Ing. Mag. Matthias M. Hudobnik FIP • CIPP/E • CIPT • DPO • CIS LA matthias(a)hudobnik.at http://www.hudobnik.at @mhudobnik

3 4

APRALO Bytes - Regional Internet Registry Governance, 14 Oct 2025
by Justine Chew Oct. 14, 2025

Oct. 14, 2025

Hello everyone, Here is the latest *APRALO Byte*, which is on the topic of *Regional Internet Registry governance*, published at https://icann-community.atlassian.net/wiki/spaces/APRALO/pages/412844037/AP… (click on 'Read more'). In brief, we draw attention to the ongoing *review of the Internet Coordination Policy - 2 (ICP-2) Document *by the Address Supporting Organization (ASO) and the ALAC's position on the second version of the draft “Governance Document for the Recognition, Operation, and Derecognition of Regional Internet Registries” to update the ICP-2. More details are in the Byte. Kind regards, APRALO Leadership Team ---------------------- *APRALO Bytes* (see: https://icann-community.atlassian.net/wiki/x/BYCbG) is an APRALO initiative aimed at *keeping the community apprised* of issues or topics of importance to the At-Large and/or APRALO community in a manner that is* issue/topic-focused, informative yet lightweight*, *while encouraging community interest and discourse* in such issues/topics.

1 0

Speaking list for 13 and 14 Oct Informal Interactive WSIS+20 stakeholder consultations
by Amrita Choudhury Oct. 10, 2025

Oct. 10, 2025

Hi All The speaking lists for the 13 and 14 October Virtual Informal Interactive WSIS stakeholder consultations on the Zero-Draft have been finalized and are now public here <https://publicadministration.desa.un.org/sites/default/files/2021-04/2025/W…> . The recordings and other outputs from the sessions will be made available here <https://publicadministration.desa.un.org/wsis20/octconsultations>. Regards Amrita

1 0

SAC131 SSAC Comments on Functional Model for Root Server System Governance
by Matthias M. Hudobnik Oct. 1, 2025

Oct. 1, 2025

Dear all, The SSAC commends the Root Server System (RSS) Governance Working Group (GWG) for developing the proposed Functional Model, a significant step toward evolving RSS governance. We acknowledge the Root Server Operators’ (RSOs) critical role in ensuring DNS stability through independent, resilient, and technologically advanced operations. The SSAC supports the Functional Model as a foundation for future RSS governance but highlights areas needing further clarity: · Governance Principles: Define clear principles to guide decision-making and governance evolution. · Implementation Roadmap: Develop a staged plan balancing continuity and governance maturity. · Inclusivity and Transparency: Ensure accountability and diverse stakeholder participation. · Funding Stability: Explore sustainable funding to maintain RSS security and resilience. Regarding the RSSAC037 Concept Model, the SSAC recommends the RSS Council address: · Operationalization: Provide a detailed plan to implement the Concept Model. · High-Level Principles: Specify processes, e.g., for RSO designation/removal. · Operational Details: Define secretariat formation, funding mechanisms, and ICANN community relations. · Interactions: Clarify relationships with bodies like CSC, RZERC, and SSAC. The SSAC urges the RSS Council to prioritize these operational specifics, maintain transparency, and consult the community throughout implementation. We look forward to offering further support to enhance RSS security, stability, and accountability. Link: HYPERLINK "https://itp.cdn.icann.org/en/files/security-and-stability-advisory-committe…"SAC131 SSAC Comments on Functional Model for Root Server System Governance. SAC131 has also been submitted as the SSAC’s response to the Functional Model for Root Server System Governance: https://www.icann.org/en/public-comment/proceeding/functional-model-for-roo… Best, Matthias __________________________ Ing. Mag. Matthias M. Hudobnik FIP, CIPP/E, CIPT, DPO, CIS LA matthias(a)hudobnik.at http://www.hudobnik.at @mhudobnik

2 2