この文書はRFC3833の日本語訳（和訳）です。 この文書の翻訳内容の正確さは保障できないため、 正確な知識や情報を求める方は原文を参照してください。 翻訳者はこの文書によって読者が被り得る如何なる損害の責任をも負いません。 この翻訳内容に誤りがある場合、訂正版の公開や、 誤りの指摘は適切です。 この文書の配布は元のＲＦＣ同様に無制限です。
Network Working Group D. Atkins
Request for Comments: 3833 IHTFP Consulting
Category: Informational R. Austein
ISC
August 2004
Threat Analysis of the Domain Name System (DNS)
ドメインネームシステム（ＤＮＳ）の脅威の分析
Status of this Memo
この文書の状態
This memo provides information for the Internet community. It does
not specify an Internet standard of any kind. Distribution of this
memo is unlimited.
このメモはインターネット共同体のための情報を供給します。これはインター
ネット標準を指定しません。このメモの配布は無制限です。
Copyright Notice
著作権表示
Copyright (C) The Internet Society (2004).
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.
ＤＮＳセキュリティ拡張（ＤＮＳＳＥＣ）が最近１０年間の大部分で開発下
にありましたが、ＩＥＴＦは一度もＤＮＳＳＥＣが守ろうとしている脅威を
書いていません。この本末転倒状態は、設計目標が指定されないためＤＮＳ
ＳＥＣが設計目標を満たすかどうか決定することを難しくしました。この文
書はＤＮＳに対する周知の脅威を文書化しようと試み、そしてこれらの脅威
から守ることにおいてＤＮＳＳＥＣがどの程度に有用な道具であるか考えよ
うと試みます。
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]:
ＩＥＴＦの中のＤＮＳＳＥＣの最も早い組織的な仕事は１９９３年１１月の
ヒューストンでの第２８回のＩＥＴＦの会合におけるＤＮＳ作業班のメンバー
による公開設計チームの会合でした。我々が今日それを知っているＤＮＳＳ
ＥＣの広範囲の概要は、Jim Galvinの会合の結果の要約ですでに明確です
[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.
- ある会合の関係者が無権限者へのＤＮＳデータの漏洩からの保護に興味を
持っていたが、設計チームは「ＤＮＳデータは『公開』」と明示的な決定
をして、データ漏洩の全て脅威を明確にＤＮＳＳＥＣの範囲外と裁定しま
した。
- 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.
- ある会合関係者がアクセス制御の基礎としてＤＮＳクライアントとサーバ
の認証に興味を持っていたが、この仕事は本質的にＤＮＳＳＥＣの範囲外
とされました。
- Backwards compatibility and co-existence with "insecure DNS" was
listed as an explicit requirement.
- 後方互換性と「非安全ＤＮＳ」との共存が明示的な必要条件と記録されま
した。
- The resulting list of desired security services was
- セキュリティサービスの結果として生じる望ましい事のリストは以下でした。
1) data integrity, and
1) データ完全性と
2) data origin authentication.
2) データ源認証。
- The design team noted that a digital signature mechanism would
support the desired services.
- 設計チームはディジタル署名機構が望ましいサービスを支援するであろう
ことを指摘しました。
While a number of detail decisions were yet to be made (and in some
cases remade after implementation experience) over the subsequent
decade, the basic model and design goals have remained fixed.
多くの詳細が１０年間の間決定がされないまま（そしていくつかは実装経験
後に作り直された）、基本的なモデルと設計目標は固定したままでいました。
Nowhere, however, does any of the DNSSEC work attempt to specify in
any detail the sorts of attacks against which DNSSEC is intended to
protect, or the reasons behind the list of desired security services
that came out of the Houston meeting. For that, we have to go back
to a paper originally written by Steve Bellovin in 1990 but not
published until 1995, for reasons that Bellovin explained in the
paper's epilogue [Bellovin95].
しかしながら、ＤＮＳＳＥＣの仕事のどれもＤＮＳＳＥＣが保護を意図する
攻撃の種類や、ヒューストン会合で出た望ましいセキュリティサービスのリ
ストの裏にある理由を指定しようと試みません。それのために、我々は元々
１９９０年にSteve Bellovinによって書かれ、しかし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.
保護を意図するプロトコルの仕事を始めた１０年後に、脅威の分析を公表す
ることは少し妙に思われるかもしれないが、にもかかわらず、これがこの文
書のしようと試みることです。遅れても、ないよりまし。
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].
この文書は読者がＤＮＳとＤＮＳＳＥＣの両方に精通していると想定し、い
ずの指導もしません。この文書の内容に最も関係があるＤＮＳ文書は以下で
す：[RFC1034]、[RFC1035]、[RFC1123]の６．１章、[RFC2181]、[RFC2308]、
[RFC2671]、[RFC2845]、[RFC2930]、[RFC3007]、[RFC2535]。
For purposes of discussion, this note uses the term "DNSSEC" to refer
to the core hierarchical public key and signature mechanism specified
in the DNSSEC documents, and refers to TKEY and TSIG as separate
mechanisms, even though channel security mechanisms such as TKEY and
TSIG are also part of the larger problem of "securing DNS" and thus
are often considered part of the overall set of "DNS security
extensions". This is an arbitrary distinction that in part reflects
the way in which the protocol has evolved (introduction of a
putatively simpler channel security model for certain operations such
as zone transfers and dynamic update requests), and perhaps should be
changed in a future revision of this note.
処理鍵や処理署名のようなチャネルセキュリティ機構がより大きい「ＤＮＳ
セキュリティ」問題の一部であり、これらはしばしば全体的な「ＤＮＳセキュ
リティ拡張」の一部と考えられているけれども、議論の目的で、この文書は
ＤＮＳＳＥＣ文書で指定した階層的な公開鍵と署名機構として用語「ＤＮＳ
ＳＥＣ」を使い、処理鍵と処理署名を別の機構とします。これはプロトコル
の進展した経緯（ゾーン転送や動的更新のようなある特定のオペレーション
のための、単純なチャネルセキュリティモデルの導入導入）を反映した独断
的な区別で、そして多分この文書の将来の修正で変えられるべきです。
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.
ＤＮＳに対する脅威はいくつかに分類でき、そしてその大部分はより一般的
な問題をＤＮＳに適応したもので、少数のものがＤＮＳプロトコルに固有で
す。
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.
ＤＮＳに対しての最も単純な脅威のいくつかはパケット妨害の様々な変形で
す：中間猿攻撃、リゾルバへの真の回答を返す詐欺と組み合わさった立ち聞
き、など。これらのシナリオのどれも、攻撃者は相手を信用するどちらにも
（通常解答者に）話すことができます。パケット妨害攻撃がＤＮＳに特有か
らほど遠いが、ＤＮＳが全部の問合せあるいは回答をひとつの署名なしで暗
号化されていないＵＤＰパケットで送る通常の行動により、共有か通過ネッ
トワーク上のパケットを途中で捕える能力をもつ悪役がこれらの攻撃が簡単
です。
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).
さらに複雑になると、攻撃者が途中で捕えるＤＮＳの質問は攻撃の手段であ
るかもしれません：攻撃者は、応答メッセージの解答部で正しい結果を返し、
例えば名前連鎖攻撃（２.３章参照）で、何他のためのステージを設定するた
めに他の部分を使うかもしれません。
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).
処理署名やＩＰｓｅｃのようなチャネルセキュリティ機構を使ってＤＮＳメッ
セージを署名するか、あるいはＩＰｓｅｃを使ってそれらを暗号化すること
は確かに可能であるであろうが、これは妨害攻撃のために非常に良い解決で
はないでしょう。最初に、この方法はＤＮＳメッセージ毎に非常に高い処理
コストを課し、特定の質問の解決に関係するすべての関係者間の双方向の信
頼関係を確証し維持するのに高いコストを課すでしょう。（ルートゾーンサー
バのような）ひどく利用されているネームサーバで、このコストはほとんど
確実に法外なコストです。より重要なのは、このような設計の基礎をなして
いる信頼モデルは、ＤＮＳメッセージの「ホップ毎のホップ」完全性検査を
供給できるだけで、ＤＮＳデータの生成者（ゾーン管理者）とＤＮＳデータ
の利用者（問合せを引き起こしたアプリケーション）の間のエンドエンド完
全性検査を供給しないということです。
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.
対照的に、ＤＮＳＳＥＣは（正確に使われる時）エンドエンドデータ完全性
検査を供給し、そして基本的なＤＮＳ検索オペレーションでのこの種類のク
ラスでより良い解決です。
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.
処理署名は、ゾーン転送や、動的更新や、特定のクライアントと、自分自身
ですべてのＤＮＳＳＥＣ署名を検証しようとないクライアントのリゾルバの
ような、特定のクライアントとサーバの間の信頼関係がある場合に使う部分
にある、ＤＮＳプロトコルの一部です。
Note that DNSSEC does not provide any protection against modification
of the DNS message header, so any properly paranoid resolver must:
ＤＮＳＳＥＣがＤＮＳメッセージヘッダの修正に対して保護を供給しないの
で、正しく疑うリゾルバは以下をしなければならないことに注意してくださ
い：
- Perform all of the DNSSEC signature checking on its own,
- 自分自身でＤＮＳＳＥＣ署名の検査をすべてを行います、
- Use TSIG (or some equivalent mechanism) to ensure the integrity of
its communication with whatever name servers it chooses to trust,
or
- 信頼できると選択したネームサーバとの通信で完全性を保証するために、
処理署名（あるいは同等のもの）を使用する、あるいは
- 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. 識別子推測と質問予想
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.
ＤＮＳが大部分はＵＤＰ／ＩＰ上で使われるので、攻撃者が転送プロトコル
パラメータと一致するであろうパケットを生成することは比較的容易です。
ＤＮＳヘッダの識別子フィールドはただ１６ビットのフィールドに過ぎませ
ん、そしてＤＮＳと結び付けられたサーバのＵＤＰポートは既知の値です、
それで所定のクライアントとサーバで、識別子とクライアントのＵＤＰポー
トには２**３２の可能な組み合わせがあります。これは特に大きい範囲でな
くて、そして力づくの捜索から保護することに対して十分ではありません；
さらに、実際はクライアントのＵＤＰポートとＩＤの両方がしばしば前のト
ラフィックから予想できます、（ファイアウォールや他の制限のために）ク
ライアントポートは既知の固定した値であることは珍しくありません、それ
でしばしば捜索範囲を２**１６より小さい範囲に小さくなします。
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.
ひとりでに、ＩＤ推測だけでは攻撃者が偽のデータの注入をできませんが、
リゾルバが問い合わせるＱＮＡＭＥやＱＴＹＰＥの知識（あるいは推定）と
組み合わせて、リゾルバを偽応答攻撃に対して脆弱にします。
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.
たいていの他の点で、この攻撃は１パケット妨害攻撃に類似しています。Ｄ
ＮＳＳＥＣ署名を検査するリゾルバは偽応答を認識可能であるでしょう；Ｄ
ＮＳＳＥＣ署名検査を行わないリゾルバは、ＤＮＳＳＥＣ署名を検査する再
帰ネームサーバとの通信の完全性を保証するために処理署名や同等のメカニ
ズムを使うべきです。
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.
多分最もＤＮＳ固有の脅威の種類は、名前連鎖攻撃です。これらはしばしば
より大きいクラス、「キャッシュ中毒」攻撃と呼ばれる名前に基づく攻撃の
の部分グループです。たいていの名前に基づく攻撃は、応答メッセージの元
の問いに関係がない資源レコードの検査の長時間の防御で緩和できますが、
このような防御は名前連鎖攻撃を捉えません。基本的な攻撃についていくつ
かの違いがありますが、共通して資源データ部（右側）にＤＮＳ名（あるい
は、いくつかの場合に直接ＤＮＳ名ではないが、ＤＮＳ名に対応される何か）
を含むＤＮＳ資源レコードを伴うことです。このような資源レコードは、少
なくとも原則として、攻撃者が犠牲者のキャッシュに良くないデータを供給
させるフックで、潜在的にＤＮＳ名に基づいた次の決定を変えます。
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.
この種の資源レコードで最も悪い例は、攻撃者の操作できる場所に犠牲者の
質問を向け直すことができるから、ＣＮＡＭＥとＮＳとＤＮＡＭＥ資源レコー
ドです。ＭＸとＳＲＶのような資源レコードは幾分危険度は低いですが、原
則としてこれらも攻撃者の操作できる場所への検索を引き起こすために使う
ことができます。ＡあるいはＡＡＡＡのようなアドレス資源レコード種別は
資源データにＤＮＳ名を持っていませんが、IN-ADDR.ARPAとIP6.ARPAツリー
がＩＰｖ４とＩＰｖ６アドレスのＤＮＳコーディングを使ってインデックス
を付けるので、これらのレコード種別は同じく名前連鎖攻撃に使えます。
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).
- 攻撃者の回答は資源データにＤＮＳ名と１つ以上の資源レコードを含みま
す；この攻撃がどの形式をとるかによって、目的がこの回答の追加部にお
いた名前に関連する偽データを犠牲者のキャッシュに注入するためかもし
れないし、次の段階の問合せを攻撃者が選択したサーバに向けるかもしれ
ません（単一応答に入るのより複雑な嘘を犠牲者のキャッシュに入れるた
め、あるいはリゾルバの防御を回避しやすい応答の権威部や解答部に置く
ために）。
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.
名前連鎖攻撃のすべてでの共通項は応答メッセージに攻撃者が選択できる任
意のＤＮＳ名を注入し、そして攻撃者がそれらの名前と結び付けられると主
張する情報を注入することを許すということです；犠牲者が名前に関連する
情報のより良い知識がなければ、犠牲者をこの種類の攻撃から守るのは困難
です。
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.
この攻撃のクラスは、例えば、テキスト／ＨＴＭＬメールで１×１画像「ウェ
ブバグ」へのリンクを埋め込むことによって、攻撃者が選択できる特定の名
前を参照するように犠牲者を仕向けることが非常に容易であるとすれば、特
に潜伏的です。もし犠牲者のメール読みプログラムがこのようなリンクを参
照しようと試みるなら、攻撃者によって選択される名前のためのＤＮＳの問
合せを起こすでしょう。
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 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.
ＤＮＳＳＥＣ署名はグルーレコードを保護しません、それでグルーに関連す
る名前連鎖攻撃の可能性があります、しかしＤＮＳＳＥＣで、データの署名
された正式なレコードを得るために一時的にグルーを受け入れ、正式なレコー
ドで署名を検査することによって攻撃を検出することは可能です。
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.
もう１つのパケット妨害攻撃の方法は、偶然か意図的かにかかわらず、それ
ほど信できない信頼サーバです。多くのクライアントマシンがスタブリゾル
バ構成を設定するだけで、自己のＤＮＳ問合せの代理として信頼サーバを使
用します。多くの場合、信頼サーバはユーザのＩＳＰにあり、ＤＨＣＰやＰ
ＰＰオプションでクライアントに広告されます。偶発的な信頼関係の裏切り
（サーバのバグ、サーバ乗っ取りの成功）のほかに、ユーザを助けるための
正直な試みや、ＩＳＰと第三者の間にビジネス協力を進めるような目的で、
サーバ自身がユーザが予想しない返事を返す様に設定されるかもしれません。
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.
この問題は自分の装置を持ち運んで、行く先々で同じ方法で装置が働くこと
を期待する頻繁な旅行者で、特に問題です。このような旅行者は、現在装置
がつながっているネットワークを誰が運営するか、あるいはローカルインフ
ラでどの様なブランドの中間装置を使うかに関係なく、信頼可能なＤＮＳサー
ビスを必要とします。
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.
この問題に対する明白な解決策はクライアントがより信頼可能な信頼サーバ
を選択する事ですが、実際はクライアントが選択できないかもしれません。
多くのネットワーク環境でクライアントマシンが選択できる再帰ネームサー
バは限定的です、そしていずれも特に信頼可能ではないかもしれません。極
端な場合、たとえクライアント機械の所有者が望みクライアントホストが再
帰リゾルバを動作可能でも、ポートフィルタや他の形式のパケット妨害がそ
れを阻止するかもしれません。それでこの問題が元々本質的にＤＮＳプロト
コル攻撃ではないのが、この種類の裏切りはＤＮＳクライアントに対する脅
威で、ただ異なる再帰ネームサーバに切り替えることは適切な防衛策ではあ
りません。
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.
ＤＮＳプロトコル見地から厳密に見て、唯一のこの種類の裏切りとパケット
妨害攻撃の相違は、この場合クライアントが自発的に攻撃者にリクエストを
送ったということです。これに対しての防衛はパケット妨害攻撃と同じです：
リゾルバは選択したサーバが信頼できることを認証するために、自分自身で
ＤＮＳＳＥＣ署名を検査するか、あるいは処理署名（あるいは同等物）を使
わなくてはなりません。処理署名の使用だけでは名前サーバを信頼できませ
ん：処理署名がすることは、リゾルバが、他の理由で信頼すると決めた名前
サーバと、通信する事を守るのを手伝うだけであることに注意してください。
偽の答えを配るサーバと通信するリゾルバを守ることは特に有用ではありま
せん。
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.
同じくもしスタブリゾルバが、代理として仕事をしていてＤＮＳＳＥＣ署名
の検査もする名前サーバを信頼しないなら、リゾルバが実際に検査を実行す
るために必要なＤＮＳＳＥＣ公開鍵の独自の知識を持つ必要があることに注
意してください。通常ルートゾーンの公開鍵で十分です、しかしある場合に
は追加の鍵の知識が同じく適切であるかもしれません。
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 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.
ＤＮＳ応答パケットがＤＮＳ問合せパケットより長い傾向がある時から、Ｄ
ＮＳサーバがサービス妨害の増幅に用いられる危険があります。予想通りに、
ＤＮＳＳＥＣはここで助けになりません。
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.
たくさんの議論がドメイン名のない事の認証の問題で起きました。特定の質
問は、名前が実在しない事の認証の必要条件があるかどうかです。問題は、
いつ攻撃者が資源レコードを応答から取り除いた際に、リゾルバがいつ検出
が可能であるべきかです。
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.
疑い深く考えると、資源レコードの欠如が失敗以外の動作を生じるときに
（例えばＭＸとＳＲＶ資源レコードを失うとＡレコードが使われる）、これ
は脅威になります。多分、ある場合には、資源レコードの欠如自体が問題と
思われるかもしれません。残りの質問：この脅威はどれぐらい重大ですか？
明らかに脅威は存在します；疑い深い人は、たとえ我々が今日ありそうな攻
撃シナリオを考えられなくても、いつの日か主要な新聞の一面を飾るだろう
と言います。これはなんらかのこのリスクの緩和が必要とされることを意味
します。
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.
非存在の認証メカニズムの一部としてワイルドカード資源レコードの非実在
を証明することが必要で、そして、１以上のラベルの深さのゾーンで、この
ような証明が多数の別々のワイルドカード資源レコードの非実在を証明する
ことを必要とするかもしれないことに注意してください。
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.
ＤＮＳＳＥＣはゾーンにどの正式な名前が存在するか、そしてその正式な名
前にどの資源レコード種別が存在するか決定することを可能にするメカニズ
ムを含みます。ＤＮＳＳＥＣ保護はグルーレコードのような正式でないデー
タをカバーしません。
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.
「ワイルドカード」ＤＮＳ名にデータ完全性とデータ源認証を提供するべき
かどうかと、もしイエスならどのような方法でかについて、たくさんの議論
が起きました。概念的に、ワイルドカード名を持っている資源レコードは、
ＲＦＣ１０３４の４.３.２章で記述した一致規則に従って動的に統合生成す
る資源レコードです。ワイルドカード名の行動を制御する規則は不慣れなゾー
ン管理者が間違えやすいが、多くのサイトでワイルドカード資源レコード、
特にワイルドカードＭＸ資源レコードを激しく使用していることは明確です。
In order to provide the desired services for wildcard RRs, we need to
do two things:
ワイルドカード資源レコードに望ましいサービスを提供するために、我々は
２つのことをする必要があります：
- 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
- 我々はワイルドカード資源レコード自身の存在を証明する方法を必要とし
ます（すなわち、我々は統合規則が存在することを示す必要があります）、
そして
- 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).
- 我々は、どのワイルドカード資源レコードが使われるかを決める統合規則
に無関係なワイルドカード資源レコード、もしそれらが存在したなら、を
生成する資源レコードの非実在でも証明する方法を必要とします。
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.
ＤＮＳＳＥＣは上記のメカニズムを含み、そしてこれはネームサーバが答え
を生み出す際にワイルドカードを応用したことを、リゾルバが正確に確かめ
ることを可能にします。
3. Weaknesses of DNSSEC
3. ＤＮＳＳＥＣの欠点
DNSSEC has some problems of its own:
ＤＮＳＳＥＣはあるそれ自身の問題を持っています：
- 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 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 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.
- ＤＮＳＳＥＣ解答検証は、ＤＮＳＳＥＣ対応リゾルバが署名検証を行う必
要があり、ある場合にはさらに質問を発する必要があるので、リゾルバの
作業負荷を増やします。増加した作業負荷は応答を元のＤＮＳクライアン
トに渡すのに必要な時間を増やし、そしてある場合にはタイムアウトと再
問合せの両方を引き起こす可能性があります。多分、多くの現在のＤＮＳ
クライアントはＤＮＳＳＥＣが課す遅延を考慮に入れる前にでさえ、あま
りにも遅いです、しかしその話題はこの文書の範囲外です。
- 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.
- ＤＮＳ自身のように、ＤＮＳＳＥＣの信頼モデルはほとんど階層的です。
ＤＮＳＳＥＣがリゾルバにルート以外の公開鍵の特別な追加の知識を持つ
ことを許すが、一般的な場合に、ルート鍵は重要です。それでルートと特
定の目標名の間のゾーンのどこか暴露が起きると、その目標名の所有する
データの完全性を守るＤＮＳＳＥＣの能力に損害を与えます。これは、不
安定なＤＮＳが同じモデルを持っているので、変更ではありません。
- 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.
- ＤＮＳＳＥＣは検証を行うリゾルバとＤＮＳＳＥＣ署名を作るエンティティ
間に緩い同期が必要です。ＤＮＳＳＥＣ以前に、すべてのＤＮＳでの時間
に関連した行動は、機械は「経過」あるいは「相対」時間を知っていれば
動作できました。ＤＮＳＳＥＣ署名の有効期間は「絶対」時間に基づいて
いるので、検証リゾルバはが署名がその有効期間内にあるか、あるいは期
限切れかどうか決定するため、ゾーン署名者と同じ絶対時間の概念を持っ
ていなくてはなりません。リゾルバの現在の絶対の時刻を変える事ができ
る攻撃者が期限切れの署名でだます事ができます。ゾーン署名者の現在の
時刻を変えることができる攻撃者は、有効期間が署名者の意図と異なる署
名を生成するようにゾーン署名者をだますことができます。
- 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.
- ゾーンのワイルドカード資源レコードの存在はかなり非存在認証メカニズ
ムを複雑にします。ＤＮＳＳＥＣを開発した１０年の大部分でこれらの問
題は不完全に理解されました。非存在認証メカニズムが完全に完璧かどう
か、そしてワイルドカードがゾーンに存在していない普通の場合のために
非存在認証メカニズムを最適化することは価値があるであろうかどうかに
ついて、何度も質問がありました。しかしながら、主要な問題はワイルド
カードメカニズム自身に固有の複雑さです。この複雑さは恐らくもろい非
存在証明の検査と生成コードを作りますが、広範囲にわたる使用のため完
全にワイルドカードを断念する選択肢はに実用的ではないので、我々はワ
イルドカードを甘んじて受け入れなければならないつもりです。質問、提
案された最適化がＤＮＳＳＥＣのメカニズムを多かれ少なかれもろくする
かどうかです。
- 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.
- ＤＮＳＳＥＣがあっても、２.４章で論じられた種類の攻撃を破ることが
容易ではありません。ＤＮＳＳＥＣがこの場合効果的であるために、ＤＮ
Ｓレコードのある特定のカテゴリで署名されることを期待するようにリゾ
ルバを設定することは可能であるに違いありません。これは、リゾルバが
ルートとＴＬＤゾーンが署名されることを期待できない時、特に最初のＤ
ＮＳＳＥＣ交換期間に、リゾルバの手動設定を要求するかもしれません。
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.
ＤＮＳＳＥＣが守る事を意図する問題がＤＮＳプロトコル自身であるため、
上記の議論はＤＮＳプロトコルの範囲の攻撃に集中しています。ＤＮＳが他
のプロトコルと相互作用する境界に、他の問題の可能性があります。
4.2. Securing DNS Dynamic Update
4.2. ＤＮＳ動的更新の保証
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.
ＤＮＳ動的更新を、ＤＮＳＳＥＣと一緒にする時、多くの問題の可能性があ
ります。セキュアでないゾーンの動的更新は、クライアントからサーバへの
更新を認証するために処理署名を使うことができます。処理署名はスケーラ
ブルではないが（これはＤＮＳネームサーバとそれぞれの処理署名クライア
ント間で共有鍵の手動設定を必要とします）、ＤＨＣＰサーバがローカルな
ＤＮＳネームサーバを更新するような限定的あるいは閉鎖的環境でよく働き
ます。
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:
主な問題は、セキュアなゾーン上で動的更新を使おうとする時に起こります。
処理署名は同様にクライアントからサーバへを認証するための限定された形
式で使えますが、処理署名は実際のデータではなくＤＮＳ処理を守るだけで、
処理署名はＤＮＳゾーンに入れることは出来ず、それでリゾルバが処理署名
をゾーン変更の確認に用いることができません。これはいづれかを意味しま
す：
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) ＤＮＳネームサーバは更新に署名するため、オンラインのゾーン鍵にアク
セスを持たなくてはなりません。
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.
いずれかの場合でも、ゾーン鍵が最新されるゾーンに置くべき署名された資
源レコード集合を作るために、アクセス可能でなくてはなりません。この鍵
がオンラインである（あるいは少なくとも利用可能である）という事実は危
険の可能性があります。
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.
動的更新はゾーンのＳＯＡ資源レコードのシリアルフィールドの更新も必要
とします。理論上、これは上記の選択肢のいずれかによって処理できますが、
実際は(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.
ゾーンに誰が何の資源レコード集合にどんな変更が出来るかのポリシに関し
て他の脅威があります。安全な動的更新の現在のアクセス制御案はかなり限
定されています。それぞれが異なった種類のアクセスを必要とするかもしれ
ない、ＤＮＳゾーン情報を更新することに多数のエンティティーにきめが細
かいアクセスを与える方法はありません。例えば、アリスはゾーンに新しい
ノードを加えるか既存のノードを変えれるが削除できないかもしれません；
ボブはゾーンを削除できる必要があるがそれを追加できないかもしれません；
キャロルはノードの追加削除や修正が可能であるが、Ａレコードだけである
必要があるかもしれません。
Scaling properties of the key management problem here are a
particular concern that needs more study.
鍵管理問題のスケール特性は、より多くの調査を必要とする特別の懸念です。
4.3. Securing DNS Zone Replication
4.3. ＤＮＳゾーン複写の保証
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.
前章で論じられるように、ＤＮＳＳＥＣは本質的に標準的なＤＮＳ問合せプ
ロトコル上でデータ完全性とデータ源認証サービスを供給しようと試みます。
[RFC3552]で論じられた用語を使うと、ＤＮＳＳＥＣは標準的なＤＮＳ問合せ
プロトコルに「オブジェクトセキュリティ」を提供します。ゾーンは委任ポ
イントに署名なしのネームサーバ資源レコードとグルーを含むので、全部の
ＤＮＳゾーンを複写する目的で、しかしながら、ＤＮＳＳＥＣがオブジェク
トセキュリティを供給しません。ゾーン転送（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.
ゾーンオブジェクトセキュリティはＤＮＳＳＥＣの明示的な設計目標ではあ
りませんでした、それでこのサービスを供給することに関しての失敗は驚き
ではありません。にもかかわらず、非常に有用な追加のサービスかもしれな
いあるゾーン複製のシナリオがあります、これは将来の仕事の有用なエリア
に思われます。理論上、既存のＤＮＳＳＥＣモデルの後方互換拡張としてゾー
ンオブジェクトセキュリティを加える事は簡単であるべきですが、ＤＮＳＥ
ＸＴ作業班はまだこのような拡張の望ましさや要求条件を議論していません。
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.
上記の分析に基づいて、ＤＮＳＳＥＣ拡張は解決すべき問題を解決するため
に現われ、そして配置する価値があります。
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.
この文書全体がＤＮＳのセキュリティの考察です。著者はＤＮＳＳＥＣを配
置することは、既知のＤＮＳの脅威の全部ではないがいくらかを扱うのを手
伝うと信じます。
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.
そして著者がその名前と貢献を忘れたＤＮＳとＤＮＳＳＥＣとＤＮＳＩＮＤ
とＤＮＳＥＸＴ作業班のメンバーに感謝します、彼らは著者が彼らの考えに
関してしたことに関して責任がありません。
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.
[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.
[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.
[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.
[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.
[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.
[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.
[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.
Authors' Addresses
著者のアドレス
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
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.
著作権（Ｃ）インターネット学会（２００４）。この文書はＢＣＰ７８に含
まれる権利と許可と制限の適用を受け、そしてこの中に明らかにされる以外
は著者がすべての権利を維持します。
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.
この文書に記述された実装や技術に関して主張される知的財産権や他の権利の
正当性や範囲について、この様な権利の元でライセンスが利用可能か利用不
可能かの範囲について、ＩＥＴＦは何の立場もとりません；この様な権利を
認識する独立の調査をしたとは述べません。ＲＦＣ文書の権利に関する手続
きの情報はＢＣＰ７８とＢＣＰ７９を見てください。
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.
ＩＥＴＦ事務局に公開されたＩＰＲの写しと、利用可能な許可証と、仕様書
の実装者や利用者によってされた一般的な許可書や許可を得るためにされた
試みの結果は、http://www.ietf.org/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-ipr@ietf.orgのＩＥＴＦに情報を伝えてください。
Acknowledgement
謝辞
Funding for the RFC Editor function is currently provided by the
Internet Society.
ＲＦＣエディタ機能のための資金供給が現在インターネット学会によって
供給されます。