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.