SAC065 was published on 18 February 2014. All SSAC publications can be found at https://www.icann.org/groups/ssac/documents.
| Recommendation | Description | Current Phase |
|---|---|---|
| Recommendation 1 | ICANN should help facilitate an Internet-wide community effort to reduce the number of open resolvers and networks that allow network spoofing. | CLOSED |
| Recommendation 2 | All types of network operators should take immediate steps to prevent network address spoofing. This involves: a. Implement network ingress filtering, as described in BCP38 and SAC004, to restrict packet-level forgery to the greatest extent possible; b. Disclose the extent of their implementation of network ingress filtering to the Internet community as a means of encouraging broader and more effective use of ingress filtering. | CLOSED |
| Recommendation 3 | Recursive DNS server operators should take immediate steps to secure open recursive DNS servers. This involves: a. Identify unmanaged open recursive DNS servers operating in the network and take immediate steps to restrict access to these servers in order to prevent abuse. b. Follow SAC008 Recommendation 3 to (1) disable open recursion on name servers from external sources and (2) only accept DNS queries from trusted sources to assist in reducing amplification vectors for DNS DDoS attacks. c. DNS Application Service Providers should take all reasonable steps to prevent abusive use of their open resolvers so that they are not targets of abuse. This would include continuous monitoring for anomalous behavior, limiting or blocking known abuse queries (e.g., ripe.net ANY); tracking likely target victim IPs (attacks reported or addresses of heavily targeted servers) and restricting or disallowing responses to those IPs; and sharing information with similar operators to coordinate efforts to quell such attacks. | CLOSED |
| Recommendation 4 | Authoritative DNS server operators should investigate deploying authoritative response rate limiting. This involves: a. Investigate mechanisms to deter DNS amplification attacks (e.g., Response Rate Limiting (RRL) in DNS server software), and implement those that are appropriate for their environment; b. Encourage DNS software vendors to provide such capabilities; and c. Frequently review the state of the art of such mechanisms and update their environment as necessary. | CLOSED |
| Recommendation 5 | DNS operators should put in place operational processes to ensure that their DNS software is regularly updated and communicate with their software vendors to keep abreast of latest developments. This should minimally include: a. Audit and update operational practices as necessary to ensure that a process is in place to systematically perform DNS software updates on both an on-going and an emergency basis; and b. Encourage DNS software vendors to implement and refine the relevant capabilities at reasonable cost in system resources. | CLOSED |
| Recommendation 6 | Manufacturers and/or configurators of customer premise networking equipment, including home networking equipment, should take immediate steps to secure these devices and ensure that they are field upgradable when new software is available to fix security vulnerabilities, and aggressively replacing the installed base of non-upgradeable devices with upgradeable devices. This minimally involves: a. Ensuring that the default configuration on these devices does not implement an unmanaged open recursive DNS resolver; b. Providing updates and patches for their equipment to keep the installed base of networking equipment up-to-date to address current security threats, or as a necessary alternative replacing non-updatable equipment with appropriately configured devices; c. Ensuring that large-scale participants in purchasing of customer premise networking equipment (e.g., ISPs, government procurement, large enterprises) insist that networking equipment meet the standards discussed in this document. | CLOSED |
