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.
このドキュメントはインターネットコミュニティのためのインターネットBest Current Practicesを指定し、改善のための議論と提案を要求します。このメモの配布は無制限です。
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
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に大きく依存している以外、の簡単な虐待が問題の原因です。攻撃は優先的にこのようなデフォルトの設定を使用することが開いている再帰的なネームサーバの容易な使用を可能に共通のデフォルト構成に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].
イングレスフィルタリングの大規模な展開は、偽装されたIPアドレス[BCP38]の使用を防止するために：唯一の真の解決策を指しながら、この文書では、私たちは、攻撃の特徴を説明し、具体的に記載問題を軽減するDNSサーバの設定をお勧めします。
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].
この文書のキーワード "MUST"、 "MUST NOT"、 "REQUIRED"、、、、 "べきではない" "べきである" "ないもの" "ものとし"、 "推奨"、 "MAY"、および "OPTIONAL" はあります[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.
DNSSEC [RFC4033]とENUMサービスで使用されるよう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の非展開にのみ可能であったとしても、それがために歴史的な理由のテコに簡単です。インターネットははるかに近いニットコミュニティだったときに、いくつかのネームサーバの実装は、再帰的なネームサーバで使用、デフォルトの設定で利用可能になった、インターネット上のすべてのホストにサーバがアクセス可能。
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 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.
年間では、これはサービスのより広い可用性を有効にする、便利で親切な構成でした。この文書は見かけ作りを目指していたように、自分のネームサーバサービスを意識すると、それらのサービスの対象読者にサービスの提供を集中することになりましはるかに優れている - 大学のキャンパス、企業、またはISPの顧客彼らなります。これらは、実装によって出荷時のデフォルト設定を使用する可能性が高くなるように、ターゲットとするユーザーも、自分の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:
演算子をネームサーバにする一般的な推奨事項は、唯一の目的とするクライアントに再帰名検索サービスを提供するために、選択の実装によって提供手段を使用することです。クライアント認証は、通常、いくつかの方法で行うことができます。
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.
それは、公開鍵暗号方式ではなく、TSIG [RFC2845]で使用される対称鍵を使用していますようSIG（0）トランザクションセキュリティ[RFC2931]の展開は、SIG（0）計算コストでの注意点を考慮する必要があります。加えて、適切なキーの識別は、代替的に、鍵資源レコード上DNSSEC [RFC4033]の署名（RRSIGs）の使用DNSで公開されている場合、TSIGを展開するためのものと同様の機構を必要とし、または。順番にこの意志がDNSSECトラストアンカーの適切な管理を必要とします。
The authors would like to acknowledge the helpful input and comments of Joe Abley, Olafur Gudmundsson, Pekka Savola, Andrew Sullivan, and Tim Polk.
著者は、役に立つ入力とジョーAbley、オラフルグドムンソン、ペッカSavola、アンドリュー・サリバン、とティム・ポークのコメントを確認したいと思います。
[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]ブラドナーの、S.、 "要件レベルを示すためにRFCsにおける使用のためのキーワード"、BCP 14、RFC 2119、1997年3月。
[RFC2671] Vixie, P., "Extension Mechanisms for DNS (EDNS0)", RFC 2671, August 1999.
[RFC2671]いるVixie、P.、 "DNS用拡張メカニズム（EDNS0）"、RFC 2671、1999年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.、グドムンソン、O.、イーストレイク、D.、およびB.ウェリントン、 "DNSのための秘密鍵トランザクション認証（TSIG）"、RFC 2845、2000年5月。
[RFC2931] Eastlake, D., "DNS Request and Transaction Signatures (SIG(0)s)", RFC 2931, September 2000.
[RFC2931]イーストレイク、D.、 "DNS要求とトランザクション署名（SIG（0）S）"、RFC 2931、2000年9月。
[RFC4033] Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose, "DNS Security Introduction and Requirements", RFC 4033, March 2005.
[RFC4033]アレンズ、R.、Austeinと、R.、ラーソン、M.、マッシー、D.、およびS.ローズ、 "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]ファーガソン、P.およびD. Senie、 "ネットワーク入力フィルタリング：IP Source Address Spoofingを使うサービス妨害Attacksを破り"、BCP 38、RFC 2827、2000年5月。
[BCP84] Baker, F. and P. Savola, "Ingress Filtering for Multihomed Networks", BCP 84, RFC 3704, March 2004.
[BCP84]ベイカー、F.およびP. Savola、 "マルチホームネットワークの入力フィルタリング"、BCP 84、RFC 3704、2004年3月。
Authors' Addresses
著者のアドレス
Joao Damas Internet Systems Consortium, Inc. 950 Charter Street Redwood City, CA 94063 US
ジョアンダマインターネットシステムコンソーシアム株式会社950憲章通りカリフォルニア州レッドウッドシティー94063米国
Phone: +1 650 423 1300 EMail: Joao_Damas@isc.org URI: http://www.isc.org/
電話：+1 650 423 1300 Eメール：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
フレデリックA. C.ネベスNIC.br / Registro.brのAv。国連、11541、7サンパウロ、SP 04578から000 BR
Phone: +55 11 5509 3511 EMail: fneves@registro.br URI: http://registro.br/
電話：+55 11 5509 3511 Eメール：URI fneves@registro.br：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.
この文書とここに含まれている情報は、基礎とCONTRIBUTOR「そのまま」、ORGANIZATION HE / SHEが表すまたはインターネットSOCIETY、（もしあれば）を後援し、IETF TRUST ANDインターネットエンジニアリングタスクフォース放棄ALLに設けられています。保証は、明示または黙示、この情報の利用および特定目的に対する権利または商品性または適合性の黙示の保証を侵害しない任意の保証がこれらに限定されません。
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.
IPRの開示のコピーが利用できるようにIETF事務局とライセンスの保証に行われた、または本仕様の実装者または利用者がそのような所有権の使用のための一般的なライセンスまたは許可を取得するために作られた試みの結果を得ることができますhttp://www.ietf.org/iprのIETFのオンライン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-ipr@ietf.orgのIETFに情報を記述してください。