Action-items
1 Clarifications
1.1 Mark
1.1.1 Leverage the DNS and unique identifiers (such as botnets, denial of service attacks, social engineering attacks) for fraud, malicious conduct or route-hijacking attacks
2 Future actions?
3 Impacts
3.1 The process to restore DNS information can take a long time even when unauthorized modification of DNS information is discovered quickly
4 Mitgation
4.1 DNS Infrastructure Recommendations -- SAC 5
4.1.1 1. Zone administrators should adopt a policy that ensures that referral information for their sub-zones is updated upon request and in a timely fashion.
4.1.2 2. Zone administrators should adopt a policy that requires multiple independent servers for their zone when it delegates sub-zones to more than one responsible party.
4.2 Elements of the Registry Failover Plan (mitigation)
4.2.1 Considerable additional study is needed to develop a robust registry failover plan. However, based on the critical functions, transition experiences and failure scenarios described in this (interim) report, registries should consider at least the following measures:
4.2.2 Provide for geographic diversity of name servers and have contingency plans in place. Include diversity and contingency progress and status reports in monthly reports to ICANN.
4.2.3 Document contingency plans, provide this documentation on a confidential basis to ICANN for review and consultation, and test the plans on a periodic basis.
4.2.4 Document archival and accuracy measures performed during the monthly reporting period, and information regarding incidents (e.g., problems completing zone changes, and attacks against the registry infrastructure).
4.2.5 With ICANN, establish a clear communication plan for informing affected registrants, registrars, users and Internet community in the event of a registry failure. Commmunicate the reasons for the failure and available options.
4.2.6 As part of the new gTLD process, applicants should submit a TLD transition plan which identifies the critical functions of the registry and describes how each of those functions would be transitioned to a new operator in the event of registry failure This plan may include the identification of a back-up or temporary provider. The applicant may designate this section of the gTLD agreement or application as confidential. The transition plan is to be retained by the registry as part of the registry's overall failover plan. The transition plan requirement follows the recommendations in the GAC Principles on New gTLDs related to registry failover and continuity practices for new gTLDs.
4.2.7 A clearly documented transition process:
5 Possible Recommendations
5.1 ICANN develops catalog of registry, registrar and registrant security services
5.1.1 Issues/Concerns
5.1.1.1 Possibility of painting a roadmap for bad actors
5.1.1.1.1 Options
5.1.1.1.1.1 Keep the list confidential
5.1.1.1.1.2 List only entities that are secure -- provides a less accurate target for attackers
5.1.2 Benefits
5.1.2.1 Improves decision-making on the part of registrants
5.1.2.1.1 Finding (1) Differences exist among registrars as to their vulnerability to attack and the degree of protection they provide against attacks on domain accounts. Many domain registrants do not appear to have sufficient information to assess the extent to which a registrar is able to protect its domain accounts from attack and DNS configurations from malicious alteration. SAC 40
5.1.2.1.2 Finding (3) Registrars could make more information about their security services available to allow customers to make informed decisions. Voluntarily submitting operations to an independent security audit and publicizing successful outcomes of such audits would allow customers to choose a registrar based on security requirements as well as cost and other ancillary features (such as web and DNS hosting). SAC 40