RFC3833 日本語訳
3833 Threat Analysis of the Domain Name System (DNS). D. Atkins, R.Austein. August 2004. (Format: TXT=39303 bytes) (Status: INFORMATIONAL)
プログラムでの自動翻訳です。
英語原文
Network Working Group D. Atkins
Request for Comments: 3833 IHTFP Consulting
Category: Informational R. Austein
ISC
August 2004
コメントを求めるワーキンググループD.アトキンス要求をネットワークでつないでください: 3833年のIHTFPコンサルティングカテゴリ: 情報のR.Austein ISC2004年8月
Threat Analysis of the Domain Name System (DNS)
ドメインネームシステムの脅威分析(DNS)
Status of this Memo
この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).
Copyright(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 Security Extensions(DNSSEC)は最後の10年間の大部分開発中ですが、IETFはDNSSECが保護するように設計されている特定のセットの脅威を一度も、書き留めたことがありません。 他の欠点の中では、この馬の前のカート状況でDNSSECがデザイン目標を達成するかどうか決定するのが難しくなりました、デザイン目標がよく指定されないので。 そうする際に、この注意は、DNSへの知られている脅威のいくつかを記録するのを試みて、これらの脅威に対して防御する際にDNSSECが有益な手段であるというどんな範囲(もしあれば)まで測定するかを試みます。
1. Introduction
1. 序論
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への最も早い組織化された作業はチーム会議が1993年11月にヒューストンにおける28番目のIETFミーティングで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のために範囲からそういうものとして統治されました。
Atkins & Austein Informational [Page 1] RFC 3833 DNS Threat Analysis August 2004
[1ページ]RFC3833DNS脅威分析2004年8月の情報のアトキンスとAustein
- 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.
多くの詳細決定がその後の10年間まだ作られていない(そして、いくつかの場合、実装経験の後に作り変えられます)ことでしたが、基本型とデザイン目標は修理されたままで残っていました。
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が保護することを意図する攻撃の種類、または必要なセキュリティー・サービスのリストの後ろのヒューストンミーティングから出て来た理由を指定するのを試みませんか? それに関しては、私たちは1990年に元々スティーブBellovinによって書かれた論文に支持しますが、1995年まで発行しなくしに行かなければなりません、Bellovinが紙のエピローグ[Bellovin95]で説明した理由で。
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.
それに対して防御するように設計されたプロトコルで就業した10年間後に脅威分析を発表するのが少し奇妙に思えるかもしれませんが、それにもかかわらず、それはこの注意がするのを試みることです。 決してよりよく遅くない
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]、[RFC2181]、[RFC2308]、[RFC2671]、[RFC2845]、[RFC2930]、[RFC3007]、および[RFC2535]のセクション6.1。
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"という用語を使用して、TKEYとTSIGを別々のメカニズムと呼びます、TKEYやTSIGなどのチャンネルセキュリティー対策は、また、「DNSを固定します」というより大きい問題の一部であり、その結果、総合的なセットの「DNSセキュリティ拡張子」の一部であるとしばしば考えられます。 これはプロトコルが発展した方法(ゾーン転送やダイナミックな更新要求などのある操作のための推定上より簡単なチャンネル機密保護モデルの導入)を一部反映して、恐らくこの注意の今後の改正で変えられるべきである任意の区別です。
Atkins & Austein Informational [Page 2] RFC 3833 DNS Threat Analysis August 2004
[2ページ]RFC3833DNS脅威分析2004年8月の情報のアトキンスとAustein
2. Known Threats
2. 知られている脅威
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プロトコルのユニークさに特定です。
2.1. Packet Interception
2.1. パケット妨害
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.
DNSに対する最も簡単な脅威のいくつかが様々な形式のパケット妨害です: 中央の猿攻撃、要求を立ち聞きするのはレゾルバへの本当の応答後部などを打つ偽造している応答に結合しました。 これらのシナリオのいずれではも、攻撃者は、そのパーティーに何でも信じて欲しくてもパーティーへ行く(通常レゾルバ)ように単に言うことができます。 パケット妨害攻撃はDNSに全くユニークではありませんが、DNSの未署名の単一のunencrypted UDPパケットで全体の質問か応答を送る普通の振舞いで、これらの攻撃は共有されるかトランジットネットワークでパケットを妨害する能力があるどんな悪者にも特に簡単になります。
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).
確かに、DNSがメッセージであるとTSIGかIPsecなどのチャンネルセキュリティー対策を使用することで署名するか、またはそれらを暗号化するのさえIPsecを使用することで可能であるだろうという間、これは妨害攻撃のための非常に良いソリューションでないでしょう。 まず最初に、このアプローチはDNSメッセージあたり1つのかなり高い加工費を課すでしょう、どんな特定の質問も決議するのにかかわるかもしれないすべてのパーティーの間の双方の信頼関係を確立して、維持すると関連している非常に高い費用と同様に。 大いに使用されたネームサーバ(ルートゾーンへのサーバなどの)において、この費用はほぼ確実に法外に高いでしょう。 しかしながら、さらに重要であるのは、そのようなデザインにおける基本的な信頼モデルが間違っているだろうということです、せいぜいホップごとの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ルックアップ操作の間のこのクラスの問題のためのはるかに良いソリューションです。
Atkins & Austein Informational [Page 3] RFC 3833 DNS Threat Analysis August 2004
[3ページ]RFC3833DNS脅威分析2004年8月の情報のアトキンスとAustein
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).
- パケット妨害(そして以下で議論した他のテクニックで)で攻撃される可能性にそれ自体をゆだねてください。
2.2. ID Guessing and Query Prediction
2.2. ID推測と質問予測
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に関連しているサーバUDPポートがよく知られる値である、与えられたクライアントとサーバのためのIDとクライアントUDPポートの2**32可能な組み合わせしか、DNSヘッダーのID分野が16ビットの分野にすぎないので、ありません。これは、特に大きい範囲でなく、また力任せの検索から守るために十分ではありません。 その上、実際には、前のトラフィックからクライアント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推測が攻撃者がにせのデータを注入するのを許容でなできるくらい知識にレゾルバがそうであるQNAMEsと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.
この攻撃がリゾルバの振舞いを予測するのを当てにするので、犠牲者が知られている状態にあるとき、うまくいくのがおそらくだいたい、犠牲者が最近リブートしたか、ある他の動作で犠牲者の振舞いが攻撃者によって影響を及ぼされた、または犠牲者が攻撃者にとって知られている何らかの第三者動作に応じているので(予測できる方法で)。
Atkins & Austein Informational [Page 4] RFC 3833 DNS Threat Analysis August 2004
[4ページ]RFC3833DNS脅威分析2004年8月の情報のアトキンスとAustein
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か何らかの同等なメカニズムを使用するはずです。
2.3. Name Chaining
2.3. 名前推論
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特有の脅威は名前推論攻撃です。 これらは時々「キャッシュ中毒」攻撃と呼ばれるより大きいクラスの名前ベースの攻撃の部分集合です。 関連性がないかどうか応答メッセージでオリジナルの質問にRRsをチェックする長年のディフェンスでほとんどの名前ベースの攻撃を部分的に緩和できますが、そのようなディフェンスは名前推論攻撃を捕らえません。 基本的な攻撃の数回の変化がありますが、それらが皆、共通であることはRDATA部分(正しい手の側)がDNS名(または、いくつかの場合におけるDNS名ではありませんが、直接名前をDNSに写像する何か)を含んでいるDNS RRsにかかわるということです。 どんなそのような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.
彼らが攻撃者の選ぶことの位置に犠牲者の質問を向け直すことができるので、RRsのこのクラスで最も悪い例は、CNAMEと、NSと、DNAME RRsです。 MXとSRVのようなRRsはいくらか危険ではありませんが、また、原則として、攻撃者の選ぶことの位置でさらなるルックアップの引き金となるのに彼らを使用できます。 アドレスRRがAなどのようにタイプするか、AAAAはそれらのRDATAにDNS名を持っていませんが、またはまた、DNSを使用することでIN-ADDR.ARPAとIP6.ARPA木が索引をつけられるので、名前推論攻撃にIPv4とIPv6アドレス、これらのレコード種類のコード化は使用できます。
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).
- 犠牲者は恐らく攻撃者か第三者の扇動のときに質問を発行します。 いくつかの場合、質問自体は名前に攻撃で関係ないかもしれません(すなわち、攻撃者はある他の名前に関する偽情報を注入する手段としてただこの質問を使用しています)。
Atkins & Austein Informational [Page 5] RFC 3833 DNS Threat Analysis August 2004
[5ページ]RFC3833DNS脅威分析2004年8月の情報のアトキンスとAustein
- 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).
- 攻撃者の応答はDNS名がそれらのRDATAにある1RRsを含んでいます。 この攻撃がどの特定の形を取るかによって、オブジェクトはこの応答のAdditional部を通ってそれらの名前に関連している誤ったデータを犠牲者のキャッシュに注ぐことになっているかもしれません; または、攻撃者の選ぶことのサーバに質問の次のステージを向け直すことになっているかもしれません(容易にただ一つの応答に収まるか、またはそれらがリゾルバのディフェンスを超えて潜入するというより良い見込みを持っているところに応答のAuthorityかAnswer部の偽りを置くために犠牲者のキャッシュにより複雑な偽りを注ぐために)。
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.
攻撃者が攻撃者のものの特定の名前のために選ぶことについて質問するのに犠牲者を誘発するのが、例えばかなり簡単であるなら、このクラスの攻撃は特に油断のならないです、1×1画素の「ウェブバグ」グラフィックへのリンクを犠牲者へのText/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
DNSSECはこのクラスの攻撃の(すべて?)の変化を大部分に対する良いディフェンスに供給するはずです。 署名をチェックすることによって、レゾルバは、名前に関連しているデータが本当に代理権によってスペースというDNS名のその部分に挿入されたかどうかと決心できます。 より正確に、レゾルバは、データを注入した実体がそうしたか否かに関係なく、申し立てによると秘密のキーにだれのものにアクセスするように決心できます。
Atkins & Austein Informational [Page 6] RFC 3833 DNS Threat Analysis August 2004
[6ページ]RFC3833DNS脅威分析2004年8月の情報のアトキンスとAustein
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.
対応する公開鍵はレゾルバが先の知識を持っている公開鍵から始まる親の署名の予想されたチェーンと共に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では、同じデータの署名している正式のバージョンをとって来るために一時接着剤を受け入れることによって攻撃を検出するのは可能です、署名がその時正式のバージョンでチェックして。
2.4. Betrayal By Trusted Server
2.4. 信じられたサーバによる裏切り
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
厳密にDNSプロトコル見地から見られます、この種類の裏切りとパケット妨害攻撃の唯一の違いはこの場合クライアントが自発的に要求を送ったということです。
Atkins & Austein Informational [Page 7] RFC 3833 DNS Threat Analysis August 2004
[7ページ]RFC3833DNS脅威分析2004年8月の情報のアトキンスとAustein
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.
攻撃者。 これに対するディフェンスはパケット妨害攻撃と同じです: レゾルバは、それが信じるのを選んだサーバを認証するのに、それ自体で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.
適切にパラノイアのレゾルバがいつもそれ自身の署名の照合を実行しなければならなくて、この規則が、レゾルバを引き抜くのに当てはまりさえするという結論から逃げるのは難しいです。
2.5. Denial of Service
2.5. サービス妨害
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はサービス不能攻撃に被害を受け易いです。 DNSSECがこれを助けないで、事実上問題を署名をチェックするレゾルバには、より悪くするかもしれなくて、以来署名の両方をチェックすると、DNSメッセージあたりの加工費を増強して、また、いくつかの場合、質疑に答えるのに必要であるメッセージの数を増強できます。 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はここで助けません。
2.6. Authenticated Denial of Domain Names
2.6. ドメイン名の認証された否定
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.
多くの議論がドメイン名の認証された否定の問題の上で行われました。 特定の質問は名前の非存在を認証するための要件があるかどうかということです。 問題はレゾルバが、攻撃者がいつ応答からRRsを取り外すかを検出するはずであることができるかどうかということです。
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
一般パラノイアは別として、不在が即座の失敗(MXとSRV RRsがいなくて寂しいA RRsへのどのフェイルオーバーなどの)以外の動作を引き起こすRRタイプの存在は本当の脅威を構成します。 論証上、いくつかの場合、RRの不在さえそうです。
Atkins & Austein Informational [Page 8] RFC 3833 DNS Threat Analysis August 2004
[8ページ]RFC3833DNS脅威分析2004年8月の情報のアトキンスとAustein
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.
問題を検討しました。 問題は残っています: この脅威はどれくらい重大ですか? 明確に、脅威は存在しています。 一般的なパラノイアは、いつか、それが、ある主要な新聞の第一面にあると言います、私たちが今日この攻撃にかかわるもっともらしいシナリオを想像できないでも。 これは、このリスクの何らかの緩和が必要であることを含意します。
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.
認証された否定メカニズムの一部として適切なワイルドカードRRsの非存在を立証するのが必要であり、そのような証拠が、深く1個以上のラベルであるゾーンで非存在を立証するのをワイルドカードRRsの複数の離散的なセットを要求するかもしれないことに注意してください。
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保護は接着剤記録などの非信頼すべきデータをカバーしていません。
2.7. Wildcards
2.7. ワイルドカード
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名のための発生源認証をデータ保全とデータに提供するか。 概念的に、ワイルドカード名があるRRsは、.2セクション4.3RFC1034で説明された合っている規則に従ってRRsを急いで統合するためのパターンです。 ワイルドカード名の振舞いを制御する規則は不注意なゾーンの管理者のためにそれらを罠にすることができるいくつかの気まぐれを持っていますが、多くのサイトがワイルドカードRRsの重い使用をするのは、明確です、特にワイルドカードMX RRs。
In order to provide the desired services for wildcard RRs, we need to do two things:
必要なサービスをワイルドカードRRsに供給するために、私たちは、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).
- 私たちはRRsがどのワイルドカードで使用されているかを(すなわち、私たちは、統合規則が適切であることを示す必要があります)彼らが存在するならワイルドカードを道を支配する統合規則に従って無関係のRRにするどんなRRsの非存在にも証明する方法を必要とします。
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は上で説明された系列に沿ってメカニズムを含んでいます。系列はレゾルバが、答えを生成するとき、ネームサーバが正しくワイルドカード拡張規則を適用したことを確かめるのを可能にします。
Atkins & Austein Informational [Page 9] RFC 3833 DNS Threat Analysis August 2004
[9ページ]RFC3833DNS脅威分析2004年8月の情報のアトキンスとAustein
3. Weaknesses of DNSSEC
3. 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クライアントに答えが戻る増強するでしょう。 論証上、DNSSECがアカウントに課すさらなる遅れを取る前にさえ、多くの現在のDNSクライアントが既にせっかち過ぎますが、その話題はこの注意の範囲を超えています。
- 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はレゾルバに根のためのそれらを超えて公開鍵に関する特別な追加知識を持たせますが、一般的な場合では、ルートキーは重要なものです。 したがって、根と特定の目標名の間のゾーンのどれかのどんな感染もその目標名によって所有されていたデータの完全性を保護する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
- DNSSECは、DNSSEC署名を作成しながら、有効にしているレゾルバと実体の間でゆるい時間同期化の要件を作成します。 DNSSECの前では、「経過した」か「相対的な」およそ時間知っていただけであるマシンはDNSでのすべての時間関連の動作を実行できました。 DNSSEC署名の有効期間が「絶対」の時間に基づいているので、有効にしているレゾルバには、ゾーン署名者としての絶対時間の同じ概念が署名が有効期間中に、あるか、または期限が切れたかを決定するためになければなりません。 リゾルバの現在の絶対時間に関する意見を変えることができる攻撃者は使用が吐き出したレゾルバをだますことができます。
Atkins & Austein Informational [Page 10] RFC 3833 DNS Threat Analysis August 2004
[10ページ]RFC3833DNS脅威分析2004年8月の情報のアトキンスとAustein
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.
署名。 ゾーン署名者の現在の絶対時間に関する意見を変えることができる攻撃者は、ゾーン署名者が有効期間が署名者が意図したことに合っていない署名を生成するようにだますことができます。
- 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.
- ゾーンのワイルドカードRRsの可能な存在は認証された否定メカニズムをかなり複雑にします。 DNSSECの開発中である10年間の大部分、これらの問題は不十分に理解されていました。 認証された否定メカニズムが完全に気密であるかどうかと、ワイルドカードが現在でないよくある例のために認証された否定メカニズムを最適化するゾーンで価値があるだろうかどうかに関して質問がありました。 しかしながら、主な問題はただワイルドカードメカニズム自体の固有の複雑さです。 この複雑さで認証された否定証明を生成して、チェックするためのコードはたぶんいくらかこわれやすくなりますが、ワイルドカードをあきらめる代替手段が普及使用のために完全に実用的でないので、私たちはワイルドカードと同居しなければならないでしょう。 質問は提案された最適化でDNSSECのメカニズムが多少こわれやすくなるかどうか1つにただなります。
- 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初公開の期間。
4. Topics for Future Work
4. 今後の活動のための話題
This section lists a few subjects not covered above which probably need additional study, additional mechanisms, or both.
このセクションはたぶん追加研究、追加メカニズム、または両方を必要とする上にカバーされなかったいくつかの対象を記載します。
4.1. Interactions With Other Protocols
4.1. 他のプロトコルとの相互作用
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.
上の議論はDNSプロトコル自体の区域内に排他的な攻撃に集中しました、それらがそうので(いくつか、)、どのDNSSECに対して問題が保護することを意図したか。 しかしながら、他の潜在的な問題がDNSが他のプロトコルと対話する境界にあります。
4.2. Securing DNS Dynamic Update
4.2. 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
DNSSECに結合されると、DNSのダイナミックなアップデートは多くの潜在的な問題を開きます。 非安全なゾーンのダイナミックなアップデートは、アップデートしているクライアントをサーバに認証するのにTSIGを使用できます。TSIGがそうしない間、非常によく比例してください、(それは共有されたキーの手動の構成を必要とします。
Atkins & Austein Informational [Page 11] RFC 3833 DNS Threat Analysis August 2004
[11ページ]RFC3833DNS脅威分析2004年8月の情報のアトキンスとAustein
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.
DNSの間でネームサーバとそれぞれのTSIGクライアント)、それは地方のDNSネームサーバをアップデートするDHCPサーバなどの制限されたか閉じている環境でうまくいきます。
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が実際のデータではなく、DNSトランザクションを保護するだけであり、TSIGがDNSゾーンに挿入されないので、レゾルバはゾーンへの変化について確かめる方法としてTSIGを使用できません。 これはそれを意味します:
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.
どちらかの場合では、ゾーンに署名するキーは、アップデートされたゾーンで入賞するために署名しているRRsetsを作成するために利用可能でなければなりません。 事実このキーがオンラインと(少なくとも利用可能)でなければならないは潜在的セキュリティリスクです。
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.
だれがゾーンでどのRRsetsに変化するものを作ることができるかに関する方針を説明することに関して他の脅威があります。 Secureダイナミック・アップデートにおける現在のアクセス制御体系は公正に制限されます。 そのそれぞれが異種のアクセサリーを必要とするかもしれない複数の実体にはDNSゾーン情報をアップデートすることへのきめ細かに粒状のアクセスを与える方法が全くありません。 例えば、アリスは、新しいノードをゾーンに追加できませんし、既存のノードを変えますが、またそれらを移すことができない必要があるかもしれません。 ボブは、ゾーンを取り除きますが、それらを加えることができない必要があるかもしれません。 キャロルは、ノードを加えるか、取り除くか、または変更できる必要があるかもしれませんが、Aだけが記録します。
Scaling properties of the key management problem here are a particular concern that needs more study.
ここのかぎ管理問題のスケーリング特性は、より多くの研究を必要とする特別の関心です。
4.3. Securing DNS Zone Replication
4.3. DNSがゾーン模写であると機密保護します。
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
前項で議論するように、そういうもののDNSSECは、正常なDNS質問プロトコルの上で発生源認証サービスをデータ保全とデータに提供するのを試みます。 [RFC3552]で議論した用語を使用して、DNSSECは「オブジェクトセキュリティ」を正常なDNS質問プロトコルに提供します。 しかしながら、全体のDNSゾーンを模写する目的のために、DNSSECはオブジェクトセキュリティを提供しません、ゾーンが委譲ポイントで未署名のNS RRsと接着剤を含んでいるので。 TSIGの使用
Atkins & Austein Informational [Page 12] RFC 3833 DNS Threat Analysis August 2004
[12ページ]RFC3833DNS脅威分析2004年8月の情報のアトキンスとAustein
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.
まだオブジェクトセキュリティを完全なゾーンに提供していないのを除いて、操作が「チャンネルセキュリティ」を提供するゾーン転送(AXFRかIXFR)を保護してください。 それでも、ゾーン転送にかかわる信頼関係はホップごとにたいへんゾーンの管理者を信じるネームサーバオペレータの終わりから終わりへの問題よりむしろ他のネームサーバオペレータを信じるネームサーバオペレータの問題です。
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がまだ願わしさについて議論していない、または、そのような増進のための要件。
5. Conclusion
5. 結論
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拡張子は、解決される必要がある1セットの問題を解決するように見えて、配布する価値があります。
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,
Jaap Akkerhuis、スティーブBellovin、ダン・バーンスタイン、ランディ・ブッシュ、スティーブ・クロッカー、Olafurグドムンソン、ラスHousley、Ripルーミス、アリソン・マンキン、ポールMockapetris、トーマスNartenはニルソンを配置します、ペッカSavola、ポールVixie、Xunhuaワング
Atkins & Austein Informational [Page 13] RFC 3833 DNS Threat Analysis August 2004
[13ページ]RFC3833DNS脅威分析2004年8月の情報のアトキンスとAustein
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.
そして、作者が名前と貢献を忘れた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].
この種のどんな仕事のようにも、この注意の作者は、私たちが私たちの前に行った人の爪先を踏んでいると認めます。 また、この対象に興味を持っている読者は[Bellovin95]、[Schuba93]、および[Vixie95]を読みたがっているかもしれません。
Normative References
引用規格
[RFC1034] Mockapetris, P., "Domain names - concepts and
facilities", STD 13, RFC 1034, November 1987.
[RFC1034]Mockapetris、P.、「ドメイン名--、概念と施設、」、STD13、RFC1034、11月1987日
[RFC1035] Mockapetris, P., "Domain names - implementation and
specification", STD 13, RFC 1035, November 1987.
[RFC1035]Mockapetris、P.、「ドメイン名--、実装と仕様、」、STD13、RFC1035、11月1987日
[RFC1123] Braden, R., "Requirements for Internet Hosts -
Application and Support", STD 3, RFC 1123, October 1989.
[RFC1123]ブレーデン、R.、「インターネットホストのための要件--、アプリケーションとサポート、」、STD3、RFC1123、10月1989日
[RFC2181] Elz, R. and R. Bush, "Clarifications to the DNS
Specification", RFC 2181, July 1997.
[RFC2181] ElzとR.とR.ブッシュ、「DNS仕様への明確化」、RFC2181、1997年7月。
[RFC2308] Andrews, M., "Negative Caching of DNS Queries (DNS
NCACHE)", RFC 2308, March 1998.
[RFC2308] アンドリュース、M.、「DNS質問(DNS NCACHE)の否定的キャッシュ」、RFC2308、1998年3月。
[RFC2671] Vixie, P., "Extension Mechanisms for DNS (EDNS0)", RFC
2671, August 1999.
[RFC2671] Vixie、P.、「DNS(EDNS0)のための拡張機能」、RFC2671、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)のための秘密鍵トランザクション認証」、RFC2845)は2000がそうするかもしれません。
[RFC2930] Eastlake 3rd, D., "Secret Key Establishment for DNS
(TKEY RR)", RFC 2930, September 2000.
[RFC2930] イーストレーク3番目、D.、「DNS(TKEY RR)のための秘密鍵設立」、RFC2930、2000年9月。
[RFC3007] Wellington, B., "Secure Domain Name System (DNS) Dynamic
Update", RFC 3007, November 2000.
[RFC3007]ウェリントン、2000年11月のB.、「安全なドメインネームシステム(DNS)ダイナミック・アップデート」RFC3007。
[RFC2535] Eastlake 3rd, D., "Domain Name System Security
Extensions", RFC 2535, March 1999.
[RFC2535] イーストレーク3番目、D.、「ドメインネームシステムセキュリティ拡大」、RFC2535、1999年3月。
Atkins & Austein Informational [Page 14] RFC 3833 DNS Threat Analysis August 2004
[14ページ]RFC3833DNS脅威分析2004年8月の情報のアトキンスとAustein
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.Korver、「セキュリティ問題に関するテキストをRFCに書くためのガイドライン」BCP72、2003年7月のRFC3552。
[Bellovin95] Bellovin, S., "Using the Domain Name System for System
Break-Ins", Proceedings of the Fifth Usenix Unix
Security Symposium, June 1995.
S. [Bellovin95]Bellovin、「システム不法侵入にドメインネームシステムを使用すること」での第5Usenix 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]シューバ、C.、「ドメインネームシステムにおけるアドレシング弱点は議定書を作ります」、Masterの論文、コンピューターサイエンシズのパデュー大学部、1993年8月。
[Vixie95] Vixie, P, "DNS and BIND Security Issues", Proceedings of
the Fifth Usenix Unix Security Symposium, June 1995.
[Vixie95] Vixieと、Pと、「DNSとひもの安全保障問題」、第5Usenix unixセキュリティシンポジウム、6月1995の議事
Authors' Addresses
作者のアドレス
Derek Atkins IHTFP Consulting, Inc. 6 Farragut Ave Somerville, MA 02144 USA
Inc.6ファラガット・Ave MA02144サマービル(米国)に相談するデリックアトキンスIHTFP
EMail: derek@ihtfp.com
メール: derek@ihtfp.com
Rob Austein Internet Systems Consortium 950 Charter Street Redwood City, CA 94063 USA
ロブAusteinインターネットSystems共同体950憲章通りカリフォルニア94063レッドウッドシティー(米国)
EMail: sra@isc.org
メール: sra@isc.org
Atkins & Austein Informational [Page 15] RFC 3833 DNS Threat Analysis August 2004
[15ページ]RFC3833DNS脅威分析2004年8月の情報のアトキンスとAustein
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.
Copyright(C)インターネット協会(2004)。 このドキュメントはBCP78に含まれた権利、ライセンス、および制限を受けることがあります、そして、そこに詳しく説明されるのを除いて、作者は彼らのすべての権利を保有します。
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.
このドキュメントと「そのままで」という基礎と貢献者、その人が代表する組織で提供するか、または後援されて、インターネット協会とインターネット・エンジニアリング・タスク・フォースはすべての保証を放棄します、と急行ORが含意したということであり、他を含んでいて、ここに含まれて、情報の使用がここに侵害しないどんな保証も少しもまっすぐになるという情報か市場性か特定目的への適合性のどんな黙示的な保証。
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はどんなIntellectual Property Rightsの正当性か範囲、実装に関係すると主張されるかもしれない他の権利、本書では説明された技術の使用またはそのような権利の下におけるどんなライセンスも利用可能であるかもしれない、または利用可能でないかもしれない範囲に関しても立場を全く取りません。 または、それはそれを表しません。どんなそのような権利も特定するどんな独立している取り組みも作りました。 BCP78とBCP79でRFCドキュメントの権利に関する手順に関する情報を見つけることができます。
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倉庫からこの仕様のimplementersかユーザによるそのような所有権の使用のために許可を得ることができます。
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機能のための基金は現在、インターネット協会によって提供されます。
Atkins & Austein Informational [Page 16]
アトキンスとAustein情報です。[16ページ]
一覧
スポンサーリンク
