[要約] RFC 3833は、ドメインネームシステム(DNS)が直面する脅威とセキュリティ上の問題を分析することを目的としています。この文書は、DNSの設計と運用における脆弱性を明らかにし、攻撃者がこれらの弱点を利用する可能性のある方法を詳述しています。関連するRFCには、DNSセキュリティ拡張(DNSSEC)に関するRFC 4033、RFC 4034、RFC 4035があります。
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)
ドメイン名システム（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）The Internet Society（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）は過去10年の大半にわたって開発中でしたが、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に関する最も初期の組織的な取り組みは、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自体の範囲から除外されました。
- 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年にSteve Bellovinが最初に書いた論文に戻る必要がありますが、Bellovinが論文のエピローグ[Bellovin95]で説明した理由から、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.
それに対して防御するように設計されたプロトコルの作業を開始してから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]、[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ドキュメントで指定されたコア階層公開キーと署名メカニズムを指し、TKEYと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.
DNSに対する最も単純な脅威のいくつかは、さまざまな形式のパケット傍受です。中間者攻撃、リクエストの盗聴と、リゾルバーへの実際の応答よりも早く届くなりすまし応答の組み合わせなどです。これらのシナリオのいずれにおいても、攻撃者は、その当事者に信じ込ませたいことを何でも、どちらの当事者（通常はリゾルバー）にも伝えることができます。パケット傍受攻撃はDNSに固有のものではありませんが、DNSのクエリまたは応答全体を単一の署名しない、暗号化されていない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).
TSIGやIPsecなどのチャネルセキュリティメカニズムを使用してDNSメッセージに署名したり、IPsecを使用して暗号化したりすることは確かに可能ですが、これは傍受攻撃に対するあまり良い解決策ではありません。第一に、このアプローチは、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は、ゾーン転送、動的更新、あるいはすべてのDNSSEC署名を自分ではチェックしないリゾルバー（スタブなど）のように、特定のクライアントと特定のサーバーの間に特定の信頼関係があるDNSプロトコルの領域にその場所を持っています。
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とQTYPEに関する知識（または推測）と組み合わせることで、リゾルバーは偽の応答の注入に対して脆弱なままになります。
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の署名チェックを実行しないリゾルバーは、TSIGまたは同等のメカニズムを使用して、DNSSECの署名チェックを実行する再帰ネームサーバーとの通信の整合性を確保する必要があります。
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名に直接マップされるもの）を含むDNS RRが関与していることです。そのような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名を持つ1つ以上のRRが含まれます。この攻撃がどのような特定の形態をとるかによって、目的は、この応答の追加セクションを介してそれらの名前に関連付けられた誤ったデータを被害者のキャッシュに注入することか、あるいはクエリの次の段階を攻撃者が選択したサーバーにリダイレクトすること（単一の応答に簡単に収まるよりも複雑な嘘を被害者のキャッシュに注入するため、あるいはリゾルバーの防御をすり抜ける可能性が高い応答の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.
このクラスの攻撃は、攻撃者が被害者を挑発して攻撃者が選択した特定の名前をクエリさせることが非常に簡単であることを考えると、特に陰湿です。例えば、被害者へのテキスト/HTMLメールに1x1ピクセルの「ウェブバグ」画像へのリンクを埋め込むことによってです。被害者のメール閲覧プログラムがそのようなリンクをたどろうとすると、結果として攻撃者が選択した名前の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.
パケット傍受攻撃のもう1つのバリエーションは、偶然であれ意図的であれ、それほど信頼できないことが判明した信頼できるサーバーです。多くのクライアントマシンはスタブリゾルバーでのみ構成されており、信頼できるサーバーを使用して、すべての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はサービス拒否攻撃に対して脆弱です。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もここでは役立ちません。
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.
一般的な用心深さはさておき、即時障害以外のアクション（A RRにフェイルオーバーする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の不在を証明する必要があること、および1つ以上のラベルの深さを持つゾーンでは、そのような証明は複数の個別のセットのワイルドカード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:
WildCard 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).
- 存在した場合、ワイルドカード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クライアントに回答を戻すのにかかる時間を増やします。これは、タイムアウトと再クエリの両方をトリガーする可能性があります。おそらく、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 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が開発中であった10年のほとんどにわたり、これらの問題はあまり理解されていませんでした。さまざまな時期に、認証された不在証明メカニズムが完全に完璧であるかどうか、およびゾーン内にワイルドカードが存在しない一般的なケースの認証された不在証明メカニズムを最適化する価値があるかどうかについて疑問がありました。ただし、主な問題は、ワイルドカードメカニズム自体の固有の複雑さにすぎません。この複雑さにより、おそらく認証された不在証明を生成してチェックするためのコードがやや脆弱になりますが、ワイルドカードを完全に放棄する代替案は、広範囲に使用されているため実用的ではないため、ワイルドカードと共存する必要があります。問題は、提案された最適化が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.
上記の議論は、DNSプロトコル自体の境界内での攻撃のみに集中しています。これは、DNSSECが保護することを目的とした問題であるためです。ただし、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.
DNS動的更新は、DNSSECと組み合わせると、多くの潜在的な問題を引き起こします。非セキュアゾーンの動的更新では、TSIGを使用して、更新クライアントをサーバーに認証できます。TSIGはあまりうまくスケーリングされませんが（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.
いずれの場合も、ゾーン署名鍵を使用できるようにして、更新されたゾーンに配置する署名付きRRsetを作成する必要があります。この鍵がオンライン（または少なくとも利用可能）でなければならないという事実は、潜在的なセキュリティリスクです。
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のシリアルフィールドへの更新も必要です。理論的には、これは上記のオプションのいずれかを介して処理することもできますが、実際には（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.
ゾーン内のどのRRsetにどのような変更を加えることができるかというポリシーを記述するという点で、他の脅威があります。安全な動的更新の現在のアクセス制御スキームはかなり限られています。DNSゾーン情報の更新に対して、複数のエンティティにきめ細かいアクセス権を与える方法はありません。たとえば、アリスはゾーンに新しいノードを追加したり、既存のノードを変更したりする必要があるかもしれませんが、それらを削除する必要はありません。ボブはゾーンを削除できる必要があるかもしれませんが、それらを追加する必要はありません。キャロルは、ノードを追加、削除、または変更できる必要があるかもしれませんが、Aレコードのみです。
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クエリプロトコルに「オブジェクトセキュリティ」を提供します。ただし、DNSゾーン全体を複製する目的では、DNSSECはオブジェクトセキュリティを提供しません。ゾーンには署名されていないNS RRが含まれ、委任ポイントでグルーが含まれているためです。ゾーン転送（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.
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、および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., "Domain names - concepts and facilities", STD 13, RFC 1034, November 1987.
[RFC1035] Mockapetris, P., "Domain names - implementation and specification", STD 13, RFC 1035, November 1987.
[RFC1035] Mockapetris, P., "Domain names - implementation and specification", STD 13, RFC 1035, November 1987.
[RFC1123] Braden, R., "Requirements for Internet Hosts - Application and Support", STD 3, RFC 1123, October 1989.
[RFC1123] Braden, R., "Requirements for Internet Hosts - Application and Support", STD 3, RFC 1123, October 1989.
[RFC2181] Elz, R. and R. Bush, "Clarifications to the DNS Specification", RFC 2181, July 1997.
[RFC2181] Elz, R. and R. Bush, "Clarifications to the DNS Specification", RFC 2181, July 1997.
[RFC2308] Andrews, M., "Negative Caching of DNS Queries (DNS NCACHE)", RFC 2308, March 1998.
[RFC2308] Andrews, M., "Negative Caching of DNS Queries (DNS NCACHE)", RFC 2308, March 1998.
[RFC2671] Vixie, P., "Extension Mechanisms for DNS (EDNS0)", RFC 2671, August 1999.
[RFC2671] Vixie, P., "Extension Mechanisms for DNS (EDNS0)", RFC 2671, August 1999.
[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., Gudmundsson, O., Eastlake 3rd, D., and B. Wellington, "Secret Key Transaction Authentication for DNS (TSIG)", RFC 2845, May 2000.
[RFC2930] Eastlake 3rd, D., "Secret Key Establishment for DNS (TKEY RR)", RFC 2930, September 2000.
[RFC2930] Eastlake 3rd, D., "Secret Key Establishment for DNS (TKEY RR)", RFC 2930, September 2000.
[RFC3007] Wellington, B., "Secure Domain Name System (DNS) Dynamic Update", RFC 3007, November 2000.
[RFC3007] Wellington, B., "Secure Domain Name System (DNS) Dynamic Update", RFC 3007, November 2000.
[RFC2535] Eastlake 3rd, D., "Domain Name System Security Extensions", RFC 2535, March 1999.
[RFC2535] Eastlake 3rd, D., "Domain Name System Security Extensions", RFC 2535, March 1999.
Informative References
参考引用
[RFC3552] Rescorla, E. and B. Korver, "Guidelines for Writing RFC Text on Security Considerations", BCP 72, RFC 3552, July 2003.
[RFC3552] Rescorla, E. and B. Korver, "Guidelines for Writing RFC Text on Security Considerations", BCP 72, RFC 3552, July 2003.
[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., "Using the Domain Name System for System Break-Ins", Proceedings of the Fifth Usenix Unix Security Symposium, June 1995.
[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日にJim Galvinによって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., "Addressing Weaknesses in the Domain Name System Protocol", Master's thesis, Purdue University Department of Computer Sciences, August 1993.
[Vixie95] Vixie, P, "DNS and BIND Security Issues", Proceedings of the Fifth Usenix Unix Security Symposium, June 1995.
[Vixie95] Vixie, P, "DNS and BIND Security Issues", Proceedings of the Fifth Usenix Unix Security Symposium, June 1995.
Authors' Addresses
著者のアドレス
Derek Atkins IHTFP Consulting, Inc. 6 Farragut Ave Somerville, MA 02144 USA
Derek Atkins IHTFP Consulting、Inc。6 Farragut Ave Somerville、MA 02144 USA
EMail: derek@ihtfp.com
Rob Austein Internet Systems Consortium 950 Charter Street Redwood City, CA 94063 USA
ロブオーストインインターネットシステムコンソーシアム950チャーターストリートレッドウッドシティ、カリフォルニア94063 USA
EMail: 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.
Copyright (C) The Internet Society (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.
このドキュメントとここに含まれる情報は、「現状のまま」で提供されます。貢献者、彼/彼女が代表する組織、または彼/彼女を後援する組織（もしあれば）、インターネット協会、およびインターネットエンジニアリングタスクフォースは、明示的または黙示的を問わず、すべての保証を否認します。これには、本書の情報の使用が権利を侵害しないという保証や、商品性または特定の目的への適合性の黙示的な保証が含まれますが、これらに限定されません。
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.
IETF事務局に行われたIPR開示のコピーと、利用可能にするライセンスの保証、またはこの仕様の実装者またはユーザーによるそのような独自の権利の使用のための一般的なライセンスまたは許可を取得するための試みの結果を取得できます。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エディター機能の資金は現在、インターネット協会によって提供されています。