The IESG has approved the following document: - 'Preventing Use of Recursive Nameservers in Reflector Attacks ' <draft-ietf-dnsop-reflectors-are-evil-06.txt> as a BCP This document is the product of the Domain Name System Operations Working Group. The IESG contact persons are Ron Bonica and Dan Romascanu. A URL of this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-dnsop-reflectors-are-evil-06.txt Technical Summary This document describes ways to prevent the use of recursive nameservers as reflectors in Denial of Service (DoS) attacks. It makes recommendations to both operators and vendors (for default configurations). Working Group Summary The document was started in reaction to the "DNS reflection attacks" widely published in early 2006. While the basic direction was clear from the beginning, it needed some discussion to agree upon a recommendation of the more sophisticated and less widely deployed querier authentication mechanisms (TSIG and SIG(0)). Document Quality After the February 2006 DNS amplification attacks, several surveys have discovered varying, but huge numbers of DNS resolvers on the Internet willing to respond to DNS queries of arbitrary origin. At least two vendors of DNS recursive servers (full resolvers) have announced to (or do already) follow the recommendations made in this document by adjusting their default ACLs. Personnel Peter Koch acted as the document shepherd. Ron Bonica reviewed this document for the IESG. RFC EDITOR NOTE: ============= Section 3, 3rd last paragraph: OLD: With the increasing length of authoritative DNS responses derived from deployment of DNSSEC and NAPTR as used in ENUM services, authoritative servers will eventually be more useful as actors in this sort of amplification attack. NEW: With the increasing length of authoritative DNS responses derived from deployment of DNSSEC [RFC4033] and NAPTR as used in ENUM services, authoritative servers will eventually be more useful as actors in this sort of amplification attack. Security Considerations, 2nd paragraph: OLD: Deployment of SIG(0) transaction security should consider the caveats with SIG(0) computational expense as it uses public key cryptography rather than the symmetric keys used by TSIG. In addition, the identification of the appropriate keys needs similar mechanisms to those for deploying TSIG, or alternatively, the use of DNSSEC signatures (RRSIGs) over the KEY RRs if published in DNS. This will in turn require the appropriate management of DNSSEC trust anchors. NEW: Deployment of SIG(0) transaction security [RFC2931] should consider the caveats with SIG(0) computational expense as it uses public key cryptography rather than the symmetric keys used by TSIG [RFC2845]. In addition, the identification of the appropriate keys needs similar mechanisms to those for deploying TSIG, or alternatively, the use of DNSSEC [RFC4033] signatures (RRSIGs) over the KEY RRs if published in DNS. This will in turn require the appropriate management of DNSSEC trust anchors. Add to "8.1. Normative References" NEW: [RFC4033] Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose, "DNS Security Introduction and Requirements", RFC 4033, March 2005. _______________________________________________ IETF-Announce@ietf.org https://www.ietf.org/mailman/listinfo/ietf-announce
