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.
この文書は、インターネットコミュニティのためのインターネット標準トラックプロトコルを指定し、改善のための議論と提案を要求します。このプロトコルの標準化状態と状態への「インターネット公式プロトコル標準」（STD 1）の最新版を参照してください。このメモの配布は無制限です。
Copyright Notice
著作権表示
Copyright (C) The Internet Society (2001). All Rights Reserved.
著作権（C）インターネット協会（2001）。全著作権所有。
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.
セキュアゾーンの定義は、RFC 2535は、例えば、ゾーンはRSAキーで固定され、DSAキーで固定されていないことができ、アルゴリズムごとに基づいて固定されるようにゾーンを定義明確化及びRFC 2535のセクションを更新し、提示されています。この文書では、固定またはかかわらず、キー使用されるアルゴリズム（または使用されていない）の固定されないようにゾーンを定義するために、これを変更します。さらに、ゾーンのステータスの決意を簡素化するために、「実験的に安全な」ステータスが廃止されました。
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.
DNSゾーンが「確保」されるかどうかは、少なくとも4つの文脈で尋ねた質問です。 DNSSECを使用するようにゾーンを構成するときに、ゾーン管理者が質問をします。更新要求が到着したときに動的更新サーバーは、DNSSEC処理を必要とする可能性がある、質問を尋ねます。親が状況に子を示すデータを入力したときに委譲ゾーンは、子ゾーンの質問をします。リゾルバは、ゾーンに属するデータの受信時に質問をします。
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.
ゾーン管理者は、それができるよう、ゾーンが安全なようにするために必要な手順を決定できるようにする必要があります。それはセキュリティの出現に来るときによるDNSおよびその投与の分散性に、任意の単一のゾーンが他のゾーンに翻弄さであることを認識。この文書では、ゾーンが安全なように修飾するものを定義します。
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.
動的更新を実行するネームサーバは、更新されたゾーンが更新されたデータ、NXTレコード適用、および他の必要な処理に加え署名を持つことであるかどうかを知る必要があります。この場合には、ネームサーバが知識を構成することが考えられるが、データを調べることによって、ゾーンのステータスを決定することができることは、構成パラメータの望ましい代替です。
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.
レゾルバは、レゾルバがゾーンからのデータを処理しているときにゾーンが確保されているかどうかを知る必要があります。最終的に、レゾルバは、データをカバーする使用可能な署名を期待するかどうかを知る必要があります。この決意はどのように行われ、この文書の範囲外である、ことを除いて、いくつかのケースでは、リゾルバは親が子供が確保されていると述べているかどうかを確認するために、ゾーンの親に連絡する必要があります。
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."
DNSSECの目標は、各ゾーンは、ルートゾーンとトップレベルドメイン下葉のゾーンへの階層から、確保していることです。我々が今持っているように完全に確保し、無担保DNSからの移行 - かは、「できるだけ多く確保されるように、」 - 木はしばらく時間がかかります。この間、DNSSECは必ずしも「トップダウン」、ツリーのさまざまな場所に適用されます。
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.
例えば、特定の瞬間、ルートゾーンとの「試験」。 TLDを確保、しかしregion1.testされる可能性があります。ではないかもしれません。 （参考までに、さんはそのregion2.testを想定してみましょう。固定されている。）しかし、subarea1.region1.test。その代表団とともに、担保なる過程を経ている可能性があります。ここにジレンマが地域1、subarea1はそのゾーンキーが適切にその親ゾーンとして署名を受けることができないということです、確保されていません。
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のゾーンキー（S）を用いて事前に設定されている場合DNSSECリゾルバが、この島からの任意のデータを信頼するように来るする唯一の方法である。すなわち、セキュリティの島のルート。他のリゾルバは、（そのように構成されていない）無担保としてこの島を認識します。
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.
セキュリティの島は、その公開鍵リゾルバにあらかじめ構成されている1つのゾーンで始まります。この島の中でも確保されているサブゾーンがあります。島の「底部は」無担保ゾーンへの代表団によって定義されます。一つの島はまた、互いの上にあってもよい - 上部島の底部と下部保護された島の付け根の間に少なくとも1つの保護されていないゾーンがあることを意味します。
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。すべてのDNSSECリゾルバは、そのデータを検証しますことができるという意味で - きちんと2の後者のみが実際に「グローバル」確保され、投与スタッフによって保護された状態にされている両方。これらのレゾルバのサブセットによって固定されるよう前者、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.
RFC 2535では、「証明機関」などsubarea1などのゾーンの公開鍵に署名するエンティティのための規定があります。この活動を制限し、別の文書、[RFC3008]は、あります。かかわらず、他の文書の、リゾルバはまだsubarea1島のためのデータを検証するために証明機関を使用できるように適切な設定が必要になります。
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。」そして「ない-same.xy。」、真ん中の1が最も近いです。第一のセキュアルート株式2つのラベル、中間4、および最後0。
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.
最も近いが要求される理由は、理由はNULLキーの不安の偽の感覚を排除することです。例を続けると、理由の両方の「テスト...」と「exp.test。」安全なルートとしてリストされているが、おそらく「signed.exp.test」です。 （NULLキーを持っている）無担保です。私たちは、から下降し始めた場合は、「exp.test。」私たちの与えられたドメイン（サブ...）に、我々は、符号なしだった... NULLキーに遭遇し、そのサブを締結します。しかし、私たちは「...テスト」から派生し、キー見つけた場合、「ドメインを....」我々は「サブが...」確保されていると結論付けることができます。
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.
この例では、1-ラベルの深いゾーンを想定している、と我々はセキュリティの島の重複設定しないことを前提としています。明確にするために、与えられた定義は「short.xy.test」を除外する必要があります最も近いセキュリティルートであることから「short.xy。」にもかかわらず、2つのラベルが一致します。
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.
セキュリティのオーバーラップの島々には、概念的に面白いアイデアを導入しないでとにかくプロトコルに影響を与えません。しかし、プロトコルの実装は、そのコードが重複することによりループのためにスローされていないことを確認することをお勧めします。オーバーラップは、セキュリティの島々は、名前空間のより大きな領域を包含するように成長するにつれて、構成上の問題になるはずです。
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.
この文書の1.1で、コメントは「親は子供が確保されていると述べている。」がありますこれは混乱のかなりの原因となっています。
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:
しかし、RFC 2535、セクション2.3.4で、これらの言葉は、子供についての何かを親「状態」を持つ必要性と矛盾するように見えます。
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.
上位ゾーンが安全である場合は、すべてのサブゾーンのために、その上位ゾーンによって署名されたゾーンKEYのRR、があるに違いありません。これは通常、サブゾーンに表示され、また、上位ゾーンに含まれていてもよいです。上位ゾーンが安全である場合でも、または任意のセキュリティRRを追加するように変更されることはありませんができない無担保サブゾーンの場合には、サブゾーンを宣言するKEYは、上位ゾーンにおける上位ゾーンの署名が現れなければならない無担保されるように。
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.
ここでの混乱は、RFC 2535で、セキュリティで保護された親が子供が（「もでなければならない」とは対照的に、「あってもよい」）は何も言ってないで固定されていることを述べていることです。これは、データの欠如がされるものを意味しているという事実、カウンター直感的である「確保します」。この概念は、許容しながら、理論的な設定で動作設定でいくつかの不快感と会談しました。しかし、何かを述べる「沈黙」の使用は、実際にこのケースでは動作しないので、定義を変更することが明らかに十分な必要はありませんでした。
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.
この文書では、セキュリティで保護されたゾーンの定義はRFCのセクション3.4にアップデートされ、RFC 2535のセクションを更新します。 3.4節は、実験的なキーの定義を排除し、まだ彼らが提供するように設計された機能を実現するための方法を説明するために更新されます。 3.1.3項では、ゾーンキー内のプロトコルオクテットの値を指定することによって更新されます。
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」、および本書では[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.
このセクションでは、ゾーンのDNSSECのステータスを管理する規則が提示されています。 、グローバルローカル、および無担保：定義されたセキュリティの3つのレベルがあります。それはDNSSEC処理ルールの厳しいセットに準拠する場合、ゾーンは、グローバルに安全です。それが固定されるよう適切に構成されているだけリゾルバがゾーンを参照して、このような方法で構成されている場合、ゾーンは、局所的に固定されています。他のすべてのゾーンは無担保で。
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.
注意：現在、完全にDNSSEC検証ルールを定義する一切の文書がありません。このドキュメントの目的のために、厳しい規則は、ゾーン鍵の検証チェーンがルートゾーンへの委任ツリーのアップに匹敵すると述べていると想定されています。 （以下2.Bを参照。）これは、代替検証パスを禁止するだけで、ベースラインの定義を確立することを意図していません。
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).
2.Aゾーン署名鍵RR - そのフラグフィールド（ゾーンキーを示す）名前タイプの値01を有しているKEYのRRとキータイプのいずれかの値が00または値01（キーを示すデータを認証することを許可しました）。 （RFC 2535、セクション3.1.2を参照してください）。 KEY RRはまた、DNSSEC（3）または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.)
定義は、ゾーン鍵のRFC 2535の定義を更新します。プロトコルフィールドはDNSSECまたはALLのいずれかであるという要件は、新たな要件である（セクション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.
2.Bオンツリーの検証 - 唯一の親ゾーンは、セキュリティの認識ルートに子供のキーからの信頼の連鎖を構築するために、リゾルバで使用されているDNSSEC-意味の署名を供給するために認識されている承認モデル。 「上の木」という用語は、他のキーが利用できない場合、信頼できるキー、おそらくルートキーに到達するために（上向き）DNSドメインの階層を以下を参照します。用語「検証は、」子供のゾーンデータに署名するために、子供のキーの整合性、認証および承認を証明するために親によってデジタル署名を指します。
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.
2.Cオフツリーの検証 - キーを信頼するようにリゾルバを可能にする子供のゾーンのキーの上に署名を提供するために、親の以外のドメイン名を可能にする任意の承認モデル。
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.
世界的に確保するゾーンは、一言で言えば、アルゴリズム（RFC 2535、セクション3.2）を実装する唯一の必須使用し、委任木（ツリー上の検証）を平行鍵証明書チェーンに依存しているゾーンです。世界的に確保するゾーンは、次の規則によって定義されています。
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.ゾーンの頂点はKEY RRセットを持たなければなりません。セット内のアルゴリズムを実装するために必須の少なくとも1つのゾーン署名鍵RR（2.A）が存在していなければなりません。
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.ゾーンの頂点KEYのRRセットは親ゾーンに属する秘密鍵によって署名されなければなりません。秘密鍵の公開コンパニオンは、アルゴリズムを実装し、親の頂点が所有する必須のゾーン署名KEYのRR（2.A）でなければなりません。
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. NXTレコードは、ゾーン全体に展開されなければなりません。 （。明確にRFC 2535、セクション2.3.2）注意：現在のNXTレコードといくつかの操作上の不快感があります。二つのことが起こる場合は、この要件が変更に開いています。まず、NXTへの代替メカニズムが定義され、第二のゾーンはそれが別の方法を使用していることを示すことが可能な手段です。
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.ゾーン・メンバーシップの資格各RRセットは、頂点のKEY RRセットにあり、アルゴリズムを実装するための必須のゾーン署名鍵RR（2.A）であるキーによって署名されなければなりません。 （アップデート2535、セクション2.3.1。）
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.を支配例外を除いて、世界的に確保し、ローカルのための規則に準拠が確保されれば提供しているとみなされますまた会ったこと（必須要件を実装します）。
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.ゾーンの頂点はKEY RRセットを持たなければなりません。セット内の少なくとも1つのゾーン署名鍵RR（2.A）が存在していなければなりません。
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.ゾーンの頂点KEYのRRセットは秘密鍵によって署名されなければならないと次の二つの箇条の一つが成立しなければなりません。
2.2.b.1 The private key's public companion MUST be pre-configured in all the resolvers of interest.
2.2.b.1秘密鍵の公開コンパニオンは、関心のあるすべてのリゾルバにあらかじめ設定されなければなりません。
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.2秘密鍵の公開コンパニオンはゾーン署名KEYのRR（2.A）でなければならない関心のリゾルバによって認識されているように、ゾーンの頂点KEYのRRセットの検証を提供することを許可。
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. NXTレコードは、ゾーン全体に展開されなければなりません。注意：議論以下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.ゾーン・メンバーシップの資格各RRセットは、頂点のKEY RRセットにあり、KEY RR（2.A）を署名ゾーンであるキーによって署名されなければなりません。 （アップデート2535、セクション2.3.1。）
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.
他のすべてのゾーンは、無担保としての資格。これは、そのトピックの後のセクションで定義されているように、実験的に安全であるように設計されたゾーンを含んでいます。
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.
最も制限DNSSEC検証ルールに従うリゾルバは、ローカルでのみ固定されているゾーンを含む、無担保として世界的に安全な確保とゾーン、および他のすべてが表示されます。確保などのアルゴリズムを実装するために義務的に加えて、アルゴリズムを実装するものなど、限定されないリゾルバは、いくつかのローカル確保のゾーンが表示されます。
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.
ラベルの意図は、「グローバル」と「ローカル」ゾーンの特定の属性を特定することです。単語は、ゾーン管理者は、DNSセキュリティ拡張を利用することで取る行動を推薦文書の執筆を支援するために選択されています。単語は明示的にDNSのセキュリティ標準の遵守の状態を伝えることを意図していません。
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.
移行を容易にする目的は、実験的に安全な状態の特別な指定をすることなく達成することができます。実験的に安全なローカル担保の特殊なケースです。ゾーン管理者は、署名付きゾーンを公開し、対応する公開鍵でテストリゾルバのセットを構成することによって、これを達成することができます。公開鍵がKEYのRRで公開されていても、限り親の署名がないので、リゾルバは署名を処理するために知っているいくつかの事前設定が必要になります。これは、ゾーンは、実験の球にして固定することが、それでも一般的なインターネットでの無担保として登録することができます。
4 IANA Considerations
4つのIANAの考慮事項
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.
指定されたプロトコルまたは推奨アクションの遵守を強制する手段がなければ、「完全」に固定されるようにDNSゾーンを宣言することは不可能です。 DNSの全能のビューを想定したとしても、場合、1が適切なセキュリティのために設定されるゾーンを宣言することができ、およびルートまでのすべてのゾーンも、ふらちなリゾルバは、不良データを信じるようにだまさすることができます。ゾーンとリゾルバが遵守した場合は、非準拠または堕落親が操作を中断できます。希望することができる最高のは、すべての関係者がセキュアと判断されるように準備されており、そのセキュリティインシデントが短いために、原因に遡ることができるということです。
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.
セキュリティで保護されたゾーンの定義を洗練する必要がNIC-SE（.SEレジストラ）、CAIRN（DARPAの資金による研究ネットワーク）、およびその他のワークショップが主催する2回のDNSSECのワークショップでは、参加者の努力を通じて明らかになりました。文書につながるさらなる議論がオラフルグドムンソン、ラス・マンディ、ロバート・ワトソン、そしてブライアンウェリントンが含まれます。ロイ・アレンズ、テッドLindgreenなどはメーリングリストnamedroppers経由で重要な入力を貢献しました。
7 References
7つの参考文献
[RFC1034] Mockapetris, P., "Domain Names - Concepts and Facilities", STD 13, RFC 1034, November 1987.
[RFC1034] Mockapetris、P.、 "ドメイン名 - 概念および機能"、STD 13、RFC 1034、1987年11月。
[RFC1035] Mockapetris, P., "Domain Names - Implementation and Specification", STD 13, RFC 1035, November 1987.
[RFC1035] Mockapetris、P.、 "ドメイン名 - 実装と仕様"、STD 13、RFC 1035、1987年11月。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119]ブラドナーの、S.、 "要件レベルを示すためにRFCsにおける使用のためのキーワード"、BCP 14、RFC 2119、1997年3月。
[RFC2136] Vixie, P., (Ed.), Thomson, S., Rekhter, Y. and J. Bound, "Dynamic Updates in the Domain Name System", RFC 2136, April 1997.
[RFC2136]いるVixie、P.、（編）、トムソン、S.、Rekhter、Y.、およびJ.はバウンド、 "ドメインネームシステムにおける動的更新"、RFC 2136、1997年4月。
[RFC2535] Eastlake, D., "Domain Name System Security Extensions", RFC 2535, March 1999.
[RFC2535]イーストレイク、D.、 "ドメインネームシステムのセキュリティ拡張機能"、RFC 2535、1999年3月。
[RFC3007] Wellington, B., "Simple Secure Domain Name System (DNS) Dynamic Update", RFC 3007, November 2000.
[RFC3007]ウェリントン、B.、 "シンプル・セキュアドメインネームシステム（DNS）動的更新"、RFC 3007、2000年11月。
[RFC3008] Wellington, B., "Domain Name System Security (DNSSEC) Signing Authority", RFC 3008, November 2000.
[RFC3008]ウェリントン、B.、 "ドメインネームシステムセキュリティ（DNSSEC）署名権限"、RFC 3008、2000年11月。
10 Author's Address
10著者のアドレス
Edward Lewis NAI Labs 3060 Washington Road Glenwood MD 21738
エドワード・ルイスNAI Labsの3060ワシントンロードグレンウッドMD 21738
Phone: +1 443 259 2352 EMail: lewis@tislabs.com
電話：+1 443 259 2352 Eメール：lewis@tislabs.com
11 Full Copyright Statement
11完全な著作権声明
Copyright (C) The Internet Society (2001). All Rights Reserved.
著作権（C）インターネット協会（2001）。全著作権所有。
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.
RFC Editor機能のための基金は現在、インターネット協会によって提供されます。