Network Working Group J. Damas
Request for Comments: 5358 ISC
BCP: 140 F. Neves
Category: Best Current Practice Registro.br
October 2008
Network Working Group J. Damas
Request for Comments: 5358 ISC
BCP: 140 F. Neves
Category: Best Current Practice Registro.br
October 2008
Preventing Use of Recursive Nameservers in Reflector Attacks
防止在反射器攻击中使用递归名称服务器
Status of This Memo
关于下段备忘
This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements. Distribution of this memo is unlimited.
本文件规定了互联网社区的最佳现行做法，并要求进行讨论和提出改进建议。本备忘录的分发不受限制。
Abstract
摘要
This document describes ways to prevent the use of default configured recursive nameservers as reflectors in Denial of Service (DoS) attacks. It provides recommended configuration as measures to mitigate the attack.
本文档介绍如何防止在拒绝服务（DoS）攻击中使用默认配置的递归名称服务器作为反射器。它提供了建议的配置作为缓解攻击的措施。
Table of Contents
目录
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Document Terminology . . . . . . . . . . . . . . . . . . . . . 2
3. Problem Description . . . . . . . . . . . . . . . . . . . . . . 2
4. Recommended Configuration . . . . . . . . . . . . . . . . . . . 4
5. Security Considerations . . . . . . . . . . . . . . . . . . . . 5
6. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . 5
7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 5
7.1. Normative References . . . . . . . . . . . . . . . . . . . 5
7.2. Informative References . . . . . . . . . . . . . . . . . . 6
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Document Terminology . . . . . . . . . . . . . . . . . . . . . 2
3. Problem Description . . . . . . . . . . . . . . . . . . . . . . 2
4. Recommended Configuration . . . . . . . . . . . . . . . . . . . 4
5. Security Considerations . . . . . . . . . . . . . . . . . . . . 5
6. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . 5
7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 5
7.1. Normative References . . . . . . . . . . . . . . . . . . . 5
7.2. Informative References . . . . . . . . . . . . . . . . . . 6
Recently, DNS [RFC1034] has been named as a major factor in the generation of massive amounts of network traffic used in Denial of Service (DoS) attacks. These attacks, called reflector attacks, are not due to any particular flaw in the design of the DNS or its implementations, except that DNS relies heavily on UDP, the easy abuse of which is at the source of the problem. The attacks have preferentially used DNS due to common default configurations that allow for easy use of open recursive nameservers that make use of such a default configuration.
最近，DNS[RFC1034]被称为拒绝服务（DoS）攻击中产生大量网络流量的主要因素。这些攻击称为反射器攻击，不是由于DNS设计或其实现中的任何特定缺陷造成的，只是DNS严重依赖UDP，而UDP的易滥用是问题的根源。这些攻击优先使用DNS，因为常见的默认配置允许轻松使用使用此类默认配置的开放递归名称服务器。
In addition, due to the small query-large response potential of the DNS system, it is easy to yield great amplification of the source traffic as reflected traffic towards the victims.
此外，由于DNS系统的小查询和大响应潜力，很容易将源流量放大为向受害者反映的流量。
DNS authoritative servers that do not provide recursion to clients can also be used as amplifiers; however, the amplification potential is greatly reduced when authoritative servers are used. It is also impractical to restrict access to authoritative servers to a subset of the Internet, since their normal operation relies on them being able to serve a wide audience; hence, the opportunities to mitigate the scale of an attack by modifying authoritative server configurations are limited. This document's recommendations are concerned with recursive nameservers only.
不向客户端提供递归的DNS权威服务器也可以用作放大器；然而，当使用权威服务器时，放大潜力会大大降低。将权威服务器的访问限制在互联网的一个子集也是不切实际的，因为它们的正常运行依赖于它们能够服务于广泛的受众；因此，通过修改权威服务器配置来减轻攻击规模的机会是有限的。本文档的建议仅涉及递归名称服务器。
In this document we describe the characteristics of the attack and recommend DNS server configurations that specifically alleviate the problem described, while pointing to the only real solution: the wide-scale deployment of ingress filtering to prevent use of spoofed IP addresses [BCP38].
在本文档中，我们描述了攻击的特征，并推荐专门缓解所述问题的DNS服务器配置，同时指出了唯一真正的解决方案：大规模部署入口过滤以防止使用伪造IP地址[BCP38]。
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119].
本文件中的关键词“必须”、“不得”、“必需”、“应”、“不应”、“应”、“不应”、“建议”、“可”和“可选”应按照[RFC2119]中所述进行解释。
Because most DNS traffic is stateless by design, an attacker could start a DoS attack in the following way:
由于大多数DNS流量在设计上是无状态的，因此攻击者可以通过以下方式启动DoS攻击：
1. The attacker starts by configuring a record on any zone he has access to, normally with large RDATA and Time to Live (TTL).
1. 攻击者首先在其有权访问的任何区域上配置一条记录，通常具有较大的RDATA和生存时间（TTL）。
2. Taking advantage of clients on non-BCP38 networks, the attacker then crafts a query using the source address of their target victim and sends it to an open recursive nameserver.
2. 攻击者利用非BCP38网络上的客户端，然后使用目标受害者的源地址创建查询，并将其发送到开放递归名称服务器。
3. Each open recursive nameserver proceeds with the resolution, caches the record, and finally sends it to the target. After this first lookup, access to the authoritative nameservers is normally no longer necessary. The record will remain cached at the open recursive nameserver for the duration of the TTL, even if it's deleted from the zone.
3. 每个打开的递归名称服务器继续解析，缓存记录，最后将其发送到目标。在第一次查找之后，通常不再需要访问权威名称服务器。在TTL期间，记录将保持缓存在开放递归名称服务器中，即使它已从区域中删除。
4. Cleanup of the zone might, depending on the implementation used in the open recursive nameserver, afford a way to clean the cached record from the open recursive nameserver. This would possibly involve queries luring the open recursive nameserver to lookup information for the same name that is being used in the amplification.
4. 根据开放递归名称服务器中使用的实现，区域清理可能提供一种从开放递归名称服务器中清理缓存记录的方法。这可能涉及到一些查询，这些查询引诱开放式递归名称服务器查找在放大中使用的相同名称的信息。
Because the characteristics of the attack normally involve a low volume of packets amongst all the kinds of actors besides the victim, it's unlikely any one of them would notice their involvement based on traffic pattern changes.
由于攻击的特征通常涉及除受害者之外的所有参与者之间的低数据包量，因此他们中的任何人都不可能根据流量模式的变化注意到他们的参与。
Taking advantage of an open recursive nameserver that supports EDNS0 [RFC2671], the amplification factor (response packet size / query packet size) could be around 80. With this amplification factor, a relatively small army of clients and open recursive nameservers could generate gigabits of traffic towards the victim.
利用支持EDNS0[RFC2671]的开放递归名称服务器，放大系数（响应数据包大小/查询数据包大小）可能在80左右。有了这个放大因子，相对较小的客户端和开放递归名称服务器大军可能会向受害者产生千兆位的流量。
With the increasing length of authoritative DNS responses derived from deployment of DNSSEC [RFC4033] and NAPTR resource records as used in ENUM services, authoritative servers will eventually be more useful as actors in this sort of amplification attack.
随着ENUM服务中使用的DNSSEC[RFC4033]和NAPTR资源记录的部署所产生的权威DNS响应的长度不断增加，权威服务器最终将作为此类放大攻击的参与者变得更加有用。
Even if this amplification attack is only possible due to non-deployment of BCP38, it is easier to leverage because of historical reasons. When the Internet was a much closer-knit community, some nameserver implementations were made available with default configurations that, when used for recursive nameservers, made the server accessible to all hosts on the Internet.
即使这种放大攻击只有在未部署BCP38的情况下才可能发生，但由于历史原因，更容易利用。当Internet是一个更紧密的社区时，一些名称服务器实现可以使用默认配置，当用于递归名称服务器时，这些默认配置使Internet上的所有主机都可以访问服务器。
For years this was a convenient and helpful configuration, enabling wider availability of services. As this document aims to make apparent, it is now much better to be conscious of one's own nameserver services and focus the delivery of services on the intended audience of those services -- be they a university campus, an enterprise, or an ISP's customers. The target audience also includes operators of small networks and private server managers who
多年来，这是一种方便而有用的配置，使服务的可用性更加广泛。正如本文档旨在说明的那样，现在更好的做法是了解自己的名称服务器服务，并将服务的交付重点放在这些服务的预期受众身上——无论他们是大学校园、企业还是ISP的客户。目标受众还包括小型网络运营商和
decide to operate nameservers with the aim of optimising their DNS service, as these are more likely to use default configurations as shipped by implementors.
决定运行名称服务器以优化其DNS服务，因为这些服务器更可能使用实现者提供的默认配置。
In this section we describe the Best Current Practice for operating recursive nameservers. Following these recommendations would reduce the chances of any given recursive nameserver being used for the generation of an amplification attack.
在本节中，我们将介绍当前操作递归名称服务器的最佳实践。遵循这些建议将减少使用任何给定递归名称服务器生成放大攻击的机会。
The generic recommendation to nameserver operators is to use the means provided by the implementation of choice to provide recursive name lookup service to only the intended clients. Client authorization can usually be done in several ways:
对名称服务器操作员的一般建议是使用choice实现提供的方法，仅向预期的客户端提供递归名称查找服务。客户端授权通常可以通过几种方式完成：
o IP address based authorization. Use the IP source address of the DNS queries and filter them through an Access Control List (ACL) to service only the intended clients. This is easily applied if the recursive nameserver's service area is a reasonably fixed IP address range that is protected against external address spoofing, usually the local network.
o 基于IP地址的授权。使用DNS查询的IP源地址，并通过访问控制列表（ACL）对其进行过滤，以便仅为预期的客户端提供服务。如果递归名称服务器的服务区域是一个合理固定的IP地址范围，可以防止外部地址欺骗（通常是本地网络），那么这很容易应用。
o Incoming interface based selection. Use the incoming interface for the query as a discriminator to select which clients are to be served. This is of particular applicability for SOHO (Small Office, Home Office) devices, such as broadband routers that include embedded recursive nameservers.
o 基于输入接口的选择。使用查询的传入接口作为鉴别器来选择要为哪些客户端提供服务。这特别适用于SOHO（小型办公室、家庭办公室）设备，例如包括嵌入式递归名称服务器的宽带路由器。
o TSIG [RFC2845] or SIG(0) [RFC2931] signed queries to authenticate the clients. This is a less error prone method that allows server operators to provide service to clients who change IP address frequently (e.g., roaming clients). The current drawback of this method is that very few stub resolver implementations support TSIG or SIG(0) signing of outgoing queries. The effective use of this method implies, in most cases, running a local instance of a caching nameserver or forwarder that will be able to TSIG sign the queries and send them on to the recursive nameserver of choice.
o TSIG[RFC2845]或SIG（0）[RFC2931]签名查询以验证客户端。这是一种不易出错的方法，允许服务器运营商向频繁更改IP地址的客户端（例如漫游客户端）提供服务。此方法当前的缺点是很少有存根解析器实现支持传出查询的TSIG或SIG（0）签名。在大多数情况下，有效使用此方法意味着运行缓存名称服务器或转发器的本地实例，该实例将能够对查询进行TSIG签名，并将查询发送到所选的递归名称服务器。
o For mobile users, use a local caching nameserver running on the mobile device or use a Virtual Private Network to a trusted server.
o 对于移动用户，请使用移动设备上运行的本地缓存名称服务器，或使用虚拟专用网络连接到受信任的服务器。
In nameservers that do not need to be providing recursive service, for instance servers that are meant to be authoritative only, turn recursion off completely. In general, it is a good idea to keep recursive and authoritative services separate as much as practical. This, of course, depends on local circumstances.
在不需要提供递归服务的名称服务器中，例如仅用于授权的服务器，完全关闭递归。一般来说，尽可能将递归服务和权威服务分开是一个好主意。当然，这取决于当地情况。
Even with all these recommendations, network operators should consider deployment of ingress filtering [BCP38] in routers to prevent use of address spoofing as a viable course of action. In situations where more complex network setups are in place, "Ingress Filtering for Multihomed Network" [BCP84] maybe a useful additional reference.
即使有了所有这些建议，网络运营商也应该考虑在路由器中部署入口过滤[BCP38 ]，以防止使用地址欺骗作为可行的行动过程。在有更复杂的网络设置的情况下，“多宿网络入口过滤”[BCP84]可能是一个有用的附加参考。
By default, nameservers SHOULD NOT offer recursive service to external networks.
默认情况下，名称服务器不应向外部网络提供递归服务。
This document does not create any new security issues for the DNS protocol, it deals with a weakness in implementations.
本文档没有为DNS协议创建任何新的安全问题，它处理了实现中的一个弱点。
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 as 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.
SIG（0）事务安全的部署[RFC933]应该考虑SIG（0）计算费用的警告，因为它使用公钥密码，而不是TSIG [RCF2545 ]所使用的对称密钥。此外，适当密钥的识别需要类似于部署TSIG的机制，或者，如果在DNS中发布，则在密钥RRs上使用DNSSEC[RFC4033]签名（RRSIG）。这反过来需要对DNSSEC信托锚进行适当管理。
The authors would like to acknowledge the helpful input and comments of Joe Abley, Olafur Gudmundsson, Pekka Savola, Andrew Sullivan, and Tim Polk.
作者希望感谢Joe Abley、Olafur Gudmundsson、Pekka Savola、Andrew Sullivan和Tim Polk的有用意见和评论。
[RFC1034] Mockapetris, P., "Domain names - concepts and facilities", STD 13, RFC 1034, November 1987.
[RFC1034]Mockapetris，P.，“域名-概念和设施”，STD 13，RFC 1034，1987年11月。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119]Bradner，S.，“RFC中用于表示需求水平的关键词”，BCP 14，RFC 2119，1997年3月。
[RFC2671] Vixie, P., "Extension Mechanisms for DNS (EDNS0)", RFC 2671, August 1999.
[RFC2671]Vixie，P.，“DNS的扩展机制（EDNS0）”，RFC 26711999年8月。
[RFC2845] Vixie, P., Gudmundsson, O., Eastlake, D., and B. Wellington, "Secret Key Transaction Authentication for DNS (TSIG)", RFC 2845, May 2000.
[RFC2845]Vixie，P.，Gudmundsson，O.，Eastlake，D.，和B.Wellington，“DNS秘密密钥交易认证（TSIG）”，RFC 28452000年5月。
[RFC2931] Eastlake, D., "DNS Request and Transaction Signatures (SIG(0)s)", RFC 2931, September 2000.
[RFC2931]Eastlake，D.，“DNS请求和事务签名（SIG（0）s）”，RFC 29312000年9月。
[RFC4033] Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose, "DNS Security Introduction and Requirements", RFC 4033, March 2005.
[RFC4033]Arends，R.，Austein，R.，Larson，M.，Massey，D.，和S.Rose，“DNS安全介绍和要求”，RFC 4033，2005年3月。
[BCP38] Ferguson, P. and D. Senie, "Network Ingress Filtering: Defeating Denial of Service Attacks which employ IP Source Address Spoofing", BCP 38, RFC 2827, May 2000.
[BCP38]Ferguson，P.和D.Senie，“网络入口过滤：击败利用IP源地址欺骗的拒绝服务攻击”，BCP 38，RFC 2827，2000年5月。
[BCP84] Baker, F. and P. Savola, "Ingress Filtering for Multihomed Networks", BCP 84, RFC 3704, March 2004.
[BCP84]Baker，F.和P.Savola，“多宿网络的入口过滤”，BCP 84，RFC 37042004年3月。
Authors' Addresses
作者地址
Joao Damas Internet Systems Consortium, Inc. 950 Charter Street Redwood City, CA 94063 US
Joao Damas Internet Systems Consortium，Inc.美国加利福尼亚州红木市查特街950号，邮编94063
Phone: +1 650 423 1300
EMail: Joao_Damas@isc.org
URI: http://www.isc.org/
Phone: +1 650 423 1300
EMail: Joao_Damas@isc.org
URI: http://www.isc.org/
Frederico A. C. Neves NIC.br / Registro.br Av. das Nacoes Unidas, 11541, 7 Sao Paulo, SP 04578-000 BR
Frederico A.C.Neves NIC.br/Registro.br Av。das Nacoes Unidas，11541，圣保罗7号，SP 04578-000 BR
Phone: +55 11 5509 3511
EMail: fneves@registro.br
URI: http://registro.br/
Phone: +55 11 5509 3511
EMail: fneves@registro.br
URI: http://registro.br/
Full Copyright Statement
完整版权声明
Copyright (C) The IETF Trust (2008).
版权所有（C）IETF信托基金（2008年）。
This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights.
本文件受BCP 78中包含的权利、许可和限制的约束，除其中规定外，作者保留其所有权利。
This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
本文件及其包含的信息以“原样”为基础提供，贡献者、他/她所代表或赞助的组织（如有）、互联网协会、IETF信托基金和互联网工程任务组不承担任何明示或暗示的担保，包括但不限于任何保证，即使用本文中的信息不会侵犯任何权利，或对适销性或特定用途适用性的任何默示保证。
Intellectual Property
知识产权
The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79.
IETF对可能声称与本文件所述技术的实施或使用有关的任何知识产权或其他权利的有效性或范围，或此类权利下的任何许可可能或可能不可用的程度，不采取任何立场；它也不表示它已作出任何独立努力来确定任何此类权利。有关RFC文件中权利的程序信息，请参见BCP 78和BCP 79。
Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.
向IETF秘书处披露的知识产权副本和任何许可证保证，或本规范实施者或用户试图获得使用此类专有权利的一般许可证或许可的结果，可从IETF在线知识产权存储库获取，网址为http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org.
IETF邀请任何相关方提请其注意任何版权、专利或专利申请，或其他可能涵盖实施本标准所需技术的专有权利。请将信息发送至IETF的IETF-ipr@ietf.org.