[要約] RFC 5452は、DNSに対する偽の回答に対してより強力な耐性を持たせるための対策を提案しています。その目的は、DNSのセキュリティを向上させ、偽の回答による攻撃を防ぐことです。
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
Forgedの回答に対してDNSをより弾力性のあるものにするための手段
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.
Copyright（c）2009 IETF Trustおよび文書著者として特定された人。全著作権所有。
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/ license-info）に関連するIETF Trustの法的規定の対象となります。この文書に関するあなたの権利と制限を説明するので、これらの文書を注意深く確認してください。
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.
以下の単語は、Resolversの著者を対象としています。使用するnameserverの実装、または有効化するオプションを決定するのはオペレーター次第です。運用上の制約は、以下に説明するセキュリティの懸念を無効にする可能性があります。ただし、実装により、オペレーターはこのドキュメントで説明されている機能を有効にすることができます。
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を介して送信された検証メールに応答する能力以外のアイデンティティの確認なしで、安全なソケットレイヤー/輸送層セキュリティ（SSL/TLS）証明書を取得することが可能になりました（[RFC5321]） - 通常は使用します。ルーティングの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.
SPOOF：選択した回答を受け入れて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].
「必須」、「そうしない」、「必須」、「shall」、「shall "、" ingle "、" should "、" not "、" becommended "、" bay "、および「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の次の文は、現在の問題を予測しました。
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.
リゾルバーは、応答の解析において非常に妄想的でなければなりません。また、応答が送信されたクエリと一致していることも確認する必要があります。
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フィールドは、質問パケットの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）の短縮時間（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.
ターゲットドメイン名のrrsetsのライブ時間は、機会のウィンドウがどれだけ頻繁に利用できるかを決定します。これは、短い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フィールドは16ビット幅です。つまり、これらすべてのビットで完全に使用されている場合、その内容が本当にランダムである場合、平均して32768の推測を試みる必要があります。逸話的な証拠は、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.
多くのゾーンには2つまたは3つの権威ある名前アーバーがあり、本物の応答のソースアドレスと一致する可能性が非常に高くなります。
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.
一般に、この状態は、一致する前に最大2つまたは3つの試行を必要とします。
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.
最大ポートの範囲が利用されている場合、平均して、1024未満のポートが使用できず、64512オプションを残すことができないため、元のクエリのソースポートを一致させる前に、平均して約32256ソースポートを試す必要があります。
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 Resolverがポートを使用すると、短時間後にそのポートがリリースされ、別のポートに移動します。大量のリゾルバーの場合にのみ、特定の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.
攻撃者が送信するパケットは、その単一ドメインの未解決のクエリのいずれかを一致させるだけであるため、受け入れられる可能性がはるかに高くなります。上記の誕生日の類推と比較して、クエリと応答で構成されるグループのグループのいずれかを共有する可能性は急速に上昇します。
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ミリ秒の場合、攻撃者は650000パケット/sを簡単に送信して、最初の試みでスプーフィングされたデータを受け入れる可能性が50％になる必要があります。
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応答は、IPヘッダーを含む約80バイトで構成され、上記のパケットレートを416 Mbit/sの立派なバーストに対応します。
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 Mbit/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.
さらに、攻撃者が1回以上のチャンスを与えられ、300秒の時間があるドメインで最大60分間の作業を許可された場合、偽データを取得する50％の確率でわずかな4 Mbit/sで十分です受け入れられました。より長い時間を装備すると、上記の一致条件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：使用されるポートの数（1024歳未満のポートとして最大64000が常に利用可能ではありませんが、多くの場合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」であり、攻撃者が1秒あたり「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:
少なくとも1つの成功の合計チャンスを計算するために、次の式が保持されます。
(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の一般的な数値（上記のように）、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を上げるだけで保護が得られることがわかります。権威ある名前アーバーの数をRaise 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」と等しくなり、権威あるサーバーの応答時間です。
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を搭載したRRSetで以前に導出された式を使用して、7000の偽の応答パケット/s（4.5 Mbit/sのレート）を送信する攻撃者は、最初の24時間で記録をスプーフィングする可能性が10％あります。、1週間後に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のRRSetの場合、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 Mbit/sのパケットの予期しない入っているストリームに気付くかもしれません。
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.
そのポート番号も不明で推測する必要がある場合、問題スペースは64000倍に拡大し、攻撃者は同様の成功率を達成するために285GB/sを超える必要があります。
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.
効果的に無限の数のクエリを使用して、望ましいスプーフィング目標を達成するための手法を利用できます。上記の数学では、これにより有効なTTLが0に減少します。
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.
そのような手法が上記の同じ7000パケット/sレートを使用して使用し、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ポートが使用されている場合、約116時間後に50％レベルに達します。
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
o クエリID
o Query name
o クエリ名
o Query class and type
o クエリクラスとタイプ
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 発信クエリには予測不可能なクエリIDを使用して、利用可能な全範囲（0-65535）を利用します。
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.
おそらく、上記のように多くのパケットが基準に失敗することを発見することで、リゾルバーがそれをスプーフィングする試みが行われていることを検出した場合、UDPクエリを放棄してTCPを介して再発行する可能性があります。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.
このドキュメントでは、UDPソースポート番号のランダム化を使用して、有効なDNSトランザクションIDを利用可能な16ビットを超えて拡張することを推奨しています。
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.
上記の推奨事項を実装していないリゾルバーは、スプーフィングされた応答を簡単に受け入れることを余儀なくされ、クライアントコンピューターに渡されます。
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.
ほとんどのセキュリティ上の考慮事項はセクション4および5に記載されていますが、提案された対策についてはセクション9で説明します。
For brevity's sake, in lieu of repeating the security considerations references, the reader is referred to these sections.
Brevityのために、セキュリティに関する考慮事項の参照を繰り返す代わりに、読者はこれらのセクションを参照します。
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.
NATまたはStatefullファイアウォールの後ろに座っているDNS再帰サーバーは、高クエリ負荷で操作するときに利用可能なすべての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ボックスとStatefullファイアウォールは、そのマッピングの最後の発信クエリが送信されてから10〜17秒後に発信DNSクエリ翻訳エントリをパージすることができます。[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のソースポートランダム化が最初に実装され、おそらくDan J. Bernsteinによって発明されました。
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
間違いは私たち自身のものであり続けていますが、著者は、ステファン・ボルツメイヤー・アルフレッド・ホエンズ・ピーター・コック・ショーン・リーチ・ノーバート・センキー・ポール・ヴィクシー・フロリアン・ワイマー・ウーター・ヴィ・ウィッツ・ダン・ウィングの助けと貢献を感謝して認めています。
[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] Bradner、S。、「要件レベルを示すためにRFCで使用するためのキーワード」、BCP 14、RFC 2119、1997年3月。
[RFC2181] Elz, R. and R. Bush, "Clarifications to the DNS Specification", RFC 2181, July 1997.
[RFC2181] Elz、R。およびR. Bush、「DNS仕様の説明」、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] Ferguson、P。およびD. Senie、「ネットワークイングレスフィルタリング：IPソースアドレススプーフィングを採用するサービス拒否攻撃の敗北」、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.、Gudmundsson、O.、Eastlake、D。、およびB. Wellington、「DNSのシークレットキートランザクション認証」、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] Arends、R.、Austein、R.、Larson、M.、Massey、D。、およびS. Rose、「DNSセキュリティの紹介と要件」、RFC 4033、2005年3月。
[RFC4086] Eastlake, D., Schiller, J., and S. Crocker, "Randomness Requirements for Security", BCP 106, RFC 4086, June 2005.
[RFC4086] Eastlake、D.、Schiller、J。、およびS. Crocker、「セキュリティのランダム性要件」、BCP 106、RFC 4086、2005年6月。
[RFC5321] Klensin, J., "Simple Mail Transfer Protocol", RFC 5321, October 2008.
[RFC5321] Klensin、J。、「Simple Mail Transfer Protocol」、RFC 5321、2008年10月。
[RFC1123] Braden, R., "Requirements for Internet Hosts - Application and Support", STD 3, RFC 1123, October 1989.
[RFC1123] Braden、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] Atkins、D。およびR. Austein、「ドメイン名システムの脅威分析（DNS）」、RFC 3833、2004年8月。
[RFC4301] Kent, S. and K. Seo, "Security Architecture for the Internet Protocol", RFC 4301, December 2005.
[RFC4301] Kent、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. Jennings、「Unicast UDPのネットワークアドレス変換（NAT）行動要件」、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] Damas、J。およびF. Neves、「リフレクター攻撃での再帰的な名前の使用の防止」、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、「さまざまなDNSサービスの実装は、同じリソースレコードの複数の同時クエリを生成します」、VU 457875、2002年11月。
Authors' Addresses
著者のアドレス
Bert Hubert Netherlabs Computer Consulting BV. Braillelaan 10 Rijswijk (ZH) 2289 CM The Netherlands
Bert Hubert Netherlabs Computer Consulting bv。braillalaan 10 rijswijk（zh）2289 cmオランダ
EMail: bert.hubert@netherlabs.nl
Remco van Mook Equinix Auke Vleerstraat 1 Enschede 7521 PE The Netherlands
レンコ・ヴァン・ムーク・エクイニクスauke vleerstraat 1 Enschede 7521 PEオランダ
EMail: remco@eu.equinix.com