この文書はRFC3090の日本語訳（和訳）です。 この文書の翻訳内容の正確さは保障できないため、 正確な知識を求める方は原文を参照してください。 翻訳者はこの文書によって読者が被り得る如何なる損害の責任をも負いません。 この翻訳内容に誤りがある場合、訂正版の公開や、 誤りの指摘は適切です。 この文書の配布は元のＲＦＣ同様に無制限です。
Network Working Group E. Lewis
Request for Comments: 3090 NAI Labs
Category: Standards Track March 2001
DNS Security Extension Clarification on Zone Status
ゾーン状態に対するＤＮＳセキュリティ拡張の明確化
Status of this Memo
この文書の状態
This document specifies an Internet standards track protocol for the
Internet community, and requests discussion and suggestions for
improvements. Please refer to the current edition of the "Internet
Official Protocol Standards" (STD 1) for the standardization state
and status of this protocol. Distribution of this memo is unlimited.
この文書はインターネット共同体のためのインターネット標準化作業中のプ
ロトコルを指定して、そして改良のために議論と提案を求めます。標準化状
態とこのプロトコル状態は「インターネット公式プロトコル標準」（ＳＴＤ
１）の現在の版を参照してください。このメモの配布は無制限です。
Copyright Notice
著作権表示
Copyright (C) The Internet Society (2001). All Rights Reserved.
Abstract
概要
The definition of a secured zone is presented, clarifying and
updating sections of RFC 2535. RFC 2535 defines a zone to be secured
based on a per algorithm basis, e.g., a zone can be secured with RSA
keys, and not secured with DSA keys. This document changes this to
define a zone to be secured or not secured regardless of the key
algorithm used (or not used). To further simplify the determination
of a zone's status, "experimentally secure" status is deprecated.
安全ゾーンの定義は、ＲＦＣ２５３５の提示と明確化と更新の章にあります。
ＲＦＣ２５３５がアルゴリズムに基づいて安全ゾーンを定義します、例えば、
ゾーンがＲＳＡ鍵で安全に保たれて、ＤＳＡ鍵で安全に保たれないことがで
きます。この文書は、使われた（あるいは使われていない）鍵アルゴリズム
にかかわらず、ゾーンが安全か否かを定義するためにこれを変えます。さら
にゾーンの状態の確定を単純化するために、「実験安全」状態が廃止されま
す。
1 Introduction
1 はじめに
Whether a DNS zone is "secured" or not is a question asked in at
least four contexts. A zone administrator asks the question when
configuring a zone to use DNSSEC. A dynamic update server asks the
question when an update request arrives, which may require DNSSEC
processing. A delegating zone asks the question of a child zone when
the parent enters data indicating the status the child. A resolver
asks the question upon receipt of data belonging to the zone.
ＤＮＳゾーンが「安全」かどうかは少なくとも４つの文脈でされた質問です。
ゾーン管理者が、ＤＮＳＳＥＣを使うためにゾーンを設定する時、質問をし
ます。ダイナミック更新サーバが、更新要求が到着する時、質問をし、それ
はＤＮＳＳＥＣ処理を必要とするかもしれません。委任ゾーンで、親が子ゾー
ンの状態データを入力する際に、子に尋ねます。リゾルバがゾーンに属して
いるデータの受信の際に質問をします。
1.1 When a Zone's Status is Important
1.1 いつゾーン状態が重要か
A zone administrator needs to be able to determine what steps are
needed to make the zone as secure as it can be. Realizing that due
to the distributed nature of DNS and its administration, any single
zone is at the mercy of other zones when it comes to the appearance
of security. This document will define what makes a zone qualify as
secure.
ゾーン管理者が、どの手順でゾーンが安全であるか必要があるか、決定が可
能である必要があります。ＤＮＳとその管理の分散した性質のために、ひと
つのゾーンのセキュリティの話は他のゾーンの恵みが必要です。この文書は
何がゾーンを安全と見なさせるか定義します。
A name server performing dynamic updates needs to know whether a zone
being updated is to have signatures added to the updated data, NXT
records applied, and other required processing. In this case, it is
conceivable that the name server is configured with the knowledge,
but being able to determine the status of a zone by examining the
data is a desirable alternative to configuration parameters.
ダイナミック更新を行っているネームサーバが更新されているゾーンで、更
新されたデータに署名の追加が必要かどうか、ＮＸＴレコードを適用するか
どうか、そして他の必要とされる処理をするかどうか知る必要があります。
この場合、ネームサーバに知識を設定することは想像可能ですが、データを
調べることでゾーン状態を決定可能であることは設定パラメータの望ましい
選択肢です。
A delegating zone is required to indicate whether a child zone is
secured. The reason for this requirement lies in the way in which a
resolver makes its own determination about a zone (next paragraph).
To shorten a long story, a parent needs to know whether a child
should be considered secured. This is a two part question. Under
what circumstances does a parent consider a child zone to be secure,
and how does a parent know if the child conforms?
委任ゾーンは子ゾーンが安全に保たれるかどうか示すように要求されます。
この必要条件の理由はリゾルバがゾーンについての決定をする方法によりま
す（次の段落）。短く言うと、親は子が安全と考えられるべきかどうか知る
必要があります。これは２つの質問に分かれます。どの状況下で親が子ゾー
ンが安全であると考えるか、そしてどのように親が子が規則に従うか知るの
か？
A resolver needs to know if a zone is secured when the resolver is
processing data from the zone. Ultimately, a resolver needs to know
whether or not to expect a usable signature covering the data. How
this determination is done is out of the scope of this document,
except that, in some cases, the resolver will need to contact the
parent of the zone to see if the parent states that the child is
secured.
リゾルバがゾーンのデータを処理している時、ゾーンが安全かどうか知る必
要があります。究極的には、リゾルバがデータをカバーしている有効な署名
を期待するべきかどうか知る必要があります。ある場合にリゾルバは、親が
子を安全状態と述べるかどうか見るため、ゾーンの親と連絡を取る必要があ
る以外、この決定をする方法はこの文書の範囲から出ています。
1.2 Islands of Security
1.2 セキュリティの島
The goal of DNSSEC is to have each zone secured, from the root zone
and the top-level domains down the hierarchy to the leaf zones.
Transitioning from an unsecured DNS, as we have now, to a fully
secured - or "as much as will be secured" - tree will take some time.
During this time, DNSSEC will be applied in various locations in the
tree, not necessarily "top down."
ＤＮＳＳＥＣのゴールは、ルートゾーンから最上位ドメインを通って、末端
まで、それぞれのゾーンを安全に保つ事です。無担保のＤＮＳからの移行で、
今そうであるように、完全に安全に保たれた−あるいは「安全に保たれるで
あろう」−木までいくらか時間を要するでしょう。この間に、ＤＮＳＳＥＣ
は、必ずしも「トップダウン」ではなく、木の様々な場所で適用されるでしょ
う。
For example, at a particular instant, the root zone and the "test."
TLD might be secured, but region1.test. might not be. (For
reference, let's assume that region2.test. is secured.) However,
subarea1.region1.test. may have gone through the process of becoming
secured, along with its delegations. The dilemma here is that
subarea1 cannot get its zone keys properly signed as its parent zone,
region1, is not secured.
例えば、特定の瞬間、ルートゾーンと"test."TLDは安全に保たれるかもしれ
ませんが、region１.test.がそうではないかもしれません。（参照のために、
region2.test. 安全と想定します）。しかしながら、 subarea1.region1.test.
がその委任とともに安全になる処理を体験したかもしれません。ジレンマはこ
こでsubarea1の親ゾーンregion1が安全でないから、正確に署名されたゾーン
鍵を得ることができないということです。
The colloquial phrase describing the collection of contiguous secured
zones at or below subarea1.region1.test. is an "island of security."
The only way in which a DNSSEC resolver will come to trust any data
from this island is if the resolver is pre-configured with the zone
key(s) for subarea1.region1.test., i.e., the root of the island of
security. Other resolvers (not so configured) will recognize this
island as unsecured.
subarea1.region1.test.で、あるいはその下の、隣接した安全なゾーンの集
合は口語的に言うと「セキュリティの島」です。ＤＮＳＳＥＣリゾルバがこ
の島からデータを信頼するためにできる唯一の方法はリゾルバが
subarea1.region1.test. 、すなわち、セキュリティの島のルートのゾーン
鍵を事前設定されるかどうかです。（それで設定されていない）他のリゾル
バがこの島を安全でないと認知するでしょう。
An island of security begins with one zone whose public key is pre-
configured in resolvers. Within this island are subzones which are
also secured. The "bottom" of the island is defined by delegations
to unsecured zones. One island may also be on top of another -
meaning that there is at least one unsecured zone between the bottom
of the upper island and the root of the lower secured island.
セキュリティの島はその公開鍵がリゾルバで前もって設定されている１つの
ゾーンから始まります。この島の中に同じく安全に保たれるサブゾーンがあ
ります。島の「底」は安全でないゾーンの委任によって定義されます。１つ
の島が他の島の上にあるかもしれません−上の島の底と、下の安全な島の頂
上の間に少なくとも１つの安全でないゾーンがあることを意味ます。
Although both subarea1.region1.test. and region2.test. have both been
properly brought to a secured state by the administering staff, only
the latter of the two is actually "globally" secured - in the sense
that all DNSSEC resolvers can and will verify its data. The former,
subarea1, will be seen as secured by a subset of those resolvers,
just those appropriately configured. This document refers to such
zones as being "locally" secured.
subarea1.region1.test.とregion2.test.の両方が共に正確に管理しているス
タッフによって安全状態に持って来られたけれども、後者２つは実際に「グ
ローバル」に安全です−すべてのＤＮＳＳＥＣリゾルバがそのデータを実証
できるという意味でです。前者、subarea1は、適切な設定がされた一部のリ
ゾルバにだけ安全に見えるでしょう。 この文書はこのようなゾーンを「ロー
カル」に安全と言います。
In RFC 2535, there is a provision for "certification authorities,"
entities that will sign public keys for zones such as subarea1.
There is another document, [RFC3008], that restricts this activity.
Regardless of the other document, resolvers would still need proper
configuration to be able to use the certification authority to verify
the data for the subarea1 island.
ＲＦＣ２５３５で、subarea1のようなゾーンに公開鍵署名をするであろうエ
ンティティー、「認可権威」、の準備があります。もう１つの文書[RFC3008]
でこの活動を限定します。他の文書にかかわらず、リゾルバがまだ適切な設
定がsubarea1島のデータを実証する認可権威を使うことが可能である必要が
あるでしょう。
1.2.1 Determining the closest security root
1.2.1 最も近いセキュリティルートを決定する
Given a domain, in order to determine whether it is secure or not,
the first step is to determine the closest security root. The
closest security root is the top of an island of security whose name
has the most matching (in order from the root) right-most labels to
the given domain.
与えられたドメインについて、それが安全かどうか決定するための第一歩は
最も近いセキュリティルートを決定する事です。最も近いセキュリティルー
トはセキュリティの島の頂上で、その名前は与えられたドメインと右側が
（ルートからの順で）最も一致します。
For example, given a name "sub.domain.testing.signed.exp.test.", and
given the secure roots "exp.test.", "testing.signed.exp.test." and
"not-the-same.xy.", the middle one is the closest. The first secure
root shares 2 labels, the middle 4, and the last 0.
例えば、与えられた名前「sub.domain.testing.signed.exp.test」と、そし
て与えられたセキュリティルート「exp.test」と「testing.signed.exp.test」
と「 not-the-same.xy」で、真中の最も近いです。 最初のセキュリティルー
トは２ラベル、真ん中は４ラベル、最後は０ラベルを共有します。
The reason why the closest is desired is to eliminate false senses of
insecurity because of a NULL key. Continuing with the example, the
reason both "testing..." and "exp.test." are listed as secure root is
presumably because "signed.exp.test." is unsecured (has a NULL key).
If we started to descend from "exp.test." to our given domain
(sub...), we would encounter a NULL key and conclude that sub... was
unsigned. However, if we descend from "testing..." and find keys
"domain...." then we can conclude that "sub..." is secured.
なぜ最も近いものが望まれるかの理由はヌル鍵のための不安定な間違った認
識を排除することです。例を続けると、"testing..."と"exp.test."の両方
がセキュリティルートとリストアップされる理由は、多分、"signed.exp.test."
が安全でないからです（ヌル鍵を持っています）。もし我々が"exp.test."
から下降し始めたなら、与えられたドメイン(sub...)で、ヌル鍵に遭遇し、
sub...は署名がないと結論づけるでしょう。しかしながら、もし我々が
"testing..."から下降すると、"domain...."鍵が見つかり、それから我々は
"sub..."が安全と結論できます。
Note that this example assumes one-label deep zones, and assumes that
we do not configure overlapping islands of security. To be clear,
the definition given should exclude "short.xy.test." from being a
closest security root for "short.xy." even though 2 labels match.
この例が１ラベル深いゾーンを想定し、我々がセキュリティが部分的に重な
り合っている島を設定しないと想定することに注意してください。明確にす
ると、与えられた定義は、２ラベルが一致しても、"short.xy.test."が
"short.xy."の最も近いセキュリティルートであることを禁じるべきです。
Overlapping islands of security introduce no conceptually interesting
ideas and do not impact the protocol in anyway. However, protocol
implementers are advised to make sure their code is not thrown for a
loop by overlaps. Overlaps are sure to be configuration problems as
islands of security grow to encompass larger regions of the name
space.
セキュリティが部分的に重なり合っている島が概念的に面白い考えを導入せ
ず、プロトコルに影響を与えません。しかしながら、プロトコル実装者は部
分的な一致のためコードがループに入らないことを確かにするように助言さ
れます。重複は、セキュリティ島が名前空間のより大きい地域をカバーする
ようになるにつれて、設定問題であることを確かにします。
1.3 Parent Statement of Child Security
1.3 子セキュリティの親の言明
In 1.1 of this document, there is the comment "the parent states that
the child is secured." This has caused quite a bit of confusion.
この文書の１.１で、コメント「親は子が安全に保たれると述べる」がありま
す。 これは相当の混乱を起こしました。
The need to have the parent "state" the status of a child is derived
from the following observation. If you are looking to see if an
answer is secured, that it comes from an "island of security" and is
properly signed, you must begin at the (appropriate) root of the
island of security.
親が子の状態を「述べる」必要は次の観察から得られます。もしあなたが
「セキュリティ島」から来た答えが安全で正確に署名されてる事をかどうか
見たいと思うなら、あなたがセキュリティ島の（適切な）ルートから始めて
なくてはなりません。
To find the answer you are inspecting, you may have to descend
through zones within the island of security. Beginning with the
trusted root of the island, you descend into the next zone down. As
you trust the upper zone, you need to get data from it about the next
zone down, otherwise there is a vulnerable point in which a zone can
be hijacked. When or if you reach a point of traversing from a
secured zone to an unsecured zone, you have left the island of
security and should conclude that the answer is unsecured.
あなたが調べている答えを見いだすために、あなたはセキュリティ島の中で
ゾーンを通って降りなければならないかもしれません。島の信頼されたルー
トから始まって、あなたは下の次のゾーンに降ります。あなたが上のゾーン
を信頼するので、あなたが次のゾーンについてそこからデータを得る必要が
あり、さもなければゾーンが乗っ取られることができる攻撃されやすいポイ
ントがあります。いつあるいはもしあなたが安全に保たれたゾーンから安全
でないゾーンへ移動する点に達するなら、あなたがセキュリティ島を去って、
そして返事が安全でないと結論するべきです。
However, in RFC 2535, section 2.3.4, these words seem to conflict
with the need to have the parent "state" something about a child:
しかしながら、ＲＦＣ２５３５の２.３.４章で、これらの言葉は親が子につ
いて何かを「述べる」ようにする必要と矛盾するように思われます：
There MUST be a zone KEY RR, signed by its superzone, for every
subzone if the superzone is secure. This will normally appear in
the subzone and may also be included in the superzone. But, in
the case of an unsecured subzone which can not or will not be
modified to add any security RRs, a KEY declaring the subzone to
be unsecured MUST appear with the superzone signature in the
superzone, if the superzone is secure.
もしサブゾーンがが安全なら、すべてのサブソーンのために、その上位ゾー
ンによって署名されたゾーン鍵資源レコードがあります(MUST)。これは通
常サブゾーンにに現われるでしょう、そして同じくスーパーゾーンに含め
られるかもしれません。しかし、セキュリティ資源レコードを追加できな
い安全でないサブゾーンの場合、もし上位ゾーンが安全なら、サブゾーン
が安全でないと宣言する鍵が上位ゾーンで上位ゾーンで署名されて現われ
なければなりません(MUST)。
The confusion here is that in RFC 2535, a secured parent states that
a child is secured by SAYING NOTHING ("may also be" as opposed to
"MUST also be"). This is counter intuitive, the fact that an absence
of data means something is "secured." This notion, while acceptable
in a theoretic setting has met with some discomfort in an operation
setting. However, the use of "silence" to state something does
indeed work in this case, so there hasn't been sufficient need
demonstrated to change the definition.
混乱はＲＦＣ２５３５で、安全に保たれた親が子について何も言わないこと
で安全に保たれると述べるということです（「そうかもしれない」は「そう
であるに違いない」の反対です）。データの欠如が「安全」を意味するとい
う事はは直観と逆です。この考えは理論的に許容できる設定ですが、運用設
定上の不安に遭遇しました。しかしながら、何かを述べるための「静寂」の
使用はこの場合本当にうまくいきます、それで定義を変えることを十分に明
らかな必要がありませんでした。
1.4 Impact on RFC 2535
1.4 ＲＦＣ２５３５への影響
This document updates sections of RFC 2535. The definition of a
secured zone is an update to section 3.4 of the RFC. Section 3.4 is
updated to eliminate the definition of experimental keys and
illustrate a way to still achieve the functionality they were
designed to provide. Section 3.1.3 is updated by the specifying the
value of the protocol octet in a zone key.
この文書はＲＦＣ２５３５の章を最新のものにします。安全に保たれた地域
の定義はＲＦＣの３.４章の更新です。３.４章が、供給を意図する機能性を
成し遂げるための、実験的な鍵の定義と方法の例示を排除し、更新されます。
セクション３.１.３がゾーン鍵のプロトコルオクテット値の指定によって更
新されます。
1.5 "MUST" and other key words
1.5 "MUST"と他のキーワード
The key words "MUST", "REQUIRED", "SHOULD", "RECOMMENDED", and "MAY"
in this document are to be interpreted as described in [RFC 2119].
Currently, only "MUST" is used in this document.
この文書のキーワード"MUST"と"REQUIRED"と"SHOULD"と"RECOMMENDED"と
"MAY"は[RFC 2119]で記述されるように、解釈されるはずです。現在、ただ
"MUST"だけがこの文書で使われます。
2 Status of a Zone
2 ゾーンの状態
In this section, rules governing a zone's DNSSEC status are
presented. There are three levels of security defined: global,
local, and unsecured. A zone is globally secure when it complies
with the strictest set of DNSSEC processing rules. A zone is locally
secured when it is configured in such a way that only resolvers that
are appropriately configured see the zone as secured. All other
zones are unsecured.
この章で、ゾーンのＤＮＳＳＥＣ状態を支配している規則を提示します。定
義された３つのレベルのセキュリティがあります：グローバルとローカルと
安全でないです。ゾーンがＤＮＳＳＥＣの最も厳しい処理規則に従う時、グ
ローバルに安全です。適切に設定されるリゾルバだけがゾーンの安全を見れ
るように設定される時、ゾーンはローカルに安全です。すべての他のゾーン
は安全でありません。
Note: there currently is no document completely defining DNSSEC
verification rules. For the purposes of this document, the strictest
rules are assumed to state that the verification chain of zone keys
parallels the delegation tree up to the root zone. (See 2.b below.)
This is not intended to disallow alternate verification paths, just
to establish a baseline definition.
ノート：完全にＤＮＳＳＥＣ認証規則を定義している文書が現在ありません。
この文書で、最も厳しい規則はゾーン鍵の証明チェーンがルートゾーンまで
の委任木と並行することと仮定します。（以下の２ｂを見てください）。こ
れは基本定義に一致する他の証明パスを拒絶することは意図しません。
To avoid repetition in the rules below, the following terms are
defined.
下に規則で繰り返しを避けるために、次の用語が定義されます。
2.a Zone signing KEY RR - A KEY RR whose flag field has the value 01
for name type (indicating a zone key) and either value 00 or value 01
for key type (indicating a key permitted to authenticate data). (See
RFC 2535, section 3.1.2). The KEY RR also has a protocol octet value
of DNSSEC (3) or ALL (255).
２．ａ ゾーン署名鍵資源レコード−鍵資源レコードで、名前タイプのフラグ
フィールド値が０１（ゾーンの鍵を示している）で、鍵タイプ値が００か０１
（鍵はデータを認証に許される）です。（ＲＦＣ２５３５、３.１.２章参照）。
鍵資源レコードは同じくプロトコルオクテット値がＤＮＳＳＥＣ（３）かＡＬ
Ｌ（２５５）を持ちます。
The definition updates RFC 2535's definition of a zone key. The
requirement that the protocol field be either DNSSEC or ALL is a new
requirement (a change to section 3.1.3.)
定義はＲＦＣ２５３５の、ゾーン鍵の定義を更新します。プロトコルフィー
ルドがＤＮＳＳＥＣかＡＬＬであるという条件は新しい必要条件である
（３.１.３章に対する変更）。
2.b On-tree Validation - The authorization model in which only the
parent zone is recognized to supply a DNSSEC-meaningful signature
that is used by a resolver to build a chain of trust from the child's
keys to a recognized root of security. The term "on-tree" refers to
following the DNS domain hierarchy (upwards) to reach a trusted key,
presumably the root key if no other key is available. The term
"validation" refers to the digital signature by the parent to prove
the integrity, authentication and authorization of the child's key to
sign the child's zone data.
２.b 委任木認証−子ゾーンの鍵から認識しているセキュリティルートまで信
頼の鎖を作るためにリゾルバによって使われるＤＮＳＳＥＣの有効な署名の
供給が、親ゾーンだけに認められている認証モデル。用語「委任木上の」は、
もし他の鍵が利用可能ではないなら、信頼された鍵、多分ルート鍵に届くた
めにＤＮＳドメイン階層に（上に向かって）従うことを示します。用語「認
証」は、子のゾーンデータに署名する子鍵の完全性と認証と認可を証明する
ための、親によるディジタル署名を示します。
2.c Off-tree Validation - Any authorization model that permits domain
names other than the parent's to provide a signature over a child's
zone keys that will enable a resolver to trust the keys.
２.c 委任木外の認証−リゾルバが鍵を信頼することができるようにするため
の子ゾーンの鍵の署名の供給を、親以外のドメイン名に認める認可モデル。
2.1 Globally Secured
2.1 グローバルに安全
A globally secured zone, in a nutshell, is a zone that uses only
mandatory to implement algorithms (RFC 2535, section 3.2) and relies
on a key certification chain that parallels the delegation tree (on-
tree validation). Globally secured zones are defined by the
following rules.
グローバルに安全なゾーンが、簡単に言えば、実装が必須のアルゴリズム
（ＲＦＣ２５３５、２章）だけを使い、委任木に平行な認証鎖（ 委任木上の
認証）に頼るゾーンです。グローバルに安全なゾーンが次の規則によって定義
されます。
2.1.a. The zone's apex MUST have a KEY RR set. There MUST be at
least one zone signing KEY RR (2.a) of a mandatory to implement
algorithm in the set.
2.1.a. ゾーンの頂上には鍵資源レコード集合があります(MUST)。少なくとも
１つの必須実装アルゴリズムのゾーン署名鍵資源レコード(2.a)があります
(MUST)。
2.1.b. The zone's apex KEY RR set MUST be signed by a private key
belonging to the parent zone. The private key's public companion
MUST be a zone signing KEY RR (2.a) of a mandatory to implement
algorithm and owned by the parent's apex.
2.1.b. ゾーンの頂上の鍵資源レコード集合は親ゾーンに属しているプライベー
ト鍵によって署名されます(MUST)。秘密鍵に対応する公開鍵は必須実装アル
ゴリズムのゾーン署名鍵資源レコードで、親の頂上に属します(MUST)。
If a zone cannot get a conforming signature from the parent zone, the
child zone cannot be considered globally secured. The only exception
to this is the root zone, for which there is no parent zone.
もしゾーンが親ゾーンから署名を得ることができないなら、子ゾーンはグロー
バルに安全と考ることができません。唯一の例外は親ゾーンがないルートゾー
ンです。
2.1.c. NXT records MUST be deployed throughout the zone. (Clarifies
RFC 2535, section 2.3.2.) Note: there is some operational discomfort
with the current NXT record. This requirement is open to
modification when two things happen. First, an alternate mechanism
to the NXT is defined and second, a means by which a zone can
indicate that it is using an alternate method.
2.1.c. ＮＸＴレコードがゾーン全体に設定されなくてはなりません。（ＲＦ
Ｃ２５３５の２.３.２章を明確にします）ノート：現在ＮＸＴレコードにあ
る運用上の問題があります。この条件は、２つのことが起きる時、修正され
るかもしれません。最初に、ＮＸＴの代わりのメカニズムが定義されます、
そして第二にゾーンが変わりの手段を使っていることを示します。
2.1.d. Each RR set that qualifies for zone membership MUST be signed
by a key that is in the apex's KEY RR set and is a zone signing KEY
RR (2.a) of a mandatory to implement algorithm. (Updates 2535,
section 2.3.1.)
2.1.d. ゾーンメンバーの各鍵資源レコード(2.a)は、ゾーンの頂上の、必須
実装アルゴリズムの、鍵資源レコードの鍵で署名されます(MUST)。（２５３５
の２.３.１章を更新）。
Mentioned earlier, the root zone is a special case. The root zone
will be considered to be globally secured provided that if conforms
to the rules for locally secured, with the exception that rule 2.1.a.
be also met (mandatory to implement requirement).
前に言ったとおり、ルートゾーンは特別です。ルートゾーンは、ルール2.1.a
が要求される（必須実装条件）を除き、ローカル安全の規則に従うときに、
グローバルに安全です。
2.2 Locally Secured
2.2 ローカルな安全
The term "locally" stems from the likely hood that the only resolvers
to be configured for a particular zone will be resolvers "local" to
an organization.
用語「ローカル」は、特定のゾーンに対する設定をされるリゾルバが、組織
の「ローカル」リゾルバであるだろうということによります。
A locally secured zone is a zone that complies with rules like those
for a globally secured zone with the following exceptions. The
signing keys may be of an algorithm that is not mandatory to
implement and/or the verification of the zone keys in use may rely on
a verification chain that is not parallel to the delegation tree
(off-tree validation).
ローカルに安全なゾーンは、次の例外を除き、グローバルに安全なゾーンの
規則に従う地域です。署名鍵のアルゴリズムは必須実装のではないかもしれ
ません、ゾーン鍵の認証は委任木に平行していない認証鎖によるかもしれま
せん（委任木外の認証）。
2.2.a. The zone's apex MUST have a KEY RR set. There MUST be at
least one zone signing KEY RR (2.a) in the set.
2.2.a. ゾーンの頂上は鍵資源レコード集合をを持っていなくてはなりません
(MUST)。少なくとも１つのゾーン署名鍵資源レコード（2.a)があるに違いあ
りません(MUST)。
2.2.b. The zone's apex KEY RR set MUST be signed by a private key and
one of the following two subclauses MUST hold true.
2.2.b. ゾーンの頂上の鍵資源レコード集合は、秘密鍵で署名され、以下の２
つのどちらかが真でなくてはなりません(MUST)。
2.2.b.1 The private key's public companion MUST be pre-configured in
all the resolvers of interest.
2.2.b.1 秘密鍵に対応する公開鍵はすべてのリゾルバで前もって設定されな
くてはなりません(MUST)。
2.2.b.2 The private key's public companion MUST be a zone signing KEY
RR (2.a) authorized to provide validation of the zone's apex KEY RR
set, as recognized by resolvers of interest.
2.2.b.1 秘密鍵に対応する公開鍵は、関係するリゾルバに認識される、ゾー
ンの頂上の鍵資源レコードを認証するために供給された、ゾーン署名鍵資源
レコード(2.a)です(MUST)。
The previous sentence is trying to convey the notion of using a
trusted third party to provide validation of keys. If the domain
name owning the validating key is not the parent zone, the domain
name must represent someone the resolver trusts to provide
validation.
前の文は鍵の認証を供給するために信頼できる第三者を使う考えを伝えよう
としています。もし有効な鍵を所有しているドメイン名が親ゾーンではない
なら、ドメイン名はリゾルバが認証を供給するために信頼する誰かを表さな
くてはなりません。
2.2.c. NXT records MUST be deployed throughout the zone. Note: see
the discussion following 2.1.c.
2.2.c. ＮＸＴレコードがゾーン全体に設定されなくてはなりません(MUST)。
ノート：2.1.cの後の論議を見てください。
2.2.d. Each RR set that qualifies for zone membership MUST be signed
by a key that is in the apex's KEY RR set and is a zone signing KEY
RR (2.a). (Updates 2535, section 2.3.1.)
2.2.d. ゾーンメンバの各資源レコード集合が頂上の鍵資源レコード集合にあ
る、ゾーン署名鍵資源レコードの、鍵で署名されなくてはなりません(MUST)。
（２５３５の２.３.１章を更新します）。
2.3 Unsecured
2.3 安全でない
All other zones qualify as unsecured. This includes zones that are
designed to be experimentally secure, as defined in a later section
on that topic.
すべての他のゾーンは安全でないと見なされます。これはあのトピックの後
の章に定義される、実験的に安全であるよう意図されるゾーンを含めます。
2.4 Wrap up
2.4 終わり
The designation of globally secured, locally secured, and unsecured
are merely labels to apply to zones, based on their contents.
Resolvers, when determining whether a signature is expected or not,
will only see a zone as secured or unsecured.
グローバルに安全と、ローカルに安全と、安全でないの指定は単にゾーンの
中身に基づいて適用するラベルです。リゾルバが署名が期待されるかどうか
決定する時、ただ安全なゾーンか安全でないゾーンかだけを見るでしょう。
Resolvers that follow the most restrictive DNSSEC verification rules
will only see globally secured zones as secured, and all others as
unsecured, including zones which are locally secured. Resolvers that
are not as restrictive, such as those that implement algorithms in
addition to the mandatory to implement algorithms, will see some
locally secured zones as secured.
最も限定的にＤＮＳＳＥＣ認証規則に従うリゾルバは、グローバルに安全な
ゾーンだけを安全と考え、ローカルに安全なゾーンも含めて他の全てのゾー
ンをを安全でないと考えるでしょう。義務的でないアルゴリズムを実行する
ような、限定的でないリゾルバが、ローカルに安全なゾーンを安全と見るで
しょう。
The intent of the labels "global" and "local" is to identify the
specific attributes of a zone. The words are chosen to assist in the
writing of a document recommending the actions a zone administrator
take in making use of the DNS security extensions. The words are
explicitly not intended to convey a state of compliance with DNS
security standards.
「グローバル」と「ローカル」のラベルの意図はゾーンの特定の特質を識別
するためです。用語は、ＤＮＳセキュリティ拡張を利用するゾーン管理者に、
行動を勧める文書の記述を支援するように選ばれます。用語は明示的にＤＮ
Ｓセキュリティ標準の遵守状態を伝達するように意図されません。
3 Experimental Status
3 実験的状態
The purpose of an experimentally secured zone is to facilitate the
migration from an unsecured zone to a secured zone. This distinction
is dropped.
実験的に安全なゾーンの目的は安全でないゾーンから安全なゾーンへの以降
を容易にすることです。この区別はやめます。
The objective of facilitating the migration can be achieved without a
special designation of an experimentally secure status.
Experimentally secured is a special case of locally secured. A zone
administrator can achieve this by publishing a zone with signatures
and configuring a set of test resolvers with the corresponding public
keys. Even if the public key is published in a KEY RR, as long as
there is no parent signature, the resolvers will need some pre-
configuration to know to process the signatures. This allows a zone
to be secured with in the sphere of the experiment, yet still be
registered as unsecured in the general Internet.
移行を容易にすることは実験的に確かな状態の特別な肩書き無しで成し遂げ
られることができます。実験的に安全はローカルに安全の特別な場合です。
ゾーン管理者が署名付きでゾーンを公開し、対応する公開鍵をテストリゾル
バに設定するでこれを成し遂げることができます。たとえ公開鍵が鍵資源レ
コードで公開されたとしても、親の署名がない限り、リゾルバは事前設定の
署名を処理することを必要とするでしょう。これは、一般的なインターネッ
トで保証がなくて登録されたまま、実験の範囲で安全なゾーンを許します。
4 IANA Considerations
4 ＩＡＮＡの考慮
This document does not request any action from an assigned number
authority nor recommends any actions.
この文書は番号割当て当局に行動を求めないし、行動を勧めません。
5 Security Considerations
5 セキュリティの考察
Without a means to enforce compliance with specified protocols or
recommended actions, declaring a DNS zone to be "completely" secured
is impossible. Even if, assuming an omnipotent view of DNS, one can
declare a zone to be properly configured for security, and all of the
zones up to the root too, a misbehaving resolver could be duped into
believing bad data. If a zone and resolver comply, a non-compliant
or subverted parent could interrupt operations. The best that can be
hoped for is that all parties are prepared to be judged secure and
that security incidents can be traced to the cause in short order.
指定されたプロトコルの遵守あるいは推薦された行動を実施する手段無しで、
ＤＮＳゾーンが「完全」安全と宣言することは不可能です。たとえ誰かが、
ＤＮＳの観点で、ゾーンがセキュリティのために適切に設定していると宣言
し、ルートまでも同様と想定しても、行儀悪いリゾルバが良くないデータを
信じてだまされます。もしゾーンとリゾルバが規則に従っていても、従って
いないか、腐敗した親がオペレーションを中断できます。望まれる最良の事
は、すべての関係者が安全を判断する用意ができ、セキュリティの事件がす
ぐに原因を追跡できることです。
6 Acknowledgements
6 謝辞
The need to refine the definition of a secured zone has become
apparent through the efforts of the participants at two DNSSEC
workshops, sponsored by the NIC-SE (.se registrar), CAIRN (a DARPA-
funded research network), and other workshops. Further discussions
leading to the document include Olafur Gudmundsson, Russ Mundy,
Robert Watson, and Brian Wellington. Roy Arends, Ted Lindgreen and
others have contributed significant input via the namedroppers
mailing list.
安全なゾーンの定義を洗練する必要性は、ＮＩＣ ＳＥと（レジスター）と
ＣＡＩＲＮ（ＤＡＲＰＡによって資金を供給された研究ネットワーク）と他
のワークショップによって後援された２つのＤＮＳＳＥＣワークショップの
関係者の努力を通して明白になりました。文書を導いた論議がOlafur
GudmundssonとRuss MundyとRobert WatsonとBrian Wellingtonを含みます。
Roy ArendsとTed Lindgreenと他の人たちはnamedroppersメーリングリスト
に重要な入力を提供しました。
7 References
7 参考文献
[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.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2136] Vixie, P., (Ed.), Thomson, S., Rekhter, Y. and J. Bound,
"Dynamic Updates in the Domain Name System", RFC 2136,
April 1997.
[RFC2535] Eastlake, D., "Domain Name System Security Extensions", RFC
2535, March 1999.
[RFC3007] Wellington, B., "Simple Secure Domain Name System (DNS)
Dynamic Update", RFC 3007, November 2000.
[RFC3008] Wellington, B., "Domain Name System Security (DNSSEC)
Signing Authority", RFC 3008, November 2000.
10 Author's Address
10 著者のアドレス
Edward Lewis
NAI Labs
3060 Washington Road Glenwood
MD 21738
Phone: +1 443 259 2352
EMail: lewis@tislabs.com
11 Full Copyright Statement
11 著作権表示全文
Copyright (C) The Internet Society (2001). All Rights Reserved.
著作権（Ｃ）インターネット学会（２００１）。すべての権利は保留される。
This document and translations of it may be copied and furnished to
others, and derivative works that comment on or otherwise explain it
or assist in its implementation may be prepared, copied, published
and distributed, in whole or in part, without restriction of any
kind, provided that the above copyright notice and this paragraph are
included on all such copies and derivative works. However, this
document itself may not be modified in any way, such as by removing
the copyright notice or references to the Internet Society or other
Internet organizations, except as needed for the purpose of
developing Internet standards in which case the procedures for
copyrights defined in the Internet Standards process must be
followed, or as required to translate it into languages other than
English.
上記著作権表示とこの段落が全ての複写や派生的な仕事につけられていれば、
この文書と翻訳は複写や他者への提供ができ、そしてコメントや説明や実装
を支援する派生的な仕事のためにこの文書の全部か一部を制約なく複写や出
版や配布できます。しかし、この文書自身は、英語以外の言葉への翻訳やイ
ンターネット標準を開発する目的で必要な場合以外は、インターネット学会
や他のインターネット組織は著作権表示や参照を削除されるような変更がで
きません、インターネット標準を開発する場合はインターネット標準化プロ
セスで定義された著作権の手順に従われます。
The limited permissions granted above are perpetual and will not be
revoked by the Internet Society or its successors or assigns.
上に与えられた限定された許可は永久で、インターネット学会やその後継者
や譲渡者によって無効にされません。
This document and the information contained herein is provided on an
"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
TASK FORCE DISCLAIMS 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.
この文書とここに含む情報は無保証で供給され、そしてインターネット学会
とインターネット技術標準化タスクフォースは、特別にも暗黙にも、この情
報の利用が権利を侵害しないことや商業利用や特別の目的への利用に適当で
ある事の保障を含め、すべての保証を拒否します。
Acknowledgement
謝辞
Funding for the RFC Editor function is currently provided by the
Internet Society.
ＲＦＣエディタ機能のための資金供給が現在インターネット学会によって
供給されます。