[要約] RFC 3090は、DNSセキュリティ拡張に関するゾーンの状態の明確化についての要約です。このRFCの目的は、ゾーンの状態に関する情報を提供し、DNSセキュリティの実装と運用を向上させることです。
Network Working Group E. Lewis
Request for Comments: 3090 NAI Labs
Category: Standards Track March 2001
DNS Security Extension Clarification on Zone Status
ゾーンステータスに関するDNSセキュリティ拡張の説明
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.
Copyright（c）The Internet Society（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のセクションを明確にし、更新します。RFC2535は、アルゴリズムベースに基づいて保護されるゾーンを定義します。このドキュメントは、これを変更して、使用される（または使用していない）キーアルゴリズムに関係なく、保護されているか、保護されていないゾーンを定義します。ゾーンのステータスの決定をさらに簡素化するために、「実験的に安全な」ステータスは非推奨です。
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?
子ゾーンが保護されているかどうかを示すには、委任ゾーンが必要です。この要件の理由は、リゾルバーがゾーンについて独自の決定をする方法にあります（次の段落）。長い話を短くするために、親は子供が安全であると見なされるべきかどうかを知る必要があります。これは2つの部分の質問です。親はどのような状況下で子ゾーンを安全であると考えていますか？また、親は子供が適合するかどうかをどのように知りますか？
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です。 ではないかもしれません。 （参照のために、領域2.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以下の連続したセキュリティゾーンのコレクションを説明する口語フレーズ。「安全の島」です。DNSSECリゾルバーがこの島のデータを信頼するようになる唯一の方法は、リゾルバーが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.
セキュリティ島は、公開キーがリゾルバーに事前に構成されている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]があります。他のドキュメントに関係なく、Resolversは、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。」そして、「not-same.xy。」、中央のものが最も近いものです。最初のセキュアルートは、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.
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.
スーパーゾーンが安全な場合は、すべてのサブゾーンについて、スーパーゾーンで署名されたゾーンキーRRが必要です。これは通常、サブゾーンに表示され、スーパーゾーンにも含まれる場合があります。しかし、セキュリティRRSを追加するために変更できない、または変更できない無担保サブゾーンの場合、Superzoneが安全である場合、Superzoneの署名でSuperzone署名でサブゾーンを宣言するキーが表示されなければなりません。
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 2535のセクションを更新します。安全なゾーンの定義は、RFCのセクション3.4の更新です。セクション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.
このドキュメントの「必須」、「必須」、「必要」、「推奨」、および「5月」は、[RFC 2119]で説明されているように解釈されます。現在、このドキュメントでは「必須」のみが使用されています。
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 -Flagフィールドに名前タイプ（ゾーンキーを示す）の値01とキータイプの値01（データの認証が許可されているキーを示す）のキーRR。（RFC 2535、セクション3.1.2を参照）。キー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またはすべてであるという要件は、新しい要件です（セクション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. ゾーンの頂点には、キーRRセットが必要です。 セットにアルゴリズムを実装するための必須のキーRR（2.a）に少なくとも1つのゾーンに署名する必要があります。
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.ゾーンの頂点キーRRセットは、親ゾーンに属する秘密鍵で署名する必要があります。秘密鍵のパブリックコンパニオンは、アルゴリズムを実装し、親の頂点が所有するために必須のキー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レコードには、運用上の不快感があります。この要件は、2つのことが発生したときに変更するために開かれています。第一に、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セットは、ApexのキーRRセットにあるキーによって署名する必要があり、アルゴリズムを実装するための必須のキーRR（2.a）に署名するゾーン署名キー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.ゾーンの頂点には、キー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.ゾーンのApexキーRRセットは秘密鍵で署名する必要があり、次の2つのサブクロースのいずれかを保持する必要があります。
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秘密鍵のパブリックコンパニオンは、関心のあるリソースバーによって認識されているように、ゾーンのApexキーRRセットの検証を提供することを許可されたキーRR（2.A）に署名するゾーンでなければなりません。
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セットは、APEXのキーRRセットにあるキーで署名し、キー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.
実験的に安全なステータスを特別に指定することなく、移行を促進するという目的を達成できます。実験的に保護されていることは、地元で保護された特別なケースです。ゾーン管理者は、署名を備えたゾーンを公開し、対応するパブリックキーを使用してテストリゾルバーのセットを構成することにより、これを実現できます。親の署名がない限り、公開キーがキー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の全能ビューを想定しても、セキュリティのために適切に構成されているゾーンを宣言でき、すべてのゾーンもルートまで宣言することができます。ゾーンとリゾルバーが準拠している場合、非準拠または破壊された親は操作を中断する可能性があります。期待できるのは、すべての当事者が安全であると判断される準備ができており、セキュリティインシデントが短期間で原因にまでさかのぼることができるということです。
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ワークショップで参加者の努力を通じて明らかになりました。この文書につながるさらなる議論には、Olafur Gudmundsson、Russ Mundy、Robert Watson、およびBrian Wellingtonが含まれます。Roy Arends、Ted Lindgreenなどは、AnigantPersメーリングリストを介して重要なインプットを提供しています。
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] Bradner、S。、「要件レベルを示すためにRFCで使用するためのキーワード」、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。、（ed。）、Thomson、S.、Rekhter、Y。およびJ. Bound、「ドメイン名システムの動的更新」、RFC 2136、1997年4月。
[RFC2535] Eastlake, D., "Domain Name System Security Extensions", RFC 2535, March 1999.
[RFC2535] Eastlake、D。、「ドメイン名システムセキュリティ拡張機能」、RFC 2535、1999年3月。
[RFC3007] Wellington, B., "Simple Secure Domain Name System (DNS) Dynamic Update", RFC 3007, November 2000.
[RFC3007] Wellington、B。、「Simple Secure Domain Name System（DNS）Dynamic Update」、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
エドワードルイスナイラボ3060ワシントンロードグレンウッド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.
Copyright（c）The Internet Society（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エディター機能の資金は現在、インターネット協会によって提供されています。