Network Working Group D. Atkins
Request for Comments: 3833 IHTFP Consulting
Category: Informational R. Austein
ISC
August 2004
Threat Analysis of the Domain Name System (DNS)
Status of this Memo
このメモの位置付け
This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited.
このメモはインターネットコミュニティのための情報を提供します。それはどんな種類のインターネット標準を指定しません。このメモの配布は無制限です。
Copyright Notice
著作権表示
Copyright (C) The Internet Society (2004).
著作権（C）インターネット協会（2004）。
Abstract
抽象
Although the DNS Security Extensions (DNSSEC) have been under development for most of the last decade, the IETF has never written down the specific set of threats against which DNSSEC is designed to protect. Among other drawbacks, this cart-before-the-horse situation has made it difficult to determine whether DNSSEC meets its design goals, since its design goals are not well specified. This note attempts to document some of the known threats to the DNS, and, in doing so, attempts to measure to what extent (if any) DNSSEC is a useful tool in defending against these threats.
DNSセキュリティ拡張機能（DNSSEC）は最後の十年のほとんどのために開発されてきたが、IETFは、DNSSECを保護するように設計されてそれに対して脅威の特定のセットを書き留めたことはありません。その設計目標は十分に指定されていないので、他の欠点の中で、このカート・ビフォア・-馬の状況は、それが困難なDNSSECは、その設計目標を満たしているかどうかを判断できるようになりました。このノートでは、DNSへの既知の脅威のいくつかを文書化しようとし、そして、そうすることで、どの程度（もしあれば）に測定しようとするDNSSECは、これらの脅威からの防御に便利なツールです。
The earliest organized work on DNSSEC within the IETF was an open design team meeting organized by members of the DNS working group in November 1993 at the 28th IETF meeting in Houston. The broad outlines of DNSSEC as we know it today are already clear in Jim Galvin's summary of the results of that meeting [Galvin93]:
IETF内のDNSSECの最も初期の整理作業はヒューストンで第28回IETFミーティングで1993年11月にDNSワーキンググループのメンバーが主催するオープンな設計チームミーティングでした。今日私たちが知っているようにDNSSECの広範な輪郭がすでにその会議[Galvin93]の結果のジム・ガルビンの概要が明らかにされています。
- While some participants in the meeting were interested in protecting against disclosure of DNS data to unauthorized parties, the design team made an explicit decision that "DNS data is `public'", and ruled all threats of data disclosure explicitly out of scope for DNSSEC.
- 会議でのいくつかの参加者が権限のない者にDNSデータの開示からの保護に興味を持っていたものの、設計チームは、「DNSデータが ' `公開されている」、とDNSSECのために明示的にスコープ外のデータ開示のすべての脅威を支配することを明示的な決定を下しました。
- While some participants in the meeting were interested in authentication of DNS clients and servers as a basis for access control, this work was also ruled out of scope for DNSSEC per se.
- 会議でのいくつかの参加者は、アクセス制御のための基礎として、DNSクライアントとサーバーの認証に興味を持っていたが、この作品は、DNSSECそれ自体の範囲外支配されました。
- Backwards compatibility and co-existence with "insecure DNS" was listed as an explicit requirement.
- 「安全でないDNS」との後方互換性と共存は、明示的な要件として記載されていました。
- The resulting list of desired security services was 1) data integrity, and 2) data origin authentication.
- 必要なセキュリティサービスの結果のリストは1）データの整合性であり、2）データ発信元認証。
- The design team noted that a digital signature mechanism would support the desired services.
- 設計チームは、デジタル署名メカニズムが必要なサービスをサポートすることに留意しました。
While a number of detail decisions were yet to be made (and in some cases remade after implementation experience) over the subsequent decade, the basic model and design goals have remained fixed.
詳細決定の数は、その後の十年間で行うことがまだあった（場合によっては実装経験した後にリメイク）が、基本的なモデルと設計目標は、固定されたままです。
Nowhere, however, does any of the DNSSEC work attempt to specify in any detail the sorts of attacks against which DNSSEC is intended to protect, or the reasons behind the list of desired security services that came out of the Houston meeting. For that, we have to go back to a paper originally written by Steve Bellovin in 1990 but not published until 1995, for reasons that Bellovin explained in the paper's epilogue [Bellovin95].
どこにも、しかし、任意の詳細にDNSSECを保護することを意図しているの攻撃、またはヒューストン会議から出てきた必要なセキュリティサービスのリストの背後にある理由の種類を指定するには、DNSSECの仕事の試みのいずれもしません。そのために、我々は戻って、もともとBellovin氏は、紙のエピローグ[Bellovin95]で説明した理由のため、1990年にスティーブBellovin氏によって書かれたが、1995年まで発行されていない紙に行かなければなりません。
While it may seem a bit strange to publish the threat analysis a decade after starting work on the protocol designed to defend against it, that is, nevertheless, what this note attempts to do. Better late than never.
それはそれを防御するために設計されたプロトコル上で作業を開始した後、脅威分析に十年の公開を少し奇妙に思えるかもしれないが、それはこのノートが何をしようとするもの、それにもかかわらず、です。ないより遅れて。
This note assumes that the reader is familiar with both the DNS and with DNSSEC, and does not attempt to provide a tutorial on either. The DNS documents most relevant to the subject of this note are: [RFC1034], [RFC1035], section 6.1 of [RFC1123], [RFC2181], [RFC2308], [RFC2671], [RFC2845], [RFC2930], [RFC3007], and [RFC2535].
このノートでは、読者がDNSの両方を持つとDNSSECに精通しており、いずれかのチュートリアルを提供しようとしないことを前提としています。このノートの主題に最も関連のDNS書類は以下のとおりです。[RFC1034]、[RFC1035]、[RFC1123]のセクション6.1、[RFC2181]、[RFC2308]、[RFC2671]、[RFC2845]、[RFC2930]、[RFC3007 ]、および[RFC2535]。
For purposes of discussion, this note uses the term "DNSSEC" to refer to the core hierarchical public key and signature mechanism specified in the DNSSEC documents, and refers to TKEY and TSIG as separate mechanisms, even though channel security mechanisms such as TKEY and TSIG are also part of the larger problem of "securing DNS" and thus are often considered part of the overall set of "DNS security extensions". This is an arbitrary distinction that in part reflects the way in which the protocol has evolved (introduction of a putatively simpler channel security model for certain operations such as zone transfers and dynamic update requests), and perhaps should be changed in a future revision of this note.
議論の目的のために、このノートはDNSSEC文書で指定されたコア階層公開鍵と署名機構を指すために、用語「DNSSEC」を使用し、さらにはそのような処理鍵とTSIGとしてチャネルセキュリティメカニズムが、別個の機構としてTKEYおよびTSIGを指しまた、「DNSの確保」の大きな問題の一部であり、したがって、多くの場合、「DNSセキュリティ拡張」の全体的なセットの一部とみなされます。これは、部分的にはプロトコルが進化してきた方法（例えばゾーン転送及び動的更新要求などの特定の操作のための推定簡単なチャネルのセキュリティ・モデルの導入）を反映する任意の区別であり、おそらくこの将来の改訂で変更されなければなりません注意。
There are several distinct classes of threats to the DNS, most of which are DNS-related instances of more general problems, but a few of which are specific to peculiarities of the DNS protocol.
そこより一般的な問題のDNS関連のインスタンスであるそのほとんどがDNSへの脅威のいくつかの異なるクラスがありますが、そのうちのいくつかは、DNSプロトコルの特殊性に固有のものです。
Some of the simplest threats against DNS are various forms of packet interception: monkey-in-the-middle attacks, eavesdropping on requests combined with spoofed responses that beat the real response back to the resolver, and so forth. In any of these scenarios, the attacker can simply tell either party (usually the resolver) whatever it wants that party to believe. While packet interception attacks are far from unique to DNS, DNS's usual behavior of sending an entire query or response in a single unsigned, unencrypted UDP packet makes these attacks particularly easy for any bad guy with the ability to intercept packets on a shared or transit network.
サル-in-the-middle攻撃、等々バックリゾルバに本当の応答を破って、偽装されたレスポンスと組み合わせリクエストの盗聴：DNSに対する最も簡単な脅威のいくつかは、様々なパケット傍受の形態です。これらのシナリオのいずれにおいても、攻撃者は、単にそれは当事者が信じるようにすることを望んでいるものは何でも、いずれかの当事者（通常リゾルバ）を伝えることができます。パケット傍受攻撃がはるかにDNSに固有のですが、単一の符号なし、暗号化されていないUDPパケットにクエリ全体または応答を送信するDNSの通常の動作は、共有またはトランジットネットワーク上のパケットを傍受する能力を持つ任意の悪い男のためのこれらの攻撃は特に簡単になります。
To further complicate things, the DNS query the attacker intercepts may just be a means to an end for the attacker: the attacker might even choose to return the correct result in the answer section of a reply message while using other parts of the message to set the stage for something more complicated, for example, a name chaining attack (see section 2.3).
さらに物事を複雑にするには、DNSクエリが攻撃者のインターセプトは、単に攻撃者のための目的を達成するための手段かもしれ：攻撃者も設定したメッセージの他の部分を使用しながら、応答メッセージの応答セクションで、正しい結果を返すことを選択するかもしれません例えば、より複雑なもの、攻撃の連鎖名（セクション2.3を参照）のためのステージ。
While it certainly would be possible to sign DNS messages using a channel security mechanism such as TSIG or IPsec, or even to encrypt them using IPsec, this would not be a very good solution for interception attacks. First, this approach would impose a fairly high processing cost per DNS message, as well as a very high cost associated with establishing and maintaining bilateral trust relationships between all the parties that might be involved in resolving any particular query. For heavily used name servers (such as the servers for the root zone), this cost would almost certainly be prohibitively high. Even more important, however, is that the underlying trust model in such a design would be wrong, since at best it would only provide a hop-by-hop integrity check on DNS messages and would not provide any sort of end-to-end integrity check between the producer of DNS data (the zone administrator) and the consumer of DNS data (the application that triggered the query).
それは確かにIPsecを使用してそれらを暗号化するためにも、このようなTSIGやIPsecなどのチャネルのセキュリティ・メカニズムを使用してDNSメッセージに署名、またはすることが可能であろうが、これは傍受攻撃のために非常に良い解決策ではないでしょう。まず、このアプローチは、DNSメッセージあたりかなり高い処理コスト、ならびに任意の特定のクエリの解決に関与している可能性のあるすべての当事者間の二国間の信頼関係を確立し、維持することに関連した非常に高いコストを課します。 （例えば、ルートゾーンのサーバなど）使用頻度の高いネームサーバの場合、このコストはほぼ確実に法外に高いだろう。さらに重要なのは、しかし、そのような設計における基本的な信頼モデルはせいぜいそれが唯一のDNSメッセージのホップバイホップ整合性チェックを提供するために、間違っているだろうし、エンド・ツー・エンドの任意の並べ替えを提供しないということですDNSデータのプロデューサー（ゾーン管理者）とDNSデータの消費者（クエリをトリガしたアプリケーション）間の整合性チェック。
By contrast, DNSSEC (when used properly) does provide an end-to-end data integrity check, and is thus a much better solution for this class of problems during basic DNS lookup operations.
これとは対照的に、DNSSEC（適切に使用）、エンドツーエンドのデータの整合性チェックを提供し、したがって、基本的なDNSルックアップ操作中の問題のこのクラスのためのより良い解決策です。
TSIG does have its place in corners of the DNS protocol where there's a specific trust relationship between a particular client and a particular server, such as zone transfer, dynamic update, or a resolver (stub or otherwise) that is not going to check all the DNSSEC signatures itself.
TSIGはすべてチェックするつもりはないようなゾーン転送、動的更新、またはリゾルバ（スタブまたはそれ以外）として、特定のクライアントと特定のサーバ間の具体的な信頼関係がありますDNSプロトコルのコーナーでその場所を持っていますDNSSEC署名そのもの。
Note that DNSSEC does not provide any protection against modification of the DNS message header, so any properly paranoid resolver must:
DNSSECはDNSメッセージヘッダの変更に対する任意の保護を提供しませんので、任意の適切偏執的なリゾルバがなければならないことに注意してください：
- Perform all of the DNSSEC signature checking on its own,
- 自分自身でチェックDNSSEC署名をすべて実行し、
- Use TSIG (or some equivalent mechanism) to ensure the integrity of its communication with whatever name servers it chooses to trust, or
- 利用TSIG（またはいくつかの同等のメカニズム）それは信頼することを選択する任意の名前のサーバーとの通信の整合性を確保するため、または
- Resign itself to the possibility of being attacked via packet interception (and via other techniques discussed below).
- パケット傍受（及び以下に述べる他の技術を介して）を介して攻撃される可能性に自分自身を辞任。
Since DNS is for the most part used over UDP/IP, it is relatively easy for an attacker to generate packets which will match the transport protocol parameters. The ID field in the DNS header is only a 16-bit field and the server UDP port associated with DNS is a well-known value, so there are only 2**32 possible combinations of ID and client UDP port for a given client and server. This is not a particularly large range, and is not sufficient to protect against a brute force search; furthermore, in practice both the client UDP port and the ID can often be predicted from previous traffic, and it is not uncommon for the client port to be a known fixed value as well (due to firewalls or other restrictions), thus frequently reducing the search space to a range smaller than 2**16.
DNSがUDP / IP上で使用されるほとんどの部分があるので、攻撃者は、トランスポートプロトコルパラメータと一致しますパケットを生成することが比較的容易です。 DNSヘッダ内のIDフィールドは、16ビットのフィールドであり、DNSに関連するサーバUDPポートは、周知の値であるので、そこに与えられたクライアントのIDとクライアントUDPポートのみ2 ** 32の可能な組み合わせであるとサーバ。これは、特に大規模な範囲ではなく、力まかせ探索から保護するのに十分ではありません。さらに、両方のクライアントUDPポート実際にので、頻繁に削減、IDは、多くの場合、以前のトラフィックから予測することができ、クライアント側のポートが（原因ファイアウォールやその他の制限のために）としても既知の固定値とすることは珍しいことではありません2 ** 16よりも小さい範囲に探索空間。
By itself, ID guessing is not enough to allow an attacker to inject bogus data, but combined with knowledge (or guesses) about QNAMEs and QTYPEs for which a resolver might be querying, this leaves the resolver only weakly defended against injection of bogus responses.
単独で、ID推測攻撃者が偽のデータを注入することを可能にするのに十分ではなく、知識（または推測）と組み合わせたリゾルバが照会されるかもしれないためのQNameとQTYPEsについて、これは弱くしか偽の応答の注入に対する擁護リゾルバを残します。
Since this attack relies on predicting a resolver's behavior, it's most likely to be successful when the victim is in a known state, whether because the victim rebooted recently, or because the victim's behavior has been influenced by some other action by the attacker, or because the victim is responding (in a predictable way) to some third party action known to the attacker.
この攻撃は、リゾルバの挙動を予測に依存しているので、それは被害者が最近、再起動しているためか、被害者が知られている状態にあるとき、成功する可能性が最も高いです、または被害者の行動は、攻撃者によって、いくつかの他のアクションに影響されているので、または理由被害者が攻撃者に知られているいくつかのサードパーティのアクションに（予測可能な方法で）応答しています。
This attack is both more and less difficult for the attacker than the simple interception attack described above: more difficult, because the attack only works when the attacker guesses correctly; less difficult, because the attacker doesn't need to be on a transit or shared network.
この攻撃は、上述の簡単な盗聴攻撃よりも攻撃のためのより少ない困難でもある：より多くの困難、攻撃者が正しく推測する場合、攻撃にのみ動作するため、攻撃者はトランジットまたは共有ネットワーク上にある必要はありませんので、それほど難しいです。
In most other respects, this attack is similar to a packet interception attack. A resolver that checks DNSSEC signatures will be able to detect the forged response; resolvers that do not perform DNSSEC signature checking themselves should use TSIG or some equivalent mechanism to ensure the integrity of their communication with a recursive name server that does perform DNSSEC signature checking.
他のほとんどの点で、この攻撃は、パケット傍受攻撃に似ています。 DNSSEC署名をチェックするリゾルバは偽造応答を検出することができるであろう。自分自身をチェックするDNSSEC署名を行わないリゾルバがDNSSEC署名チェックを実行しない再帰ネームサーバとの通信の整合性を確保するためにTSIGまたはいくつかの同等のメカニズムを使用する必要があります。
Perhaps the most interesting class of DNS-specific threats are the name chaining attacks. These are a subset of a larger class of name-based attacks, sometimes called "cache poisoning" attacks. Most name-based attacks can be partially mitigated by the long-standing defense of checking RRs in response messages for relevance to the original query, but such defenses do not catch name chaining attacks. There are several variations on the basic attack, but what they all have in common is that they all involve DNS RRs whose RDATA portion (right hand side) includes a DNS name (or, in a few cases, something that is not a DNS name but which directly maps to a DNS name). Any such RR is, at least in principle, a hook that lets an attacker feed bad data into a victim's cache, thus potentially subverting subsequent decisions based on DNS names.
DNS固有の脅威のおそらく最も興味深いのクラスは、攻撃をチェーンの名前です。これらは、時々、「キャッシュポイズニング」攻撃と呼ばれる名前ベースの攻撃の大きなクラスのサブセットで、です。ほとんどの名前ベースの攻撃は、部分的に元のクエリとの関連性のための応答メッセージでRRをチェックするの長年の防衛によって軽減することができますが、そのような防御は攻撃を名前連鎖をキャッチしないでください。そこの基本的な攻撃にはいくつかのバリエーションがありますが、どのような彼らはすべてに共通しているの彼らのすべてがそのRDATA部分（右側）DNS名（または、いくつかのケースでは、DNS名ではないものを含んでDNSのRRを伴うということですしかし、これは直接DNS名にマップ）。そのような任意のRRは、少なくとも原理的には、攻撃者は、このように潜在的にDNS名に基づいて、その後の決定を覆す、被害者のキャッシュに不正なデータを送ることができますフックです。
The worst examples in this class of RRs are CNAME, NS, and DNAME RRs because they can redirect a victim's query to a location of the attacker's choosing. RRs like MX and SRV are somewhat less dangerous, but in principle they can also be used to trigger further lookups at a location of the attacker's choosing. Address RR types such as A or AAAA don't have DNS names in their RDATA, but since the IN-ADDR.ARPA and IP6.ARPA trees are indexed using a DNS encoding of IPv4 and IPv6 addresses, these record types can also be used in a name chaining attack.
彼らは攻撃者の選択した場所に被害者のクエリをリダイレクトすることができますので、RRのこのクラスの最悪の例はCNAME、NS、およびDNAMEのRRです。 MXとSRVのようなRRはやや少ない危険ですが、原則的に、彼らはまた、攻撃者の選択した場所でさらに検索をトリガするために使用することができます。そのようなAまたはAAAAのアドレスのRRタイプは、彼らのRDATAにDNS名を持っていないが、IN-ADDR.ARPAとIP6.ARPA木はIPv4アドレスとIPv6アドレスのDNSエンコーディングを使用して索引付けされているため、これらのレコードタイプも使用することができます名前に攻撃を連鎖します。
The general form of a name chaining attack is something like this:
名前の連鎖攻撃の一般的な形式は次のようなものです：
- Victim issues a query, perhaps at the instigation of the attacker or some third party; in some cases the query itself may be unrelated to the name under attack (that is, the attacker is just using this query as a means to inject false information about some other name).
- 被害者は、おそらく、攻撃者または一部のサードパーティの扇動で、クエリを発行します。いくつかのケースでクエリ自体は（つまり、攻撃者は単にいくつかの他の名前についての虚偽の情報を注入する手段として、このクエリを使用している場合）、攻撃の下に名前とは無関係のかもしれません。
- Attacker injects response, whether via packet interception, query guessing, or by being a legitimate name server that's involved at some point in the process of answering the query that the victim issued.
- 攻撃者はパケット傍受を経由して、クエリ推測、または被害者が発行したクエリに答える過程でいくつかの点で関与しています正当なネームサーバであることによってか、応答を注入します。
- Attacker's response includes one or more RRs with DNS names in their RDATA; depending on which particular form this attack takes, the object may be to inject false data associated with those names into the victim's cache via the Additional section of this response, or may be to redirect the next stage of the query to a server of the attacker's choosing (in order to inject more complex lies into the victim's cache than will fit easily into a single response, or in order to place the lies in the Authority or Answer section of a response where they will have a better chance of sneaking past a resolver's defenses).
- 攻撃者の応答は、そのRDATAでDNS名を持つ一の以上のRRを含み、この攻撃が取るどの特定の形態に応じて、オブジェクトは、この応答の追加セクションを経由して、被害者のキャッシュにそれらの名前に関連した虚偽のデータを注入することであってもよいし、攻撃者ののサーバへのクエリの次のステージをリダイレクトすることであってもよいです当局に嘘を置くか、彼らはリゾルバの過去こっそりのより良いチャンスがあります応答の部分に答えるために、単一の応答に容易に適合、またはだろうよりも、被害者のキャッシュに、より複雑な嘘を注入するために、（選択します防御）。
Any attacker who can insert resource records into a victim's cache can almost certainly do some kind of damage, so there are cache poisoning attacks which are not name chaining attacks in the sense discussed here. However, in the case of name chaining attacks, the cause and effect relationship between the initial attack and the eventual result may be significantly more complex than in the other forms of cache poisoning, so name chaining attacks merit special attention.
被害者のキャッシュにリソースレコードを挿入することができ、任意の攻撃者は、ほぼ確実に損傷のいくつかの種類を行うことができますので、ここで説明の意味での攻撃を名前連鎖されていないキャッシュポイズニング攻撃があります。名前の連鎖攻撃は特別な注意に値するのでしかし、名前の連鎖攻撃の場合には、最初の攻撃と最終的な結果との間に因果関係は、キャッシュポイズニングの他の形態に比べてはるかに複雑です。
The common thread in all of the name chaining attacks is that response messages allow the attacker to introduce arbitrary DNS names of the attacker's choosing and provide further information that the attacker claims is associated with those names; unless the victim has better knowledge of the data associated with those names, the victim is going to have a hard time defending against this class of attacks.
攻撃を名前連鎖のすべてに共通のスレッドは、応答メッセージは、攻撃者は、攻撃者が選択した任意のDNS名を紹介すると、攻撃者のクレームはそれらの名前に関連付けられていること、さらに情報を提供できるようにするということです。被害者がそれらの名前に関連付けられたデータのより良い知識を持っていない限り、被害者は攻撃のこのクラスの防御苦労を持っているとしています。
This class of attack is particularly insidious given that it's quite easy for an attacker to provoke a victim into querying for a particular name of the attacker's choosing, for example, by embedding a link to a 1x1-pixel "web bug" graphic in a piece of Text/HTML mail to the victim. If the victim's mail reading program attempts to follow such a link, the result will be a DNS query for a name chosen by the attacker.
攻撃のこのクラスは特に陰湿な攻撃者は例えば、作品にグラフィック「ウェブバグ」1x1ピクセルへのリンクを埋め込むことにより、攻撃者が選択した特定の名前をクエリに被害者を挑発するのは非常に簡単だということ与えられています被害者へのテキスト/ HTMLメールの。被害者のメール読み取りプログラムは、このようなリンクをたどるしようとすると、結果が攻撃者によって選ばれた名前のDNSクエリになります。
DNSSEC should provide a good defense against most (all?) variations on this class of attack. By checking signatures, a resolver can determine whether the data associated with a name really was inserted by the delegated authority for that portion of the DNS name space. More precisely, a resolver can determine whether the entity that injected the data had access to an allegedly secret key whose corresponding public key appears at an expected location in the DNS name space with an expected chain of parental signatures that start with a public key of which the resolver has prior knowledge.
DNSSECは、攻撃のこのクラスのほとんど（すべて？）の変動に対して良好な防御力を提供する必要があります。署名をチェックすることにより、リゾルバは名前に関連付けられたデータが実際にDNS名前空間のその部分のために委任された権限によって挿入されたかどうかを判断することができます。より正確には、リゾルバは、データを注入されたエンティティが公開鍵に対応する公開鍵で始まる親の署名の期待チェーンとDNS名前空間に予想される場所に表示される容疑者の秘密鍵へのアクセスを持っていたかどうかを判断することができますリゾルバは事前知識を持っています。
DNSSEC signatures do not cover glue records, so there's still a possibility of a name chaining attack involving glue, but with DNSSEC it is possible to detect the attack by temporarily accepting the glue in order to fetch the signed authoritative version of the same data, then checking the signatures on the authoritative version.
DNSSEC署名はグルーレコードをカバーしていないので、その後、そこに接着剤を含む名前の連鎖攻撃の可能性はまだだが、DNSSECと、一時的に同じデータの署名権威バージョンを取得するために、接着剤を受け入れることによって、攻撃を検出することが可能です正式なバージョンの署名をチェックします。
Another variation on the packet interception attack is the trusted server that turns out not to be so trustworthy, whether by accident or by intent. Many client machines are only configured with stub resolvers, and use trusted servers to perform all of their DNS queries on their behalf. In many cases the trusted server is furnished by the user's ISP and advertised to the client via DHCP or PPP options. Besides accidental betrayal of this trust relationship (via server bugs, successful server break-ins, etc), the server itself may be configured to give back answers that are not what the user would expect, whether in an honest attempt to help the user or to promote some other goal such as furthering a business partnership between the ISP and some third party.
パケット傍受攻撃のもう一つの変化は偶然か意図によってか、とても信頼できないことが判明した信頼できるサーバです。多くのクライアントマシンにのみスタブリゾルバで構成され、その代わりに、彼らのDNSクエリのすべてを実行するために信頼できるサーバーを使用しています。多くの場合、信頼されたサーバーは、ユーザーのISPによって提供されており、DHCPまたはPPPオプションを介してクライアントにアドバタイズ。 （サーバーのバグ、成功したサーバーの侵入などを経由して）、この信頼関係の偶然の裏切りに加えて、サーバー自体は、ユーザーが期待するものではありません答えをお返しするように構成することができる、正直な試みでユーザーを支援するかどうかそのようなISPや一部の第三者との間の事業提携を進めるなど、いくつかの他の目標を促進します。
This problem is particularly acute for frequent travelers who carry their own equipment and expect it to work in much the same way wherever they go. Such travelers need trustworthy DNS service without regard to who operates the network into which their equipment is currently plugged or what brand of middle boxes the local infrastructure might use.
この問題は、独自の機器を運ぶ、彼らはどこに行っても、それはほとんど同じように動作することを期待頻繁に旅行者のために特に深刻です。このような旅行者は、その機器が現在接続されているか、地域のインフラがミドルボックスのどのようなブランドを使用する可能性がありますその中にネットワークを運営し、誰に関係なく、信頼できるDNSサービスを必要とします。
While the obvious solution to this problem would be for the client to choose a more trustworthy server, in practice this may not be an option for the client. In many network environments a client machine has only a limited set of recursive name servers from which to choose, and none of them may be particularly trustworthy. In extreme cases, port filtering or other forms of packet interception may prevent the client host from being able to run an iterative resolver even if the owner of the client machine is willing and able to do so. Thus, while the initial source of this problem is not a DNS protocol attack per se, this sort of betrayal is a threat to DNS clients, and simply switching to a different recursive name server is not an adequate defense.
この問題に対する明白な解決策は、より信頼性の高いサーバを選択するために、クライアントのためになるが、実際には、これは、クライアントのためのオプションではないかもしれません。多くのネットワーク環境では、クライアント・マシンは、から選択する再帰ネームサーバの限られたセットを持っており、それらのどれもが、特に信頼できないかもしれません。極端な例では、ポートフィルタリングまたはパケット傍受の他の形態は、クライアントマシンの所有者は喜んでしてそうすることが可能であったとしても、反復リゾルバを実行することができることから、クライアントのホストを防ぐことができます。この問題の最初の源はそれ自体がDNSプロトコル攻撃ではありませんしつつ、裏切りのこの種は、DNSクライアントへの脅威であり、単に別の再帰ネームサーバへの切り替えは、十分な防衛ではありません。
Viewed strictly from the DNS protocol standpoint, the only difference between this sort of betrayal and a packet interception attack is that in this case the client has voluntarily sent its request to the attacker. The defense against this is the same as with a packet interception attack: the resolver must either check DNSSEC signatures itself or use TSIG (or equivalent) to authenticate the server that it has chosen to trust. Note that use of TSIG does not by itself guarantee that a name server is at all trustworthy: all TSIG can do is help a resolver protect its communication with a name server that it has already decided to trust for other reasons. Protecting a resolver's communication with a server that's giving out bogus answers is not particularly useful.
DNSプロトコルの観点から厳密に見ると、裏切りのこの種とパケット傍受攻撃の唯一の違いは、この場合には、クライアントが自発的に攻撃者にその要求を送信したということです。これに対する防御はパケット傍受攻撃と同じです：リゾルバが自身をDNSSEC署名を確認するか、それが信頼するように選択したサーバーを認証するためにTSIG（または同等品）を使用する必要があります。 TSIGの使用は、それ自体でネームサーバが全く信頼できることを保証するものではありません注意：TSIGを行うことができ、すべてのリゾルバが、それは既に他の理由のために信頼することを決定したネームサーバとの通信を保護するのに役立ちます。偽の答えを配っていますサーバとリゾルバの通信を保護することは特に有用ではありません。
Also note that if the stub resolver does not trust the name server that is doing work on its behalf and wants to check the DNSSEC signatures itself, the resolver really does need to have independent knowledge of the DNSSEC public key(s) it needs in order to perform the check. Usually the public key for the root zone is enough, but in some cases knowledge of additional keys may also be appropriate.
また、スタブリゾルバが代わって作業を行うと、DNSSEC署名自体をチェックしたいされたネームサーバを信頼していない場合、リゾルバは実際にそれがために必要なDNSSEC公開鍵（複数可）の独立した知識を持っている必要がないことに注意してくださいチェックを実行します。通常、ルートゾーンの公開鍵で十分ですが、いくつかのケースでは、追加のキーの知識も適切かもしれません。
It is difficult to escape the conclusion that a properly paranoid resolver must always perform its own signature checking, and that this rule even applies to stub resolvers.
適切にパラノイアリゾルバは常にそれ自身の署名チェックを実行しなければならないという結論を脱出することは困難であり、このルールにもリゾルバスタブに適用されていること。
As with any network service (or, indeed, almost any service of any kind in any domain of discourse), DNS is vulnerable to denial of service attacks. DNSSEC does not help this, and may in fact make the problem worse for resolvers that check signatures, since checking signatures both increases the processing cost per DNS message and in some cases can also increase the number of messages needed to answer a query. TSIG (and similar mechanisms) have equivalent problems.
（実際または、談話の任意のドメイン内の任意の種類のほぼすべてのサービス）任意のネットワークサービスと同様に、DNSはサービス拒否攻撃に対して脆弱です。署名をチェックすると、DNSメッセージあたりの処理コストが増加し、いくつかのケースでも、クエリに答えるために必要なメッセージの数を増やすことができ、両方のため、DNSSECは、これを解決しないと、実際に署名をチェックリゾルバのための問題を悪化させることがあります。 TSIG（及び類似のメカニズム）は同等の問題があります。
DNS servers are also at risk of being used as denial of service amplifiers, since DNS response packets tend to be significantly longer than DNS query packets. Unsurprisingly, DNSSEC doesn't help here either.
DNS応答パケットをDNSクエリパケットよりも大幅に長くなる傾向にあるため、DNSサーバは、サービスアンプの否定として使用されているのリスクもあります。当然のことながら、DNSSECはここでも助けにはなりません。
Much discussion has taken place over the question of authenticated denial of domain names. The particular question is whether there is a requirement for authenticating the non-existence of a name. The issue is whether the resolver should be able to detect when an attacker removes RRs from a response.
多くの議論は、ドメイン名の認証された否定の質問の上に行われています。特定の質問には、名前の非存在を認証するための要件があるかどうかです。問題は、リゾルバが、攻撃者が応答からRRを除去するときを検出することができなければならないかどうかです。
General paranoia aside, the existence of RR types whose absence causes an action other than immediate failure (such as missing MX and SRV RRs, which fail over to A RRs) constitutes a real threat. Arguably, in some cases, even the absence of an RR might be considered a problem. The question remains: how serious is this threat? Clearly the threat does exist; general paranoia says that some day it'll be on the front page of some major newspaper, even if we cannot conceive of a plausible scenario involving this attack today. This implies that some mitigation of this risk is required.
一般的な妄想はさておき、（RRSにフェイルオーバーなどMXとSRV RRを欠落しているなど、）不在即時故障以外のアクションを起こしRRタイプの存在が現実の脅威を構成しています。間違いなく、いくつかのケースでは、RRのさえないことが問題と考えられるかもしれません。疑問は残る：この脅威はどのように深刻なのですか？明らかな脅威が存在しません。一般的な妄想はいつの日か、それは我々が今日、この攻撃に関与するもっともらしいシナリオを考えることができない場合でも、いくつかの主要な新聞のフロントページ上にあるだろうと述べています。これは、このリスクの一部緩和が必要であることを意味します。
Note that it's necessary to prove the non-existence of applicable wildcard RRs as part of the authenticated denial mechanism, and that, in a zone that is more than one label deep, such a proof may require proving the non-existence of multiple discrete sets of wildcard RRs.
それが認証された否定メカニズムの一部として適用可能なワイルドカードRRの非存在を証明するために必要だということに注意してください、それは、複数のラベルの深さのゾーンでは、そのような証拠は、複数の離散的なセットの非存在を証明する必要がありワイルドカードRRの。
DNSSEC does include mechanisms which make it possible to determine which authoritative names exist in a zone, and which authoritative resource record types exist at those names. The DNSSEC protections do not cover non-authoritative data such as glue records.
DNSSECは、権威あるリソースレコードタイプがそれらの名前に存在する権威名がゾーン内に存在することを確認できるように仕組み、などを含んでいます。 DNSSEC保護は、このようなグルーレコードなどの非信頼すべきデータをカバーしていません。
Much discussion has taken place over whether and how to provide data integrity and data origin authentication for "wildcard" DNS names. Conceptually, RRs with wildcard names are patterns for synthesizing RRs on the fly according to the matching rules described in section 4.3.2 of RFC 1034. While the rules that control the behavior of wildcard names have a few quirks that can make them a trap for the unwary zone administrator, it's clear that a number of sites make heavy use of wildcard RRs, particularly wildcard MX RRs.
多くの議論はどうかとどのように「ワイルドカード」DNS名のデータの整合性とデータ発信元認証を提供する上で行われました。ワイルドカード名の動作を制御する規則が彼らのためにトラップすることができ、いくつかの癖を有するが、概念的に、ワイルドカード名を持つRRはRFC 1034のセクション4.3.2に記載のマッチングルールに従ってオンザフライでRRを合成するためのパターンであります不注意なゾーン管理者は、それはサイトの数は、ワイルドカードRRの多用、特にワイルドカードMX RRを作ることは明らかです。
In order to provide the desired services for wildcard RRs, we need to do two things:
ワイルドカードのRRのために必要なサービスを提供するために、我々は2つのことを行う必要があります。
- We need a way to attest to the existence of the wildcard RR itself (that is, we need to show that the synthesis rule exists), and
- 我々は、（それは我々が合成ルールが存在することを示す必要があり、である）ワイルドカードRR自身の存在を証明する方法が必要と
- We need a way to attest to the non-existence of any RRs which, if they existed, would make the wildcard RR irrelevant according to the synthesis rules that govern the way in which wildcard RRs are used (that is, we need to show that the synthesis rule is applicable).
- 私たちは、彼らが存在する場合、ワイルドカードのRRが使用される方法（つまりを支配合成規則に従ってワイルドカードRRは無関係になるだろう、我々が表示する必要が任意のRRの非存在を証明する方法が必要です合成ルール）が適用可能であること。
Note that this makes the wildcard mechanisms dependent upon the authenticated denial mechanism described in the previous section.
これは前のセクションで説明した認証拒否機構に依存するワイルドカード機構を作ることに留意されたいです。
DNSSEC includes mechanisms along the lines described above, which make it possible for a resolver to verify that a name server applied the wildcard expansion rules correctly when generating an answer.
DNSSECは、答えを生成する際に、ネームサーバが正しくワイルドカード拡張ルールを適用することを検証するためのリゾルバことを可能にする上述の線に沿って機構を含みます。
DNSSEC has some problems of its own:
DNSSECは、独自のいくつかの問題があります：
- DNSSEC is complex to implement and includes some nasty edge cases at the zone cuts that require very careful coding. Testbed experience to date suggests that trivial zone configuration errors or expired keys can cause serious problems for a DNSSEC-aware resolver, and that the current protocol's error reporting capabilities may leave something to be desired.
- DNSSECは実装が複雑であり、非常に慎重にコーディングを必要とゾーンカットでいくつかの厄介なエッジケースを含んでいます。これまでのテストベッドでの経験は、些細なゾーン設定エラーや期限切れのキーは、DNSSEC対応リゾルバのための深刻な問題を引き起こす可能性があること、および現在のプロトコルのエラー報告機能が求められるように何かを残すことを示唆しています。
- DNSSEC significantly increases the size of DNS response packets; among other issues, this makes DNSSEC-aware DNS servers even more effective as denial of service amplifiers.
- DNSSECが大幅DNS応答パケットのサイズを増加させます。他の問題の中で、これはサービスアンプの否定として、DNSSEC対応のDNSサーバがさらに効果的になります。
- DNSSEC answer validation increases the resolver's work load, since a DNSSEC-aware resolver will need to perform signature validation and in some cases will also need to issue further queries. This increased workload will also increase the time it takes to get an answer back to the original DNS client, which is likely to trigger both timeouts and re-queries in some cases. Arguably, many current DNS clients are already too impatient even before taking the further delays that DNSSEC will impose into account, but that topic is beyond the scope of this note.
- DNSSEC対応リゾルバは、署名の検証を実行する必要がありますし、いくつかのケースでも、さらにクエリを発行する必要がありますので、DNSSECの回答検証は、リゾルバの作業負荷が増加します。この増加したワークロードはまた戻っていくつかのケースでは、両方のタイムアウトおよび再クエリをトリガーする可能性がある、元のDNSクライアントへの答えを得るのにかかる時間が長くなります。おそらく、多くの現在のDNSクライアントでもDNSSECは、アカウントに課すさらに遅れを取る前に、すでにあまりにもせっかちですが、そのトピックは、このノートの範囲を超えています。
- Like DNS itself, DNSSEC's trust model is almost totally hierarchical. While DNSSEC does allow resolvers to have special additional knowledge of public keys beyond those for the root, in the general case the root key is the one that matters. Thus any compromise in any of the zones between the root and a particular target name can damage DNSSEC's ability to protect the integrity of data owned by that target name. This is not a change, since insecure DNS has the same model.
- DNS自体と同様に、DNSSECの信頼モデルは、ほぼ完全に階層的です。 DNSSECは、リゾルバは、rootのものを超えて、公開鍵の特別な追加の知識を持つことができないが、一般的なケースではルートキーは重要です。したがって、ルートとそのターゲット名が所有するデータの整合性を保護するためにDNSSECの能力を損傷することがあり、特定のターゲット名の間ゾーンのいずれかで妥協。不安定なDNSが同じモデルを持っているので、これは、変更はありません。
- Key rollover at the root is really hard. Work to date has not even come close to adequately specifying how the root key rolls over, or even how it's configured in the first place.
- ルートにキーロールオーバーは本当に難しいです。これまでの作業でも十分に上どのルートキーロールを指定するために近くに来ていない、またはそれが最初の場所で構成されていてもどのように。
- DNSSEC creates a requirement of loose time synchronization between the validating resolver and the entity creating the DNSSEC signatures. Prior to DNSSEC, all time-related actions in DNS could be performed by a machine that only knew about "elapsed" or "relative" time. Because the validity period of a DNSSEC signature is based on "absolute" time, a validating resolver must have the same concept of absolute time as the zone signer in order to determine whether the signature is within its validity period or has expired. An attacker that can change a resolver's opinion of the current absolute time can fool the resolver using expired signatures. An attacker that can change the zone signer's opinion of the current absolute time can fool the zone signer into generating signatures whose validity period does not match what the signer intended.
- DNSSECはDNSSEC署名を作成し検証リゾルバとエンティティとの間の緩い時間同期の要求を作成します。 DNSSECに先立ち、DNS内のすべての時間に関連するアクションは、唯一の「経過」または「相対」時間を知っていたマシンで実行することができます。 DNSSEC署名の有効期間が「絶対」時間に基づいているため、検証リゾルバは、署名が有効期間内であるか、または有効期限が切れているかどうかを決定するために、ゾーン署名者として絶対時間の同じ概念を有していなければなりません。現在の絶対時間のリゾルバの意見を変えることができる攻撃者は、期限切れの署名を使用してリゾルバをだますことができます。現在の絶対時間のゾーンの署名者の意見を変えることができ、攻撃者は、その有効期限署名者が意図したものと一致しない署名を生成するにゾーンの署名者をだますことができます。
- The possible existence of wildcard RRs in a zone complicates the authenticated denial mechanism considerably. For most of the decade that DNSSEC has been under development these issues were poorly understood. At various times there have been questions as to whether the authenticated denial mechanism is completely airtight and whether it would be worthwhile to optimize the authenticated denial mechanism for the common case in which wildcards are not present in a zone. However, the main problem is just the inherent complexity of the wildcard mechanism itself. This complexity probably makes the code for generating and checking authenticated denial attestations somewhat fragile, but since the alternative of giving up wildcards entirely is not practical due to widespread use, we are going to have to live with wildcards. The question just becomes one of whether or not the proposed optimizations would make DNSSEC's mechanisms more or less fragile.
- ゾーン内のワイルドカードRRの可能な存在はかなり認証拒否機構を複雑にします。 DNSSECは、開発が進められていることを十年のほとんどは、これらの問題は、あまり理解されました。種々の時間で認証拒否メカニズムは完全に気密であり、ワイルドカードゾーンに存在しないされた一般的な場合に対して認証拒否機構を最適化するために価値があるかどうかかどうかの疑問がありました。しかし、主な問題は、ワイルドカードメカニズム自体のちょうど固有の複雑さです。この複雑さは、おそらく発生し、やや脆弱な認証された否定のアテステーションをチェックするためのコードになりますが、ワイルドカードをあきらめるの代替が完全に起因する広範囲の使用には実用的ではないので、我々はワイルドカードと一緒に暮らすために持ってしようとしています。質問はちょうど提案の最適化は、DNSSECのメカニズムは、多かれ少なかれ、脆弱になるだろうかどうかの一つとなります。
- Even with DNSSEC, the class of attacks discussed in section 2.4 is not easy to defeat. In order for DNSSEC to be effective in this case, it must be possible to configure the resolver to expect certain categories of DNS records to be signed. This may require manual configuration of the resolver, especially during the initial DNSSEC rollout period when the resolver cannot reasonably expect the root and TLD zones to be signed.
- でもDNSSECで、セクション2.4で説明した攻撃のクラスは敗北することは容易ではありません。 DNSSECは、このような場合に有効であるためには、署名されるDNSレコードの特定のカテゴリを期待するリゾルバを設定することが可能でなければなりません。これは特に、リゾルバが合理的にルートとTLDゾーンが署名されることを期待することはできません初期のDNSSECの展開期間中に、レゾルバの手動設定が必要な場合があります。
This section lists a few subjects not covered above which probably need additional study, additional mechanisms, or both.
このセクションでは、おそらく追加の調査、追加メカニズム、あるいはその両方を必要とする上記カバーされていないいくつかの科目を示しています。
The above discussion has concentrated exclusively on attacks within the boundaries of the DNS protocol itself, since those are (some of) the problems against which DNSSEC was intended to protect. There are, however, other potential problems at the boundaries where DNS interacts with other protocols.
上記の議論は、それらがDNSSECを保護することを意図したものに対して（の一部）の問題であるため、DNSプロトコル自体の境界内での攻撃だけに集中しています。 DNSは、他のプロトコルと相互作用境界で他の潜在的な問題は、しかし、があります。
DNS dynamic update opens a number of potential problems when combined with DNSSEC. Dynamic update of a non-secure zone can use TSIG to authenticate the updating client to the server. While TSIG does not scale very well (it requires manual configuration of shared keys between the DNS name server and each TSIG client), it works well in a limited or closed environment such as a DHCP server updating a local DNS name server.
DNSSECと組み合わせた場合にDNS動的更新は、潜在的な問題の数を開きます。非セキュアゾーンの動的更新がサーバーに更新クライアントを認証するためにTSIGを使用することができます。 TSIGは非常にうまくスケールしませんが、ローカルのDNSネームサーバを更新するDHCPサーバとして、それは限られたか、閉じた環境でうまく動作します（これは、DNSネームサーバと各TSIGクライアント間の共有鍵の手動設定が必要です）。
Major issues arise when trying to use dynamic update on a secure zone. TSIG can similarly be used in a limited fashion to authenticate the client to the server, but TSIG only protects DNS transactions, not the actual data, and the TSIG is not inserted into the DNS zone, so resolvers cannot use the TSIG as a way of verifying the changes to the zone. This means that either:
安全なゾーンで動的更新を使用しようとしたときの主な問題が生じます。リゾルバは、方法としてTSIGを使用することはできませんので、TSIGは、同様に、サーバにクライアントを認証するために限られた方法で使用することができますが、TSIGは、DNSのみの取引ではなく、実際のデータを保護し、TSIGは、DNSゾーンに挿入されていませんゾーンへの変更を検証します。これは、どちらかのことを意味します。
a) The updating client must have access to a zone-signing key in order to sign the update before sending it to the server, or
a）の更新クライアントは、サーバーに送信する前に、アップデートに署名するために、ゾーン署名鍵へのアクセス権を持っている必要があります、または
b) The DNS name server must have access to an online zone-signing key in order to sign the update.
b）はDNSネームサーバは、更新に署名するために、オンラインゾーン署名鍵へのアクセス権を持っている必要があります。
In either case, a zone-signing key must be available to create signed RRsets to place in the updated zone. The fact that this key must be online (or at least available) is a potential security risk.
いずれの場合も、ゾーン署名鍵が更新ゾーンに配置するために署名したRRセットを作成するために使用可能でなければなりません。このキーは、オンライン（または少なくとも利用可能）でなければならないという事実は、潜在的なセキュリティリスクです。
Dynamic update also requires an update to the SERIAL field of the zone's SOA RR. In theory, this could also be handled via either of the above options, but in practice (a) would almost certainly be extremely fragile, so (b) is the only workable mechanism.
動的更新はまた、ゾーンのSOA RRのSERIALフィールドを更新する必要があります。理論的には、これはまた、上記のオプションのいずれかを経由して処理することができ、実際には（a）は、ほぼ確実に、非常に壊れやすいだろう、そう（b）は唯一の実行可能なメカニズムです。
There are other threats in terms of describing the policy of who can make what changes to which RRsets in the zone. The current access control scheme in Secure Dynamic Update is fairly limited. There is no way to give fine-grained access to updating DNS zone information to multiple entities, each of whom may require different kinds of access. For example, Alice may need to be able to add new nodes to the zone or change existing nodes, but not remove them; Bob may need to be able to remove zones but not add them; Carol may need to be able to add, remove, or modify nodes, but only A records.
ゾーン内のどのRRセットに変更内容を作ることができる人の政策を説明するという点で他の脅威があります。セキュリティで保護された動的更新の現在のアクセス制御方式はかなり限られています。アクセスの種類が必要な場合があり、それぞれの人の複数のエンティティにDNSゾーン情報を更新するきめ細かなアクセスを与える方法はありません。例えば、アリスは、既存のノードをゾーンに新しいノードを追加または変更できるようにする必要がありますが、それらを削除しない場合があります。ボブはそれらを追加するゾーンを削除ではなく、できるようにする必要があるかもしれません。キャロルは、ノードを追加、削除、または変更できるようにする必要がありますが、レコードのみがあります。
Scaling properties of the key management problem here are a particular concern that needs more study.
ここで鍵管理の問題のスケーリングの特性は、より多くの研究が必要で特に懸念されています。
As discussed in previous sections, DNSSEC per se attempts to provide data integrity and data origin authentication services on top of the normal DNS query protocol. Using the terminology discussed in [RFC3552], DNSSEC provides "object security" for the normal DNS query protocol. For purposes of replicating entire DNS zones, however, DNSSEC does not provide object security, because zones include unsigned NS RRs and glue at delegation points. Use of TSIG to protect zone transfer (AXFR or IXFR) operations provides "channel security", but still does not provide object security for complete zones. The trust relationships involved in zone transfer are still very much a hop-by-hop matter of name server operators trusting other name server operators rather than an end-to-end matter of name server operators trusting zone administrators.
前のセクションで説明したように、それ自体DNSSECは、通常のDNSクエリプロトコルの上でデータの整合性とデータ発信元認証サービスを提供しようとします。 [RFC3552]で説明した用語を使用して、DNSSECは、通常のDNSクエリプロトコルについては、「オブジェクトセキュリティ」を提供します。ゾーンが委任点で、符号なしのNSのRRと接着剤が含まれているため、全体のDNSゾーンを複製する目的のために、しかし、DNSSECは、オブジェクトのセキュリティを提供しません。ゾーン転送（AXFRまたはIXFR）の操作を保護するためにTSIGの使用は、「チャネルセキュリティ」を提供していますが、まだ完全なゾーンのオブジェクトセキュリティを提供しません。ゾーン転送に関与信頼関係が非常に多く、まだ他のネームサーバーオペレータではなく、ゾーンの管理者を信頼するネームサーバのオペレータのエンド・ツー・エンドの問題を信頼するネームサーバのオペレータのホップバイホップ問題です。
Zone object security was not an explicit design goal of DNSSEC, so failure to provide this service should not be a surprise. Nevertheless, there are some zone replication scenarios for which this would be a very useful additional service, so this seems like a useful area for future work. In theory it should not be difficult to add zone object security as a backwards compatible enhancement to the existing DNSSEC model, but the DNSEXT WG has not yet discussed either the desirability of or the requirements for such an enhancement.
ゾーンオブジェクトセキュリティは、DNSSECの明示的な設計目標ではなかったので、このサービスを提供するために、失敗は驚くべきことではありません。それにもかかわらず、そこにこれは非常に有用な追加サービスであると思われるため、いくつかのゾーンレプリケーションのシナリオがあるので、これは今後の作業のための便利なエリアのように思えます。理論的には既存のDNSSECモデルへの後方互換性拡張としてゾーンオブジェクトのセキュリティを追加することは困難であってはならないが、DNSEXT WGは未だの望まし又は増強するための要件のいずれかを議論していません。
Based on the above analysis, the DNSSEC extensions do appear to solve a set of problems that do need to be solved, and are worth deploying.
上記の分析に基づいて、DNSSEC拡張は解決する必要があり、導入する価値があるかの問題を解くように見えるん。
Security Considerations
セキュリティの考慮事項
This entire document is about security considerations of the DNS. The authors believe that deploying DNSSEC will help to address some, but not all, of the known threats to the DNS.
この文書全体は、DNSのセキュリティ上の考慮事項についてです。著者は、DNSSECを導入すると、いくつかを解決するのに役立ち、すべてではありませんが、DNSへの既知の脅威のだろうと考えています。
Acknowledgments
謝辞
This note is based both on previous published works by others and on a number of discussions both public and private over a period of many years, but particular thanks go to
このノートでは、他の人が長年にわたってパブリックとプライベートの両方の議論の数に前回発表された作品の両方をベースにしていますが、特定のおかげでに行きます
Jaap Akkerhuis, Steve Bellovin, Dan Bernstein, Randy Bush, Steve Crocker, Olafur Gudmundsson, Russ Housley, Rip Loomis, Allison Mankin, Paul Mockapetris, Thomas Narten Mans Nilsson, Pekka Savola, Paul Vixie, Xunhua Wang, and any other members of the DNS, DNSSEC, DNSIND, and DNSEXT working groups whose names and contributions the authors have forgotten, none of whom are responsible for what the authors did with their ideas.
ヤープAkkerhuis、スティーブBellovin氏、ダン・バーンスタイン、ランディブッシュ、スティーブクロッカー、オラフルグドムンソン、ラスHousley、リップルーミス、アリソンマンキン、ポール・モカペトリス、トーマスNarten氏マン・ニルソン、ペッカSavola、ポール・ヴィクシー、Xunhua王、および任意の他のメンバー名前と貢献著者が忘れてしまったDNS、DNSSEC、DNSIND、およびDNSEXTワーキンググループのどれも作者が自分のアイデアをやったことの責任ではありません。
As with any work of this nature, the authors of this note acknowledge that we are standing on the toes of those who have gone before us. Readers interested in this subject may also wish to read [Bellovin95], [Schuba93], and [Vixie95].
この自然界のすべての作業と同じように、このノートの著者は、私たちは私たちの前に行っている人たちのつま先の上に立っていることを認めます。この主題に興味がある読者はまた、[Vixie95] [Schuba93]、[Bellovin95]を読みたい、とすることができます。
Normative References
引用規格
[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月。
[RFC1123] Braden, R., "Requirements for Internet Hosts - Application and Support", STD 3, RFC 1123, October 1989.
[RFC1123]ブレーデン、R.、 "インターネットホストのための要件 - 、アプリケーションとサポート"、STD 3、RFC 1123、1989年10月。
[RFC2181] Elz, R. and R. Bush, "Clarifications to the DNS Specification", RFC 2181, July 1997.
"DNS仕様の明確化" [RFC2181]エルツ、R.とR.ブッシュ、RFC 2181、1997年7月。
[RFC2308] Andrews, M., "Negative Caching of DNS Queries (DNS NCACHE)", RFC 2308, March 1998.
[RFC2308]アンドリュース、M.、 "DNSクエリのネガティブキャッシュ（DNS NCACHE）"、RFC 2308、1998年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 3rd, D., and B. Wellington, "Secret Key Transaction Authentication for DNS (TSIG)", RFC 2845, May 2000.
[RFC2845]いるVixie、P.、グドムンソン、O.、イーストレイク3日、D.、およびB.ウェリントン、 "DNSのための秘密鍵トランザクション認証（TSIG）"、RFC 2845、2000年5月。
[RFC2930] Eastlake 3rd, D., "Secret Key Establishment for DNS (TKEY RR)", RFC 2930, September 2000.
[RFC2930]イーストレーク第3、D.、 "DNSのための秘密鍵確立（TKEYのRR）"、RFC 2930、2000年9月。
[RFC3007] Wellington, B., "Secure Domain Name System (DNS) Dynamic Update", RFC 3007, November 2000.
[RFC3007]ウェリントン、B.、RFC 3007、2000年11月 "ドメインネームシステム（DNS）動的更新をセキュア"。
[RFC2535] Eastlake 3rd, D., "Domain Name System Security Extensions", RFC 2535, March 1999.
[RFC2535]イーストレーク第3、D.、 "ドメインネームシステムのセキュリティ拡張機能"、RFC 2535、1999年3月。
Informative References
参考文献
[RFC3552] Rescorla, E. and B. Korver, "Guidelines for Writing RFC Text on Security Considerations", BCP 72, RFC 3552, July 2003.
[RFC3552]レスコラ、E.とB.コーバー、BCP 72、RFC 3552、2003年7月、 "セキュリティ上の考慮事項の書き方RFCテキストのためのガイドライン"。
[Bellovin95] Bellovin, S., "Using the Domain Name System for System Break-Ins", Proceedings of the Fifth Usenix Unix Security Symposium, June 1995.
[Bellovin95] Bellovin氏、S.、「システムブレークイン用のドメインネームシステムを使用して」、第五のUsenix Unixのセキュリティシンポジウム、1995年6月の議事。
[Galvin93] Design team meeting summary message posted to dns-security@tis.com mailing list by Jim Galvin on 19 November 1993.
[Galvin93]デザインチームミーティングサマリメッセージは、1993年11月19日にジム・ガルビンでメーリングリストをdns-security@tis.comしました。
[Schuba93] Schuba, C., "Addressing Weaknesses in the Domain Name System Protocol", Master's thesis, Purdue University Department of Computer Sciences, August 1993.
[Schuba93] Schuba、C.、修士論文、コンピュータ・サイエンスのパデュー大学学部、1993年8月「ドメインネームシステムプロトコルの弱点に対処します」。
[Vixie95] Vixie, P, "DNS and BIND Security Issues", Proceedings of the Fifth Usenix Unix Security Symposium, June 1995.
[Vixie95]いるVixie、P、 "DNSおよびBINDセキュリティの問題"、第五のUsenix Unixのセキュリティシンポジウム、1995年6月の議事。
Authors' Addresses
著者のアドレス
Derek Atkins IHTFP Consulting, Inc. 6 Farragut Ave Somerville, MA 02144 USA
デレク・アトキンスIHTFPコンサルティング株式会社6ファラガットアベニューサマービル、MA 02144 USA
EMail: derek@ihtfp.com
メールアドレス：derek@ihtfp.com
Rob Austein Internet Systems Consortium 950 Charter Street Redwood City, CA 94063 USA
ロブAusteinとインターネットシステムコンソーシアム950憲章通りカリフォルニア州レッドウッドシティー94063 USA
EMail: sra@isc.org
メールアドレス：sra@isc.org
Full Copyright Statement
完全な著作権声明
Copyright (C) The Internet Society (2004). 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.
著作権（C）インターネット協会（2004）。この文書では、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 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が表すまたはインターネットソサエティおよびインターネット・エンジニアリング・タスク・フォース放棄すべての保証、明示または、（もしあれば）後援ISに設けられています。黙示、情報の利用は、特定の目的に対する権利または商品性または適合性の黙示の保証を侵害しない任意の保証含むがこれらに限定されません。
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に情報を記述してください。
Acknowledgement
謝辞
Funding for the RFC Editor function is currently provided by the Internet Society.
RFC Editor機能のための基金は現在、インターネット協会によって提供されます。