Subject: [DNSOP] Protocol Action: 'Preventing Use of Recursive Nameservers in Reflector Attacks' to BCP

From: The IESG <[email-masked]>
Date: Mon, 15 Sep 2008 08:39:38 -0700 (PDT)

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 DNSSECFrom [email-masked]  Mon Sep 15 08:39:41 2008
From: The IESG <[email-masked]>
To: IETF-Announce <[email-masked]>
Date: Mon, 15 Sep 2008 08:39:38 -0700 (PDT)
Cc: dnsop mailing list <[email-masked]>,
	Internet Architecture Board <[email-masked]>,
	dnsop chair <[email-masked]>,
	RFC Editor <[email-masked]>
Subject: [DNSOP] Protocol Action: 'Preventing Use of Recursive Nameservers
 in Reflector Attacks' to BCP
Sender: [email-masked]

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 DNSS
   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.

_______________________________________________
DNSOP mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/dnsop

EC
   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.

_______________________________________________
DNSOP mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/dnsop

---

From: Stephane Bortzmeyer <[email-masked]>
Date: Tue, 16 Sep 2008 21:55:30 +0200

On Mon, Sep 15, 2008 at 08:39:38AM -0700,
 The IESG <[email-masked]> wrote 

>    <draft-ietf-dnsop-reflectors-are-evil-06.txt> as a BCP

But DNS reflectors are not evil. Someone found an interesting use for
them:

http://ccr.sigcomm.org/online/?q=node/264

A Study of Prefix Hijacking and Interception in the Internet

[...]

We used recursive DNS nameservers across the Internet to generate
actual traffic destined to the prefix. To this ef- fect, we collected
a list 23,858 of recursive nameservers be- longing to 7,566 of the
18,391 routable ASes on the Internet (based on a BGP routing table
obtained from the Route- Views repository). We also pointed the NS
record for a domain name under our control (prefix.anycast.guha.cc) to
[...]
_______________________________________________
DNSOP mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/dnsop

---

From: Stephane Bortzmeyer <[email-masked]>
Date: Tue, 16 Sep 2008 21:55:30 +0200

[...]