Process for Potential Implementation

O1: Develop a Tabletop Exercise Program

R1: Continue Existing Work on DNS Abuse

Recommendation text: ICANN org should continue to participate in industry efforts to develop the definitions and actions regarding DNS abuse, and support the security and research community in identifying and mitigating DNS abuse via research funding for those identified experts.

Additional notes included in the report: DNS abuse takes many forms. Being able to clearly define what serves as abuse is an important step in determining how to mitigate that abuse.

R2: Investigate DNS Security Enhancements

Recommendation text: ICANN org should develop a program to continually investigate the limits, risks, and benefits of various DNS security enhancements such as, but not limited to:

• Scanning of CDS, CDNSKEY, and CSYNC records by registries and registrars as part of education and awareness around the support and administration of DNSSEC.
• Enhanced visibility into changes in the DNS ecosystem, such as encouraging support for the DNS Transparency Project, to notify registrants and impacted users of domain changes.
• Support for secure authentication technologies such as DANE and alternative transport technologies like DoH, DoT, and DNS-over-QUIC (DoQ) at relevant points (e.g., by authoritative nameservers at any level of the DNS hierarchy) in the DNS ecosystem.

R3: Investigate Appropriate Best Practice for Authentication (DSFI-TSG priority)

Recommendation text: ICANN org, along with relevant organizations and communities, should conduct a study and offer a report on what should be considered best practice for authentication when considered against the different roles and risks in the DNS.

Additional notes included in the report: The DSFI-TSG recognizes that there are many sources for “best practice” around authentication when it comes to the actors that play a role in the DNS ecosystem, such as registries, registrars, resellers, DNS providers, and registrants.

C1: Empower Contracted Parties

F1: Bug Bounty Program Feasibility Funding

Recommendation text: ICANN org should lead an effort to work with DNS software, hardware, and service vendors, as well as registry and registrar software vendors, to investigate the feasibility of funding and/or supporting the creation of DNS-related bug bounty programs. ICANN org should review the findings of that investigation and make recommendations for any further efforts. ICANN org should include in its reports information on the feasibility of bug bounty programs and what mechanisms are available for reporting vulnerabilities. As a final step, use the results of these reports to create a central list of all DNS bug bounty programs and reporting mechanisms that will be maintained regularly.

Additional notes included in the report: A bug bounty program may result in DNS protocol or implementation vulnerabilities being discovered and disclosed responsibly. Part of this program may include an interoperability testbed to enable cross-platform verification testing of newly discovered or reported vulnerabilities. In all cases, a bug bounty program would need continual attention and strong cross-functional collaboration.

E1: Education around Authentication

Recommendation text: ICANN org should build educational programs encouraging DNS stakeholders to make available the appropriate standards-based authentication mechanisms for all interactions that should be authenticated, as well as informing those stakeholders of the risks associated with weak authentication schemes. ICANN org should also support these programs through communication tactics.

Additional notes included in the report: At the time of publication, the DSFI-TSG believes that a training program such as this should include discussion and encouragement of multi-factor authentication and less reliance on solely password-based authentication. The ICANN community and industry experts could help in drafting such best practices based on their expertise. ICANN org could play a central role in the process of promoting and modeling their use in ICANN infrastructure, policies, and contracts. The DSFI-TSG recognizes that this recommendation overlaps recommendations offered in SAC074 and offers a strong opportunity for ICANN org to partner with other organizations to extend the education and awareness efforts.

E2: Registry Lock

Recommendation text: ICANN org should undertake efforts to improve documentation and understanding of Registry Lock features and to promote their uses, when appropriate, and improve the understanding regarding the differences between Registry and Registrar Lock. Registrants should be able to find clear definitions of what these features provide, what these features do not provide, and the difference between them. ICANN org should consider facilitating the standardization of minimum requirements for Registry and Registrar Lock services.

Additional notes included in the report: ICANN org could do this by working with the technical community and/or by providing funds for research that explores the benefit of such a process as well as facilitating discussions around it. This may build on existing work, such as the Council of European National Top-Level Domain Registries’ white paper, “Models of registry lock for top-level domain registries.”

E3: Awareness of Best Practices for Infrastructure Security

E4: DNS Blocking and Filtering

Recommendation text: ICANN org should create informative and educational materials to help the ICANN community, contracted parties, and other interested parties understand the risks and benefits of DNS blocking and filtering for security and stability reasons throughout the global DNS infrastructure community.

Additional notes included in the report: Understandings should include best practices, tooling for understanding DNS interdependencies to avoid large-scale collateral damage, use of the Public Suffix List (PSL), allow lists and similar lists to avoid overblocking, and general hygiene for these types of activities.

E5: Incident Response (DSFI-TSG priority)

Recommendation text: ICANN org should, together with relevant parties, encourage the development and deployment of a formalized incident-response process across the DNS industry that allows for interaction with others in the ecosystem. Such an effort should include incident-response handling as well as the protected sharing of threat and incident information.

Additional notes included in the report: This effort could be based on incident-response best practices from other industries and could be based in part on prior work and recommendations from SSAC’s SAC115 and the Security, Stability, and Resiliency Review Team’s (SSR2) recommendation 6, “SSR Vulnerability Disclosure and Transparency.”

E6: Covert Channel Awareness