Security and Stability Advisory Committee (SSAC)
SAC101 | Executive Summary for SSAC Advisory Regarding Access to Domain Name Registration Data (Version 2)
[PDF, 324.05 KB]
Originally published on 14 June 2018, the SSAC published a revised version on 12 December 2018 to reflect evolving circumstances related to ICANN’s Temporary Specification for gTLD Registration Data, and the ongoing Expedited Policy Development Process (EPDP) on the Temporary Specification for gTLD Registration Data. Version 1 of SAC101 has been retired and version 2 is authoritative.
This advisory describes Registration Data Directory Services (RDDS) access issues and offers recommendations for how to move forward. RDDS provide access to domain name registration data used to identify and mitigate various types of Internet abuse and technical problems. However, access to the data for legitimate purposes has diminished over recent years, and availability is more constrained and more restricted. Two primary reasons for this development are rate-limiting practices and data protection laws that limit the availability of data to the public. Such changes in Internet security practices negatively impact the ability of security practitioners and law enforcement to detect and mitigate cybercrime and DNS abuse.
Recommendations
- Recommendation 1: The ICANN Board, ICANN Organization, and ICANN community must solve long-deferred problems regarding domain registration data and access to it. SSAC recommends that the ICANN Board oversee the creation and execution of a plan that accomplishes the following interconnected tasks in a coordinated fashion, with timely deadlines. The creation and execution of this plan should be a top priority of the ICANN Board, ICANN Organization, and ICANN community.
- Recommendation 2: The ICANN Board should direct the ICANN Organization to work with the ICANN Community to: A) develop policy with clearly defined uniform purposes for RDDS rate-limiting and corresponding service level agreement requirements, and B) clarify current expectations for the use of rate limiting under existing policy and agreements.
- Recommendation 3: The ICANN Board and PDP policy-makers should ensure that security practitioners and law enforcement authorities have access to domain name contact data, via RDDS, to the full extent allowed by applicable law.
- Recommendation 4: The initiation of charges for RDDS access, or for any significant future changes in fees for RDDS access, must include a formal assessment of user impacts and the security and stability impacts, and must be conducted as part of a formal Policy Development Process (PDP). RDDS has vital uses in the public interest, and RDDS is a core service. Allowing contracted parties to charge for or significantly change access fees for RDDS service would be a highly consequential decision affecting diverse users, and presents a reasonable risk of a meaningful adverse effect on stability and security.
- Recommendation 5: The SSAC reiterates Recommendation 2 from SAC061: "The ICANN Board should ensure that a formal security risk assessment of the registration data policy be conducted as an input into the Policy Development Process. A separate security risk assessment should also be conducted regarding the implementation of the policy." These assessments should be incorporated into PDP plans at the GNSO. Among other aspects, the risk assessment should assess how the policy will affect access to and use of domain registration data by law enforcement bodies and security practitioners.
- Recommendation 6: The ICANN Board should direct the ICANN Organization to work to ensure that all methods of access to RDDS data provide an equivalent response to the same query. In particular, in the interest of security and stability, if a data field is published to a given user, ICANN should ensure that the registry or registrar publishes it via all contractually required RDDS access methods.
- Recommendation 7: The ICANN Board should direct the ICANN Organization to work to ensure that RDDS access is provided in a measurable and enforceable framework, which can be understood by all parties. ICANN Compliance testing should also measure RDDS uptime and responsiveness as it is experienced from the public Internet perspective, and ICANN Compliance must have the means and tools necessary to enforce the policy.

