Preventing Use of Recursive Nameservers in Reflector Attacks
RFC 5358

Approval announcement
Draft of message to be sent after approval:

From: The IESG <iesg-secretary@ietf.org>
To: IETF-Announce <ietf-announce@ietf.org>
Cc: Internet Architecture Board <iab@iab.org>,
    RFC Editor <rfc-editor@rfc-editor.org>, 
    dnsop mailing list <dnsop@ietf.org>, 
    dnsop chair <dnsop-chairs@tools.ietf.org>
Subject: Protocol Action: 'Preventing Use of Recursive 
         Nameservers in Reflector Attacks' to BCP 

The IESG has approved the following document:

- 'Preventing Use of Recursive Nameservers in Reflector Attacks '
   <draft-ietf-dnsop-reflectors-are-evil-07.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-07.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.