Network Working Group A. Hubert
Request for Comments: 5452 Netherlabs Computer Consulting BV.
Updates: 2181 R. van Mook
Category: Standards Track Equinix
January 2009
Measures for Making DNS More Resilient against Forged Answers
Status of This Memo
このメモのステータス
This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited.
この文書は、インターネットコミュニティのためのインターネット標準トラックプロトコルを指定し、改善のための議論と提案を要求します。このプロトコルの標準化状態と状態への「インターネット公式プロトコル標準」（STD 1）の最新版を参照してください。このメモの配布は無制限です。
Copyright Notice
著作権表示
Copyright (c) 2009 IETF Trust and the persons identified as the document authors. All rights reserved.
著作権（C）2009 IETF信託とドキュメントの作成者として特定の人物。全著作権所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/ license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document.
この文書では、BCP 78と、この文書の発行日に有効なIETFドキュメント（http://trustee.ietf.org/ライセンス情報）に関連IETFトラストの法律の規定に従うものとします。彼らは、この文書に関してあなたの権利と制限を説明するように、慎重にこれらの文書を確認してください。
Abstract
抽象
The current Internet climate poses serious threats to the Domain Name System. In the interim period before the DNS protocol can be secured more fully, measures can already be taken to harden the DNS to make 'spoofing' a recursing nameserver many orders of magnitude harder.
現在のインターネット環境は、ドメインネームシステムに深刻な脅威をもたらします。 DNSプロトコルは、より完全に固定することができる前中間連結会計期間では、対策がすでに何桁は難しい「なりすまし」再帰ネームサーバを作るためにDNSのセキュリティを強化するために撮影することができます。
Even a cryptographically secured DNS benefits from having the ability to discard bogus responses quickly, as this potentially saves large amounts of computation.
これは潜在的に計算を大量に保存して、すぐに偽の応答を破棄する能力を有するからであっても、暗号で保護DNSのメリット。
By describing certain behavior that has previously not been standardized, this document sets out how to make the DNS more resilient against accepting incorrect responses. This document updates RFC 2181.
以前に標準化されていない特定の動作を記述することで、この文書は間違った応答を受け入れるに対するDNSがより弾力作る方法を設定します。この文書は、RFC 2181に更新します。
Table of Contents
目次
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Requirements and Definitions . . . . . . . . . . . . . . . . . 4
2.1. Definitions . . . . . . . . . . . . . . . . . . . . . . . 4
2.2. Key Words . . . . . . . . . . . . . . . . . . . . . . . . 5
3. Description of DNS Spoofing . . . . . . . . . . . . . . . . . 5
4. Detailed Description of Spoofing Scenarios . . . . . . . . . . 6
4.1. Forcing a Query . . . . . . . . . . . . . . . . . . . . . 6
4.2. Matching the Question Section . . . . . . . . . . . . . . 7
4.3. Matching the ID Field . . . . . . . . . . . . . . . . . . 7
4.4. Matching the Source Address of the Authentic Response . . 7
4.5. Matching the Destination Address and Port of the
Authentic Response . . . . . . . . . . . . . . . . . . . . 8
4.6. Have the Response Arrive before the Authentic Response . . 8
5. Birthday Attacks . . . . . . . . . . . . . . . . . . . . . . . 9
6. Accepting Only In-Domain Records . . . . . . . . . . . . . . . 9
7. Combined Difficulty . . . . . . . . . . . . . . . . . . . . . 10
7.1. Symbols Used in Calculation . . . . . . . . . . . . . . . 10
7.2. Calculation . . . . . . . . . . . . . . . . . . . . . . . 11
8. Discussion . . . . . . . . . . . . . . . . . . . . . . . . . . 12
8.1. Repetitive Spoofing Attempts for a Single Domain Name . . 13
9. Forgery Countermeasures . . . . . . . . . . . . . . . . . . . 13
9.1. Query Matching Rules . . . . . . . . . . . . . . . . . . . 13
9.2. Extending the Q-ID Space by Using Ports and Addresses . . 14
9.2.1. Justification and Discussion . . . . . . . . . . . . . 14
9.3. Spoof Detection and Countermeasure . . . . . . . . . . . . 15
10. Security Considerations . . . . . . . . . . . . . . . . . . . 15
11. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 16
12. References . . . . . . . . . . . . . . . . . . . . . . . . . . 16
12.1. Normative References . . . . . . . . . . . . . . . . . . . 16
12.2. Informative References . . . . . . . . . . . . . . . . . . 17
This document describes several common problems in DNS implementations, which, although previously recognized, remain largely unsolved. Besides briefly recapping these problems, this document contains rules that, if implemented, make complying resolvers vastly more resistant to the attacks described. The goal is to make the existing DNS as secure as possible within the current protocol boundaries.
この文書は、以前に認識ものの、大部分は未解決のままのDNS実装では、いくつかの一般的な問題について説明します。簡単にこれらの問題をリキャップのほかに、このドキュメントは、実装されている場合、説明された攻撃への準拠リゾルバが大幅より耐性にルールが含まれています。目標は、現在のプロトコル境界内で可能な限り既存のDNSが安全なようにすることです。
The words below are aimed at authors of resolvers: it is up to operators to decide which nameserver implementation to use, or which options to enable. Operational constraints may override the security concerns described below. However, implementations are expected to allow an operator to enable functionality described in this document.
以下の単語は、リゾルバの作者を目的としている：それは実装が使用するネームサーバ、または可能にするためにどのオプションを決定するために事業者に任されています。運用制約は、以下のセキュリティ上の懸念を無効にすることができます。しかし、実装は、オペレータが、この文書で説明する機能を有効にすることを可能にすることが期待されます。
Almost every transaction on the Internet involves the Domain Name System, which is described in [RFC1034], [RFC1035], and beyond.
インターネット上のほぼすべてのトランザクションは、[RFC1034]に記述されているドメインネームシステム、[RFC1035]を含み、以降。
Additionally, it has recently become possible to acquire Secure Socket Layer/Transport Layer Security (SSL/TLS) certificates with no other confirmation of identity than the ability to respond to a verification email sent via SMTP ([RFC5321]) -- which generally uses DNS for its routing.
一般的に使用されます - さらに、それは最近、SMTPを介して送信確認メールに応答する能力（[RFC5321]）よりも、アイデンティティの無い他の確認とのSecure Socket Layer /トランスポート層セキュリティ（SSL / TLS）証明書を取得することが可能になってきましたそのルーティングのためのDNS。
In other words, any party that (temporarily) controls the Domain Name System is in a position to reroute most kinds of Internet transactions, including the verification steps in acquiring an SSL/ TLS certificate for a domain. This in turn means that even transactions protected by SSL/TLS could be diverted.
言い換えれば、（一時的に）ドメインネームシステムを制御当事者は、ドメインのSSL / TLS証明書を取得する際の検証手順を含むインターネット取引のほとんどの種類を、再ルーティングする立場にあります。これは、順番にSSL / TLSで保護しても取引が流用できることを意味しています。
It is entirely conceivable that such rerouted traffic could be used to the disadvantage of Internet users.
このような再ルーティングトラフィックがインターネットユーザーの不利益に使用することができることを全く考えられます。
These and other developments have made the security and trustworthiness of DNS of renewed importance. Although the DNS community is working hard on finalizing and implementing a cryptographically enhanced DNS protocol, steps should be taken to make sure that the existing use of DNS is as secure as possible within the bounds of the relevant standards.
これらおよび他の発展は新たな重要性のDNSのセキュリティと信頼性を作ってきました。 DNSコミュニティは、暗号強化DNSプロトコルを最終決定と実施に努力しているが、ステップは、DNSの既存の使用は、関連する規格の範囲内で可能な限り安全であることを確認するために取られるべきです。
It should be noted that the most commonly used resolvers currently do not perform as well as possible in this respect, making this document of urgent importance.
最も一般的に使用されるリゾルバは現在、緊急の重要性のこの文書を作り、この点で可能な限り行わないことに留意すべきです。
A thorough analysis of risks facing DNS can be found in [RFC3833].
DNSが直面するリスクの徹底的な分析は、[RFC3833]で見つけることができます。
This document expands on some of the risks mentioned in RFC 3833, especially those outlined in the sections on "ID Guessing and Query Prediction" and "Name Chaining". Furthermore, it emphasizes a number of existing rules and guidelines embodied in the relevant DNS protocol specifications. The following also specifies new requirements to make sure the Domain Name System can be relied upon until a more secure protocol has been standardized and deployed.
この文書は、RFC 3833に記載されたリスクの一部、「ID推測や問合せ予測」と「名前の連鎖」のセクションで概説特に上で展開します。さらに、それは、関連するDNSプロトコル仕様で具現既存のルールおよびガイドラインの数を強調する。以下は、よりセキュアなプロトコルが標準化され、展開されるまでドメインネームシステムが頼ることができることを確認するために新たな要件を指定します。
It should be noted that even when all measures suggested below are implemented, protocol users are not protected against third parties with the ability to observe, modify, or inject packets in the traffic of a resolver.
以下の提案すべての措置が実施された場合でも、プロトコルユーザーは、観察、変更、またはレゾルバのトラフィックでパケットを注入する能力を第三者から保護されていないことに留意すべきです。
For protocol extensions that offer protection against these scenarios, see [RFC4033] and beyond.
これらのシナリオに対する保護を提供するプロトコル拡張については、[RFC4033]以降を参照してください。
This document uses the following definitions:
このドキュメントでは、次の定義を使用します。
Client: typically a 'stub-resolver' on an end-user's computer.
クライアント：エンドユーザーのコンピュータ上で一般的に「スタブリゾルバ。
Resolver: a nameserver performing recursive service for clients, also known as a caching server, or a full service resolver ([RFC1123], Section 6.1.3.1).
リゾルバ：また、キャッシュサーバとしても知られているクライアントのための再帰的なサービスを行うネームサーバ、またはフルサービスリゾルバ（[RFC1123]、セクション6.1.3.1）。
Stub resolver: a very limited resolver on a client computer, that leaves the recursing work to a full resolver.
スタブリゾルバ：フルリゾルバへの再帰の仕事を残して、クライアントコンピュータ上で非常に限られたリゾルバ、。
Query: a question sent out by a resolver, typically in a UDP packet
クエリ：一般的にUDPパケットで、リゾルバから送信された質問
Response: the answer sent back by an authoritative nameserver, typically in a UDP packet.
回答：一般的にUDPパケットで、権限ネームサーバから送り返された答え。
Third party: any entity other than the resolver or the intended recipient of a question. The third party may have access to an arbitrary authoritative nameserver, but has no access to packets transmitted by the resolver or authoritative server.
サードパーティ：リゾルバや質問の意図した受信者以外の任意のエンティティ。第三者は、任意の権威あるネームサーバへのアクセス権を持っているが、レゾルバや認証サーバによって送信されたパケットへのアクセスを持っていなくてもよいです。
Attacker: malicious third party.
攻撃：悪意のある第三者。
Spoof: the activity of attempting to subvert the DNS process by getting a chosen answer accepted.
偽装：受け入れ選ばれた解答を取得することにより、DNSプロセスを破壊しようとする活動。
Authentic response: the correct answer that comes from the right authoritative server.
本物の応答：右権限のあるサーバーから来て正解。
Target domain name: domain for which the attacker wishes to spoof in an answer
ターゲットドメイン名：攻撃者が答えに偽装したい対象のドメイン
Fake data: response chosen by the attacker.
フェイクデータ：攻撃者によって選ばれた回答。
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]に記載されているように解釈されます。
When certain steps are taken, it is feasible to "spoof" the current deployed majority of resolvers with carefully crafted and timed DNS packets. Once spoofed, a caching server will repeat the data it wrongfully accepted, and make its clients contact the wrong, and possibly malicious, servers.
特定のステップが取られている場合、それは「なりすまし」慎重に細工して、時限DNSパケットとリゾルバの現在の展開過半数に実現可能です。一度偽装され、キャッシュサーバは、それが不当に受け入れられたデータを繰り返すことになりますし、そのクライアントは、間違って、そしておそらく悪質なサーバーに接続します。
To understand how this process works it is important to know what makes a resolver accept a response.
このプロセスは、それをどのように機能するかを理解するには、リゾルバが応答を受け入れる作るかを知ることが重要です。
The following sentence in Section 5.3.3 of [RFC1034] presaged the present problem:
[RFC1034]のセクション5.3.3で次の文は、現在この問題をpresaged：
The resolver should be highly paranoid in its parsing of responses. It should also check that the response matches the query it sent using the ID field in the response.
リゾルバは応答のその解析に非常に偏執的でなければなりません。また、応答は、それが応答でIDフィールドを使用して送信されたクエリと一致していることを確認する必要があります。
DNS data is to be accepted by a resolver if and only if:
DNSデータは、リゾルバ場合にのみによって受け入れられるべきです。
1. The question section of the reply packet is equivalent to that of a question packet currently waiting for a response.
1.応答パケットの質問セクションには、現在の応答を待っている質問パケットと同等です。
2. The ID field of the reply packet matches that of the question packet.
2.応答パケットのIDフィールドは、質問パケットのそれと一致しました。
3. The response comes from the same network address to which the question was sent.
3.応答は、質問が送信されたと同じネットワークアドレスから来ています。
4. The response comes in on the same network address, including port number, from which the question was sent.
4.応答は、質問を送信したポート番号を含め、同じネットワークアドレスに入ってきます。
In general, the first response matching these four conditions is accepted.
一般に、これら4つの条件に合致する最初の応答が受け入れられています。
If a third party succeeds in meeting the four conditions before the response from the authentic nameserver does so, it is in a position to feed a resolver fabricated data. When it does so, we dub it an "attacker", attempting to spoof in fake data.
第三者が本物のネームサーバからの応答がそうする前に、4つの条件を満たしに成功した場合は、データを作製しリゾルバを供給する立場にあります。それはそうするとき、私たちは偽のデータに偽装しようとすると、「攻撃者」、それをダビング。
All conditions mentioned above can theoretically be met by a third party, with the difficulty being a function of the resolver implementation and zone configuration.
上記全ての条件は、理論的には困難がレゾルバ実装とゾーン設定の関数であると共に、第三者によって満たすことができます。
The previous paragraph discussed a number of requirements an attacker must match in order to spoof in manipulated (or fake) data. This section discusses the relative difficulties and how implementation-defined choices impact the amount of work an attacker has to perform to meet said difficulties.
前の段落では、攻撃者が操作（または偽）データに偽装するために一致しなければならない要件の数を検討しました。このセクションでは、相対的な問題を説明し、どのように実装で定義された選択肢は、攻撃者は、前記問題を満たすために実行しなければならない作業の量に影響を与えます。
Some more details can be found in Section 2.2 of [RFC3833].
いくつかの詳細については、[RFC3833]のセクション2.2に記載されています。
Formally, there is no need for a nameserver to perform service except for its operator, its customers, or more generally its users. Recently, open recursing nameservers have been used to amplify denial-of-service attacks.
正式には、その事業者、顧客、またはより一般的にはそのユーザー以外のサービスを実行するためのネームサーバは必要ありません。最近、オープン再帰ネームサーバーは、サービス拒否攻撃を増幅するために使用されています。
Providing full service enables the third party to send the target resolver a query for the domain name it intends to spoof. On receiving this query, and not finding the answer in its cache, the resolver will transmit queries to relevant authoritative nameservers. This opens up a window of opportunity for getting fake answer data accepted.
フルサービスを提供することは、それが偽装する予定のドメイン名のクエリリゾルバのターゲットを送信するために第三者を可能にします。このクエリを受信し、そのキャッシュ内に答えを見つけないで、リゾルバは、関連する権限ネームサーバへのクエリを送信します。これが受け入れられた偽の解答データを取得するための機会の窓を開きます。
Queries may however be forced indirectly, for example, by inducing a mail server to perform DNS lookups.
クエリは、しかし、DNSルックアップを実行するためにメールサーバを誘導することにより、例えば、間接的に強制することができます。
Some operators restrict access by not recursing for unauthorized IP addresses, but only respond with data from the cache. This makes spoofing harder for a third party as it cannot then force the exact moment a question will be asked. It is still possible however to determine a time range when this will happen, because nameservers helpfully publish the decreasing time to live (TTL) of entries in the cache, which indicate from which absolute time onwards a new query could be sent to refresh the expired entry.
一部の事業者は、不正なIPアドレスに対して再帰的ではないことでアクセスを制限するが、唯一のキャッシュからのデータで応答します。それは、その後の質問が要求されます正確な瞬間を強制することはできませんので、これは、サードパーティのために難しくスプーフィングを作ります。ネームサーバは、親切を示しているキャッシュ内のエントリの（TTL）を生きるための減少時間を公開しているため、新たなクエリが期限切れのをリフレッシュするために送信される可能性があり、絶対時間以降、そこからそれは、これが起こるときの時間範囲を決定することがまだ可能ですエントリ。
The time to live of the target domain name's RRSets determines how often a window of opportunity is available, which implies that a short TTL makes spoofing far more viable.
ターゲットドメイン名のRRセットで生活する時間が短いTTLがなりすましはるかに実行可能になることを意味する、機会の窓が利用可能である頻度を決定します。
Note that the attacker might very well have authorized access to the target resolver by virtue of being a customer or employee of its operator. In addition, access may be enabled through the use of reflectors as outlined in [RFC5358].
攻撃者は非常によく、そのオペレータの顧客や従業員であることのおかげで、目標リゾルバへのアクセスを許可している場合があります。 [RFC5358]に概説するように加えて、アクセスは、反射器の使用を介して有効にすることができます。
DNS packets, both queries and responses, contain a question section. Incoming responses should be verified to have a question section that is equivalent to that of the outgoing query.
DNSパケット、両方のクエリと応答は、質問セクションが含まれています。着信応答は、発信クエリと同等の質問セクションを持っていることが確認されなければなりません。
The DNS ID field is 16 bits wide, meaning that if full use is made of all these bits, and if their contents are truly random, it will require on average 32768 attempts to guess. Anecdotal evidence suggests there are implementations utilizing only 14 bits, meaning on average 8192 attempts will suffice.
DNSのIDフィールドは、完全な使用は、これらすべてのビットで構成されている場合、その内容は真にランダムであれば、それは推測する平均32768の試みに必要になることを意味し、16ビット幅です。事例証拠は、14ビットを利用して実装が十分で平均8192の試みに意味がある示唆しています。
Additionally, if the target nameserver can be forced into having multiple identical queries outstanding, the "Birthday Attack" phenomenon means that any fake data sent by the attacker is matched against multiple outstanding queries, significantly raising the chance of success. Further details in Section 5.
ターゲット・ネームサーバは、優れた複数の同一のクエリを持つに強制することができた場合に加え、「誕生日アタック」現象は大幅に成功のチャンスを上げ、攻撃者によって送信された偽のデータが複数の未処理のクエリーに対して一致していることを意味します。第5節でさらなる詳細が表示されます。
It should be noted that meeting this condition entails being able to transmit packets on behalf of the address of the authoritative nameserver. While two Best Current Practice documents ([RFC2827] and [RFC3013] specifically) direct Internet access providers to prevent their customers from assuming IP addresses that are not assigned to them, these recommendations are not universally (nor even widely) implemented.
この条件を満たすことが権限ネームサーバのアドレスに代わってパケットを送信することができるということを伴うことに留意すべきです。 2つの最も良い現在の練習のドキュメント（[RFC2827]と[RFC3013]特異的に）直接インターネットアクセスプロバイダーは、それらに割り当てられていないIPアドレスを仮定してから顧客を防ぐために、一方で、これらの提言は（もさえ広く）が実装され普遍的ではありません。
Many zones have two or three authoritative nameservers, which make matching the source address of the authentic response very likely with even a naive choice having a double digit success rate.
多くのゾーンにも素朴な選択が二桁の成功率を持つ可能性が非常に高い本格的応答の送信元アドレスを一致させる二、三権限ネームサーバを、持っています。
Most recursing nameservers store relative performance indications of authoritative nameservers, which may make it easier to predict which nameserver would originally be queried -- the one most likely to respond the quickest.
最速応答する可能性が最も高いものを - ほとんどの再帰ネームサーバは、それが簡単に元々照会されるであろうネームサーバに予測することがあり権限ネームサーバの相対的なパフォーマンス指標を、保存してください。
Generally, this condition requires at most two or three attempts before it is matched.
それが一致する前に、一般的に、この条件は、ほとんどの二、三の試みで必要です。
4.5. Matching the Destination Address and Port of the Authentic Response
4.5. 本格的な応答の宛先アドレスとポートをマッチング
Note that the destination address of the authentic response is the source address of the original query.
本物の応答の宛先アドレスは、元のクエリの送信元アドレスであることに留意されたいです。
The actual address of a recursing nameserver is generally known; the port used for asking questions is harder to determine. Most current resolvers pick an arbitrary port at startup (possibly at random) and use this for all outgoing queries. In quite a number of cases, the source port of outgoing questions is fixed at the traditional DNS assigned server port number of 53.
再帰ネームサーバの実際のアドレスは、一般的に知られています。質問をするために使用されるポートが決定することが困難です。現在のほとんどのリゾルバは、（おそらくランダムで）起動時に任意のポートを選択し、すべての発信のクエリのためにこれを使用しています。例かなりの数では、出て行くの質問の送信元ポートが53の伝統的なDNS割り当てられたサーバーのポート番号で固定されています。
If the source port of the original query is random, but static, any authoritative nameserver under observation by the attacker can be used to determine this port. This means that matching this conditions often requires no guess work.
元のクエリの送信元ポートがランダムが、静的である場合、攻撃者による観察下でいずれかの権限ネームサーバは、このポートを決定するために使用することができます。これは、この条件に合致することは、多くの場合、全くの推測作業を必要としないことを意味します。
If multiple ports are used for sending queries, this enlarges the effective ID space by a factor equal to the number of ports used.
複数のポートがクエリを送信するために使用される場合、これは使用されるポートの数に等しい係数だけ有効なID空間を拡大します。
Less common resolving servers choose a random port per outgoing query. If this strategy is followed, this port number can be regarded as an additional ID field, again containing up to 16 bits.
あまり一般的解決サーバは、発信クエリごとにランダムポートを選択します。この戦略に従っている場合、このポート番号は、再び16ビットまでを含む、追加のIDフィールドと見なすことができます。
If the maximum ports range is utilized, on average, around 32256 source ports would have to be tried before matching the source port of the original query, as ports below 1024 may be unavailable for use, leaving 64512 options.
最大のポートが使用される範囲であれば、平均して、周りに32256元ポート1024以下のポートが使用できないとすることができるよう64512のオプションを残して、元のクエリの送信元ポートに一致する前に試みなければなりません。
It is in general safe for DNS to use ports in the range 1024-49152 even though some of these ports are allocated to other protocols. DNS resolvers will not be able to use any ports that are already in use. If a DNS resolver uses a port, it will release that port after a short time and migrate to a different port. Only in the case of a high-volume resolver is it possible that an application wanting a particular UDP port suffers a long term block-out.
DNSは、これらのポートのいくつかは、他のプロトコルに割り当てられているにもかかわらず、範囲1024から49152までのポートを使用することが一般的に安全です。 DNSリゾルバは、すでに使用されている任意のポートを使用することはできません。 DNSリゾルバは、ポートを使用している場合、それは短い時間の後、そのポートを解放し、別のポートに移行されます。唯一大量レゾルバの場合には、特定のUDPポートを望むアプリケーションは、長期ブロックアウトを被る可能性があります。
It should be noted that a firewall will not prevent the matching of this address, as it will accept answers that (appear to) come from the correct address, offering no additional security.
正しいアドレスから来た（ように見える）の答えを受け入れるようにファイアウォールが追加のセキュリティを提供していない、このアドレスのマッチングを妨げないことに留意されたいです。
Once any packet has matched the previous four conditions (plus possible additional conditions), no further responses are generally accepted.
任意のパケットは、前の4つの条件（プラス可能な追加条件を）マッチしていたら、それ以上の応答は、一般的に受け入れられません。
This means that the third party has a limited time in which to inject its spoofed response. For calculations, we will assume a window in order of at most 100 ms (depending on the network distance to the authentic authoritative nameserver).
これは、第三者がその偽装された応答を注入することで、限られた時間を有することを意味します。計算では、我々は（本物の権限ネームサーバへのネットワーク距離に応じて）最大100ミリ秒のオーダーで窓を仮定します。
This time period can be far longer if the authentic authoritative nameservers are (briefly) overloaded by queries, perhaps by the attacker.
本物の権威ネームサーバは（簡単に）おそらく、攻撃者により、クエリによってオーバーロードされている場合、この期間ははるかに長くすることができます。
The so-called "birthday paradox" implies that a group of 23 people suffices to have a more than even chance of having two or more members of the group share a birthday.
いわゆる「誕生日のパラドックスは、」23人のグループが、グループのシェアの2人の以上のメンバーの誕生日を持つのも、偶然以上のものを持っていればよいことを意味します。
An attacker can benefit from this exact phenomenon if it can force the target resolver to have multiple equivalent (identical QNAME, QTYPE, and QCLASS) outstanding queries at any one time to the same authoritative server.
それは、同じ認証サーバに一度に複数の同等（同一QNAME、QTYPEとQCLASS）を有する未処理のクエリをターゲットリゾルバを強制することができる場合、攻撃者は、この正確な現象から利益を得ることができます。
Any packet the attacker sends then has a much higher chance of being accepted because it only has to match any of the outstanding queries for that single domain. Compared to the birthday analogy above, of the group composed of queries and responses, the chance of having any of these share an ID rises quickly.
それだけでその単一ドメインのために未処理のクエリーのいずれかに一致する必要があるため、攻撃者は、その後、送信するすべてのパケットが受け入れられているのはるかに高い可能性があります。クエリと応答で構成されるグループの上記誕生日の類推、と比較すると、IDこれらの株のいずれかを有するのチャンスが急速に上昇します。
As long as small numbers of queries are sent out, the chance of successfully spoofing a response rises linearly with the number of outstanding queries for the exact domain and nameserver.
クエリの小さな番号が送信されている限り、成功した応答を偽装する可能性が正確なドメインネームサーバのための優れたクエリーの数で直線的に上昇します。
For larger numbers, this effect is less pronounced.
より多くの場合、この効果はそれほど顕著ではありません。
More details are available in US-CERT [vu-457875].
詳細は、US-CERT [VU-457875]でご利用いただけます。
Responses from authoritative nameservers often contain information that is not part of the zone for which we deem it authoritative. As an example, a query for the MX record of a domain might get as its responses a mail exchanger in another domain, and additionally the IP address of this mail exchanger.
権威ネームサーバからの応答は、多くの場合、我々はそれが信頼できると判断れるゾーンの一部ではない情報が含まれています。例として、ドメインのMXレコードのクエリは、その応答として、別のドメインのメール交換、およびこのメール交換器のさらにIPアドレスを取得する可能性があります。
If accepted uncritically, the resolver stands the chance of accepting data from an untrusted source. Care must be taken to only accept data if it is known that the originator is authoritative for the QNAME or a parent of the QNAME.
無批判に受け入れた場合、リゾルバは信頼できないソースからのデータを受け入れるのチャンスを立っています。ケアは、発信者がQNAMEまたはQNAMEの親のための権威であることが知られている場合にのみデータを受け入れるように注意する必要があります。
One very simple way to achieve this is to only accept data if it is part of the domain for which the query was intended.
これを達成するための1つの非常に単純な方法は、クエリが意図されたドメインの一部である場合にのみデータを受け入れることです。
Given a known or static destination port, matching ID field, the source and destination address requires on average in the order of 2 * 2^15 = 65000 packets, assuming a zone has 2 authoritative nameservers.
IDフィールドと一致する既知のまたは静的宛先ポート、所与、送信元および宛先アドレスは、ゾーン2つの権威あるネームサーバを有していると仮定すると、2×2 ^ 15 = 65000パケットのために平均して必要とします。
If the window of opportunity available is around 100 ms, as assumed above, an attacker would need to be able to briefly transmit 650000 packets/s to have a 50% chance to get spoofed data accepted on the first attempt.
利用可能な機会の窓は、100ミリ秒程度である場合には、上記の仮定として、攻撃者は簡単に最初の試みで受け入れ偽装されたデータを取得するために、50％の確率を持っている650000パケット/秒を送信できるようにする必要があります。
A realistic minimal DNS response consists of around 80 bytes, including IP headers, making the packet rate above correspond to a respectable burst of 416 Mbit/s.
現実的な最小限のDNS応答は、416メガビット/秒の立派バーストに対応する上記パケットレートを行う、IPヘッダを含む約80バイトから成ります。
As of mid-2006, this kind of bandwidth was not common but not scarce either, especially among those in a position to control many servers.
2006年半ばの時点では、帯域幅のこの種は、特に多くのサーバーを管理する立場にあるものの中に、いずれかの乏しい一般的ではなく、ありませんでした。
These numbers change when a window of a full second is assumed, possibly because the arrival of the authentic response can be prevented by overloading the bona fide authoritative hosts with decoy queries. This reduces the needed bandwidth to 42 Mbit/s.
完全な第二の窓を想定した場合、これらの数字は、本物の応答の到着がデコイクエリと善意の権威ホストをオーバーロードすることによって防止することができる可能性があるため、変更します。これは、42ビット/ sに必要な帯域幅を削減します。
If, in addition, the attacker is granted more than a single chance and allowed up to 60 minutes of work on a domain with a time to live of 300 seconds, a meager 4 Mbit/s suffices for a 50% chance at getting fake data accepted. Once equipped with a longer time, matching condition 1 mentioned above is straightforward -- any popular domain will have been queried a number of times within this hour, and given the short TTL, this would lead to queries to authoritative nameservers, opening windows of opportunity.
加えて、攻撃者は単一のチャンス以上に付与され、300秒の生存時間を持つドメイン上の仕事の60分まで許容、場合、わずかな4Mビット/ sが偽のデータを得ることで、50％の確率で十分受け入れました。一度上記のマッチング条件1は簡単です、長い時間を装備 - 、これは機会の窓を開け、権限ネームサーバへのクエリにつながるあらゆる人気のドメインが、この時間内回数を照会し、短いTTLを与えられているでしょう。
Assume the following symbols are used:
以下のシンボルが使用されていると仮定します。
I: Number distinct IDs available (maximum 65536)
I：使用可能な数の個別のID（最大65536）
P: Number of ports used (maximum around 64000 as ports under 1024 are not always available, but often 1)
P：（64000付近で最大1024の下のポートが常に利用可能ではないように、しばしば1）使用されるポートの数
N: Number of authoritative nameservers for a domain (averages around 2.5)
N：ドメインの権威ネームサーバの数（平均値2.5前後）
F: Number of "fake" packets sent by the attacker
F：攻撃者によって送信された「偽」パケットの数
R: Number of packets sent per second by the attacker
R：攻撃者によって1秒あたりに送信されたパケットの数
W: Window of opportunity, in seconds. Bounded by the response time of the authoritative servers (often 0.1s)
W：機会の窓（秒）。権威サーバ（多くの場合、0.1秒）の応答時間によって制限さ
D: Average number of identical outstanding queries of a resolver (typically 1, see Section 5)
D：レゾルバの同一の未処理クエリの平均数（典型的には1、セクション5を参照のこと）
A: Number of attempts, one for each window of opportunity
A：試行回数、機会のウィンドウごとに1
The probability of spoofing a resolver is equal to the amount of fake packets that arrive within the window of opportunity, divided by the size of the problem space.
レゾルバをスプーフィングの可能性は、問題の空間の大きさで割った機会のウィンドウ内に到着偽パケットの量に等しいです。
When the resolver has 'D' multiple identical outstanding queries, each fake packet has a proportionally higher chance of matching any of these queries. This assumption only holds for small values of 'D'.
リゾルバは、「D」複数の同一の未処理のクエリを有する場合、各偽のパケットは、これらのクエリのいずれかに一致する比例高い機会を有します。この仮定は「D」の値が小さいために保持します。
In symbols, if the probability of being spoofed is denoted as P_s:
シンボルでは、詐称される確率はP_Sと表記されている場合：
D * F
P_s = ---------
N * P * I
It is more useful to reason not in terms of aggregate packets but to convert to packet rate, which can easily be converted to bandwidth if needed.
集約パケットの観点ではない理由になく、簡単に、必要に応じて帯域幅に変換することができパケットレートに変換することがより便利です。
If the window of opportunity length is 'W' and the attacker can send 'R' packets per second, the number of fake packets 'F' that are candidates to be accepted is:
機会の長さの窓が「W」であると、攻撃者が毎秒「R」パケットを送信することができた場合は、受け入れ候補となる偽のパケット「F」の数は、次のとおりです。
D * R * W
F = R * W -> P_s = ---------
N * P * I
Finally, to calculate the combined chance 'P_cs' of spoofing over a chosen time period 'T', it should be realized that the attacker has a new window of opportunity each time the TTL 'TTL' of the target domain expires. This means that the number of attempts 'A' is equal to 'T / TTL'.
最後に、選択した期間「T」の上に組み合わせチャンスなりすましの「P_cs」を算出するために、攻撃者がターゲットドメインのTTL「TTL」は有効期限が切れるたびに、チャンスの新しいウィンドウを持っていることを理解すべきです。これは試み「A」の個数が「T / TTL」に等しいことを意味します。
To calculate the combined chance of at least one success, the following formula holds:
少なくとも一つの成功の組み合わせチャンスを計算するには、以下の式が成り立ちます：
(T / TTL)
A ( D * R * W )
P_cs = 1 - ( 1 - P_s ) = 1 - ( 1 - --------- )
( N * P * I )
When common numbers (as listed above) for D, W, N, P, and I are inserted, this formula reduces to:
場合、共通番号（上記のように）D、W、N、P、及びIが挿入されるため、この式は、に帰着します。
(T / TTL)
( R )
P_cs = 1 - ( 1 - ------- )
( 1638400 )
From this formula, it can be seen that, if the nameserver implementation is unchanged, only raising the TTL offers protection. Raising N, the number of authoritative nameservers, is not feasible beyond a small number.
この式から、ネームサーバの実装が唯一のTTLを上げると保護を提供する、変更されていない場合、ことがわかります。調達N、権限ネームサーバの数は、少数を超えた現実的ではありません。
For the degenerate case of a zero-second TTL, a window of opportunity opens for each query sent, making the effective TTL equal to 'W' above, the response time of the authoritative server.
ゼロ秒TTLの縮退したケースでは、機会の窓は、上記「W」、権威サーバーの応答時間に等しい有効なTTLを作成、送信される各クエリに対して開きます。
This last case also holds for spoofing techniques that do not rely on TTL expiry, but use repeated and changing queries.
この最後の場合も、TTLの有効期限に依存しているが、繰り返し、変更するクエリを使用していないスプーフィング技術についても同様です。
The calculations above indicate the relative ease with which DNS data can be spoofed. For example, using the formula derived earlier on an RRSet with a 3600 second TTL, an attacker sending 7000 fake response packets/s (a rate of 4.5 Mbit/s), stands a 10% chance of spoofing a record in the first 24 hours, which rises to 50% after a week.
上記の計算は、DNSデータを偽装することが可能な相対的容易さを示します。例えば、3600秒TTLと以前の資源レコード集合に由来する式を使用して、攻撃者が7000偽の応答パケット/秒（4.5メガビット/秒の速度）を送信、最初の24時間内のレコードをスプーフィング10％の確率を表し、一週間後に50％に上昇します。
For an RRSet with a TTL of 60 seconds, the 10% level is hit after 24 minutes, 50% after less than 3 hours, 90% after around 9 hours.
60秒のTTLと資源レコード集合のために、10％のレベルは24分未満、3時間後に50％、約9時間後に90％の後にヒットします。
For some classes of attacks, the effective TTL is near zero, as noted above.
上記のような攻撃のいくつかのクラスのために、効果的なTTLがゼロに近いです。
Note that the attacks mentioned above can be detected by watchful server operators - an unexpected incoming stream of 4.5 Mbit/s of packets might be noticed.
パケットの4.5メガビット/秒の予想外の着信ストリームは気づいたかもしれない - 上記の攻撃は気を配っサーバーオペレータによって検出することができることに注意してください。
An important assumption however in these calculations is a known or static destination port of the authentic response.
しかし、これらの計算における重要な仮定は、本物の応答の既知または静的宛先ポートです。
If that port number is unknown and needs to be guessed as well, the problem space expands by a factor of 64000, leading the attacker to need in excess of 285Gb/s to achieve similar success rates.
そのポート番号が不明であると同様に推測する必要がある場合は、問題空間は、同様の成功率を達成するために285Gb / sを超える必要に攻撃をリードし、64000倍に拡大します。
Such bandwidth is not generally available, nor is it expected to be so in the foreseeable future.
このような帯域幅は、一般的に利用できない、またそれは予見可能な将来においてそうであることが予想されます。
Note that some firewalls may need reconfiguring if they are currently set up to only allow outgoing queries from a single DNS source port.
彼らは現在、単一のDNSソースポートからの発信クエリを許可するように設定されている場合、一部のファイアウォールは、再構成必要があるかもしれないことに注意してください。
Techniques are available to use an effectively infinite number of queries to achieve a desired spoofing goal. In the math above, this reduces the effective TTL to 0.
テクニックは、希望なりすましの目標を達成するために、クエリの事実上無限数を使用してご利用いただけます。上記の数学では、これは0に有効なTTLを減少させます。
If such techniques are employed, using the same 7000 packets/s rate mentioned above, and using 1 source port, the spoofing chance rises to 50% within 7 seconds.
そのような技術は、/ sの速度は、上述した同じ7000個のパケットを使用して、1つのソースポートを使用して、使用される場合、なりすましの可能性は7秒以内に50％まで上昇します。
If 64000 ports are used, as recommended in this document, using the same query rate, the 50% level is reached after around 116 hours.
64000個のポートが使用される場合、この文書で推奨されているように、同じクエリレートを使用して、50％のレベルは、約116時間後に達成されます。
A resolver implementation MUST match responses to all of the following attributes of the query:
リゾルバの実装では、クエリの次の属性のすべてに回答と一致する必要があります。
o Source address against query destination address
問い合わせ先アドレスに対するOソースアドレス
o Destination address against query source address
クエリー送信元アドレスに対するO宛先アドレス
o Destination port against query source port
クエリー送信元ポートに対するO宛先ポート
o Query ID
クエリID
o Query name
Oクエリ名
o Query class and type
O Queryクラスとタイプ
before applying DNS trustworthiness rules (see Section 5.4.1 of [RFC2181]).
DNSの信頼性ルールを適用する前に（[RFC2181]のセクション5.4.1を参照してください）。
A mismatch and the response MUST be considered invalid.
不一致と応答が無効であると見なされなければなりません。
Resolver implementations MUST:
リゾルバ実装する必要があります。
o Use an unpredictable source port for outgoing queries from the range of available ports (53, or 1024 and above) that is as large as possible and practicable;
O可能かつ実行可能な限り大きい利用可能なポート（53、以上1024）の範囲から発信クエリの予測不可能なソースポートを使用します。
o Use multiple different source ports simultaneously in case of multiple outstanding queries;
O複数の未処理のクエリの場合、同時に複数の異なる送信元ポートを使用します。
o Use an unpredictable query ID for outgoing queries, utilizing the full range available (0-65535).
O利用可能な全範囲（0〜65535）を利用し、送信クエリの予測不可能なクエリIDを使用します。
Resolvers that have multiple IP addresses SHOULD use them in an unpredictable manner for outgoing queries.
複数のIPアドレスを持っているリゾルバは、発信クエリの予測不可能な方法でそれらを使用すべきです。
Resolver implementations SHOULD provide means to avoid usage of certain ports.
レゾルバ実装が特定のポートの使用を回避する手段を提供すべきです。
Resolvers SHOULD favor authoritative nameservers with which a trust relation has been established; stub-resolvers SHOULD be able to use Transaction Signature (TSIG) ([RFC2845]) or IPsec ([RFC4301]) when communicating with their recursive resolver.
リゾルバは、信頼関係が確立された権威ネームサーバを好むべきです。スタブリゾルバは、それらの再帰リゾルバと通信するときにトランザクション署名（TSIG）（[RFC2845]）やIPsec（[RFC4301]）を使用することができるべきです。
In case a cryptographic verification of response validity is available (TSIG, SIG(0)), resolver implementations MAY waive above rules, and rely on this guarantee instead.
場合の応答有効性の暗号検証が利用可能である（TSIG、SIG（0））、リゾルバの実装は、ルール上に放棄し、代わりに、この保証に依存してもよいです。
Proper unpredictability can be achieved by employing a high quality (pseudo-)random generator, as described in [RFC4086].
[RFC4086]に記載されているように、適切な予測不可能性は、高品質の（擬似）乱数発生器を使用することによって達成することができます。
Since an attacker can force a full DNS resolver to send queries to the attacker's own nameservers, any constant or sequential state held by such a resolver can be measured, and it must not be trivially easy to reverse engineer the resolver's internal state in a way that allows low-cost, high-accuracy prediction of future state.
攻撃者は攻撃者自身のネームサーバにクエリを送信するために、完全なDNSリゾルバを強制することができますので、そのようなリゾルバが保持している任意の定数またはシーケンシャル状態を測定することができ、そしてそのようにリゾルバの内部状態をリバースエンジニアリングすることが自明簡単ではない必要があります将来の状態の低コスト、高精度な予測が可能になります。
A full DNS resolver with only one or a small number of upstream-facing endpoints is effectively using constants for IP source address and UDP port number, and these are very predictable by potential attackers, and must therefore be avoided.
1つまたは上流に面したエンドポイントの数が少ないとの完全なDNSリゾルバは、効果的にIPソースアドレスとUDPポート番号の定数を使用しており、これらは、潜在的な攻撃者によって非常に予測可能であるため、避けなければなりません。
A full DNS resolver that uses a simple increment to get its next DNS query ID is likewise very predictable and so very spoofable.
その次のDNSクエリIDを取得するには、単純な増分を使用して、完全なDNSリゾルバは、同様に非常に予測可能なので、非常に偽造される可能性があり。
Finally, weak random number generators have been shown to expose their internal state, such that an attacker who witnesses several sequential "random" values can easily predict the next ones. A crypto-strength random number generator is one whose output cannot be predicted no matter how many successive values are witnessed.
最後に、弱い乱数発生器は、そのような証人いくつかの連続「ランダム」の値は簡単に次のものを予測することができ、攻撃者という、彼らの内部状態を公開することが示されています。暗号強度の乱数発生器は、その出力に関係なく、連続した値が目撃されているどのように多くの予測することはできませんものです。
If a resolver detects that an attempt is being made to spoof it, perhaps by discovering that many packets fail the criteria as outlined above, it MAY abandon the UDP query and re-issue it over TCP. TCP, by the nature of its use of sequence numbers, is far more resilient against forgery by third parties.
リゾルバが試みは、おそらく上記で概説したように、多くのパケットが基準を満たさないことを発見することで、それを偽装するために行われていることを検出した場合、それはTCP上のUDPクエリと再発行、それを放棄することができます。 TCPは、シーケンス番号の使用の性質により、第三者による偽造に対するはるかに弾力性のあります。
This document provides clarification of the DNS specification to decrease the probability that DNS responses can be successfully forged. Recommendations found above should be considered complementary to possible cryptographical enhancements of the domain name system, which protect against a larger class of attacks.
この文書では、DNS応答が正常に偽造できる確率を減少させるためにDNSの仕様の明確化を提供します。上記見つかった勧告は、攻撃の大きなクラスから守るドメインネームシステムの可能な暗号学的機能強化、と相補的な考慮すべきです。
This document recommends the use of UDP source port number randomization to extend the effective DNS transaction ID beyond the available 16 bits.
この文書では、利用可能な16ビットを超えて効果的なDNSトランザクションIDを拡張するためのUDP送信元ポート番号のランダム化を使用することを推奨しています。
A resolver that does not implement the recommendations outlined above can easily be forced to accept spoofed responses, which in turn are passed on to client computers -- misdirecting (user) traffic to possibly malicious entities.
上記で概説した勧告を実装していないリゾルバを簡単に順番にクライアントコンピュータに渡され、偽装された応答を、受け入れることを強制することができます - （ユーザー）トラフィックにおそらく悪質なエンティティをmisdirecting。
This document directly impacts the security of the Domain Name System, implementers are urged to follow its recommendations.
このドキュメントに直接影響するドメインネームシステムのセキュリティは、実装者がその勧告に従うよう促しています。
Most security considerations can be found in Sections 4 and 5, while proposed countermeasures are described in Section 9.
提案された対策は、セクション9に記載されている間、ほとんどのセキュリティの考慮事項は、セクション4および5に記載されています。
For brevity's sake, in lieu of repeating the security considerations references, the reader is referred to these sections.
簡潔のために、セキュリティの考慮事項参照を繰り返す代わりに、読者はこれらのセクションと呼ばれます。
Nothing in this document specifies specific algorithms for operators to use; it does specify algorithms implementations SHOULD or MUST support.
本書の内容は、オペレータが使用する特定のアルゴリズムを指定します。それは、アルゴリズムの実装は、またはサポートしなければならないように指定ありません。
It should be noted that the effects of source port randomization may be dramatically reduced by NAT devices that either serialize or limit in volume the UDP source ports used by the querying resolver.
ソースポートのランダム化の効果が劇的ボリュームにクエリリゾルバによって使用されるUDPソースポートをシリアル化または限界のいずれかNATデバイスによって減少させることができることに留意すべきです。
DNS recursive servers sitting behind at NAT or a statefull firewall may consume all available NAT translation entries/ports when operating under high query load. Port randomization will cause translation entries to be consumed faster than with fixed query port.
DNS再帰サーバは、NATでの背後に座ったり、高いクエリ負荷運転時にステートフルファイアウォールは、すべての利用可能なNAT変換エントリ/ポートを消費することがあります。ポートのランダム化は、変換エントリは、固定されたクエリ・ポートよりも速く消費されることになります。
To avoid this, NAT boxes and statefull firewalls can/should purge outgoing DNS query translation entries 10-17 seconds after the last outgoing query on that mapping was sent. [RFC4787]-compliant devices need to treat UDP messages with port 53 differently than most other UDP protocols.
そのマッピング上の最後の発信クエリが送信された後にこの問題を回避するには、NATボックスやステートフルファイアウォールは発信/ DNSクエリ変換エントリ10-17秒をパージする必要がありますすることができます。 [RFC4787]準拠のデバイスは異なり、他のほとんどのUDPプロトコルよりもポート53でUDPメッセージを処理する必要があります。
To minimize the potential that port/state exhaustion attacks can be staged from the outside, it is recommended that services that generate a number of DNS queries for each connection should be rate limited. This applies in particular to email servers.
ポート/状態枯渇攻撃は外部から上演できることの可能性を最小限にするために、各接続のDNSクエリの数を生成するサービスはレートが制限することをお勧めします。これは、電子メールサーバーに当てはまります。
Source port randomization in DNS was first implemented and possibly invented by Dan J. Bernstein.
DNSでの送信元ポートのランダム化は、最初に実装されており、おそらくダン・J.バーンスタインによって発明されました。
Although any mistakes remain our own, the authors gratefully acknowledge the help and contributions of: Stephane Bortzmeyer Alfred Hoenes Peter Koch Sean Leach Norbert Sendetzky Paul Vixie Florian Weimer Wouter Wijngaards Dan Wing
ステファンBortzmeyerアルフレッドHoenesピーター・コッホショーン・リーチノルベルトSendetzkyポール・ヴィクシーフロリアンWeimerさんはWouter Wijngaardsダン・ウィング：間違いは私たち自身の残っているが、著者は感謝の助けとの貢献を認めます
[RFC1034] Mockapetris, P., "Domain names - concepts and facilities", STD 13, RFC 1034, November 1987.
[RFC1034] Mockapetris、P.、 "ドメイン名 - 概念と設備"、STD 13、RFC 1034、1987年11月。
[RFC1035] Mockapetris, P., "Domain names - implementation and specification", STD 13, RFC 1035, November 1987.
[RFC1035] Mockapetris、P.、 "ドメイン名 - 実装及び仕様"、STD 13、RFC 1035、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月。
[RFC2181] Elz, R. and R. Bush, "Clarifications to the DNS Specification", RFC 2181, July 1997.
"DNS仕様の明確化" [RFC2181]エルツ、R.とR.ブッシュ、RFC 2181、1997年7月。
[RFC2827] 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.
[RFC2827]ファーガソン、P.およびD. Senie、 "ネットワーク入力フィルタリング：IP Source Address Spoofingを使うサービス攻撃の敗北拒否"、BCP 38、RFC 2827、2000年5月。
[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月。
[RFC3013] Killalea, T., "Recommended Internet Service Provider Security Services and Procedures", BCP 46, RFC 3013, November 2000.
[RFC3013] Killalea、T.、 "推奨インターネットサービスプロバイダのセキュリティサービスと手続き"、BCP 46、RFC 3013、2000年11月。
[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月。
[RFC4086] Eastlake, D., Schiller, J., and S. Crocker, "Randomness Requirements for Security", BCP 106, RFC 4086, June 2005.
[RFC4086]イーストレーク、D.、シラー、J.、およびS.クロッカー、 "セキュリティのためのランダム要件"、BCP 106、RFC 4086、2005年6月。
[RFC5321] Klensin, J., "Simple Mail Transfer Protocol", RFC 5321, October 2008.
[RFC5321] Klensin、J.、 "簡易メール転送プロトコル"、RFC 5321、2008年10月。
[RFC1123] Braden, R., "Requirements for Internet Hosts - Application and Support", STD 3, RFC 1123, October 1989.
[RFC1123]ブレーデン、R.、 "インターネットホストのための要件 - 、アプリケーションとサポート"、STD 3、RFC 1123、1989年10月。
[RFC3833] Atkins, D. and R. Austein, "Threat Analysis of the Domain Name System (DNS)", RFC 3833, August 2004.
[RFC3833]アトキンス、D.とR. Austeinと、RFC 3833 "ドメインネームシステム（DNS）の脅威分析"、2004年8月。
[RFC4301] Kent, S. and K. Seo, "Security Architecture for the Internet Protocol", RFC 4301, December 2005.
[RFC4301]ケント、S.とK. Seo、 "インターネットプロトコルのためのセキュリティアーキテクチャ"、RFC 4301、2005年12月。
[RFC4787] Audet, F. and C. Jennings, "Network Address Translation (NAT) Behavioral Requirements for Unicast UDP", BCP 127, RFC 4787, January 2007.
[RFC4787] Audet、F.とC.ジェニングス、 "ネットワークアドレス変換（NAT）ユニキャストUDPのための行動の要件"、BCP 127、RFC 4787、2007年1月。
[RFC5358] Damas, J. and F. Neves, "Preventing Use of Recursive Nameservers in Reflector Attacks", BCP 140, RFC 5358, October 2008.
[RFC5358]ダマ、J.およびF.ネベス、 "反射攻撃に再帰ネームサーバの使用を防止する"、BCP 140、RFC 5358、2008年10月。
[vu-457875] United States CERT, "Various DNS service implementations generate multiple simultaneous queries for the same resource record", VU 457875, November 2002.
[VU-457875]米国CERTは、VU 457875、2002年11月の「各種DNSサービスの実装は、同じリソースレコードの複数の同時クエリを生成します」。
Authors' Addresses
著者のアドレス
Bert Hubert Netherlabs Computer Consulting BV. Braillelaan 10 Rijswijk (ZH) 2289 CM The Netherlands
バート・ヒューバートNetherlabsコンピュータコンサルティングBV。 Braillelaan 10ライスワイク（ZH）2289 CMオランダ
EMail: bert.hubert@netherlabs.nl
メールアドレス：bert.hubert@netherlabs.nl
Remco van Mook Equinix Auke Vleerstraat 1 Enschede 7521 PE The Netherlands
レムコヴァンムックエクイニクスAuke Vleerstraat 1エンスケーデ7521 PEオランダ
EMail: remco@eu.equinix.com
メールアドレス：remco@eu.equinix.com