RFC3090 日本語訳
3090 DNS Security Extension Clarification on Zone Status. E. Lewis. March 2001. (Format: TXT=24166 bytes) (Obsoleted by RFC4033, RFC4034, RFC4035) (Updates RFC2535) (Updated by RFC3658) (Status: PROPOSED STANDARD)
プログラムでの自動翻訳です。
英語原文
Network Working Group E. Lewis Request for Comments: 3090 NAI Labs Category: Standards Track March 2001
コメントを求めるワーキンググループE.ルイスの要求をネットワークでつないでください: 3090年のNAI研究室カテゴリ: 2001年の標準化過程行進
DNS Security Extension Clarification on Zone Status
ゾーン状態におけるDNSセキュリティ拡大明確化
Status of this Memo
この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.
このドキュメントは、インターネットコミュニティにインターネット標準化過程プロトコルを指定して、改良のために議論と提案を要求します。 このプロトコルの標準化状態と状態への「インターネット公式プロトコル標準」(STD1)の現行版を参照してください。 このメモの分配は無制限です。
Copyright Notice
版権情報
Copyright (C) The Internet Society (2001). All Rights Reserved.
Copyright(C)インターネット協会(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.
RFC2535のセクションをはっきりさせて、アップデートして、機密保護しているゾーンの定義は提示されます。 RFC2535がアルゴリズム基礎あたりのaに基づいて保証されるゾーンを定義して、例えば、ゾーンはRSAキーで保証して、DSAキーで保証できません。 このドキュメントは、機密保護されるか、または使用される(または、使用されません)主要なアルゴリズムにかかわらず機密保護されないようにゾーンを定義するためにこれを変えます。 さらにゾーンの状態の決断を簡素化するために、「実験的に安全な」状態は推奨しないです。
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処理を必要とするかもしれない)がいつ到着するかを質問に尋ねます。 代表として派遣するゾーンは親が状態を示すデータを入力する子供ゾーンの問題に子供を尋ねます。 レゾルバはゾーンに属すデータを受け取り次第質問します。
1.1 When a Zone's Status is Important
ZoneのStatusであるときに、1.1はImportantです。
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とその管理の分配された本質のためそれがわかって、セキュリティの外観のこととなると、どんなただ一つのゾーンも他のゾーンの思うままにあります。 このドキュメントはゾーンが安全な状態で資格を得ることを定義するでしょう。
Lewis Standards Track [Page 1] RFC 3090 DNS Security Extension on Zone Status March 2001
ルイスStandardsは2001年3月にゾーン状態でRFC3090DNSセキュリティ拡張子を追跡します[1ページ]。
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.
レゾルバは、ゾーンからレゾルバが処理データであるときに、ゾーンが保証されるかどうかを知る必要があります。 結局、レゾルバは、データをカバーする使用可能な署名を予想するかどうかを知る必要があります。 このドキュメントの範囲の外にこの決断がどう完了しているかがあります、いくつかの場合、レゾルバが、親が、子供が機密保護されると述べるかどうかを見るためにゾーンの親に連絡する必要があるのを除いて。
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."
DNSSECの目標は各ゾーンを保証させることです、ルートゾーンと階層構造の下側への最上位のドメインから葉のゾーンまで。 unsecured DNSから移行して、私たちのように現在を持ってください、完全に機密保護されたa、または「機密保護されるのと同じくらい多く」に--木はある程度時間がかかるでしょう。 この間に、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委譲と共に機密保護されるようになるプロセスを通ったかもしれません。 親ゾーン(region1)が保証されないので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の下のゾーンを保証しました。「セキュリティの島」はそうですか? DNSSECレゾルバがこの島からのどんなデータも信じるようになる唯一の方法がレゾルバがsubarea1.region1.testのためにゾーンキーであらかじめ設定されるかどうかということである、すなわち、セキュリティの島の根。 他のレゾルバ(そのように構成されない)は非機密保護されるようにこの島を認識するでしょう。
Lewis Standards Track [Page 2] RFC 3090 DNS Security Extension on Zone Status March 2001
ルイスStandardsは2001年3月にゾーン状態でRFC3090DNSセキュリティ拡張子を追跡します[2ページ]。
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つの島があるかもしれません--上側の島の下部と下側の機密保護している島の根の間に少なくとも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管理しているスタッフによって適切に機密保護している状態に持って来られた両方を持ってください、そして、2つのものの後者だけが実際にすべてのDNSSECレゾルバがそうすることができるという意味で「グローバルに」機密保護されて、データについて確かめるでしょう。 まさしくものは、前者(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.
RFC2535に、支給が「証明当局」(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.
例えば、aを考えて、安全なルーツの"exp.test"と"sub.domain.testing.signed.exp.test" 当然のことを命名してください、"testing.signed.exp.test" 「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.
望まれている中で最も近くもの理由は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個のラベルですが、合ってください。
Lewis Standards Track [Page 3] RFC 3090 DNS Security Extension on Zone Status March 2001
ルイスStandardsは2001年3月にゾーン状態でRFC3090DNSセキュリティ拡張子を追跡します[3ページ]。
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.
セキュリティの島がとにかくどんな概念的におもしろい考えも紹介しないで、影響でないのにプロトコルをする重なること。 しかしながら、プロトコルimplementersが、彼らのコードが輪のためにオーバラップによって投げられないのを確実にするようにアドバイスされます。 オーバラップはセキュリティの島がスペースという名前の、より広大な地域を取り囲むようになるので設定問題であることを確信しています。
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.
この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.
答を見つけるために、あなたは点検していて、セキュリティの島の中のゾーンを通って下らなければならないかもしれません。 島の信じられた根で始まって、あなたはゾーンが倒す次の中に降ります。 上側のゾーンを信じるとき、あなたは、それからの次のゾーンに関するデータが下がるようになる必要があります。そうでなければ、ゾーンをハイジャックできる損傷を受けやすい箇所があります。 いつ達するか、そして、またはあなたがaに達するかどうかが機密保護しているゾーンから非機密保護しているゾーンまでの横断を指して、あなたは、セキュリティの島を出て、答えが非機密保護されると結論づけるべきです。
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:
しかしながら、RFC2535、セクション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があらゆる「副-ゾーン」のためにあるに違いありません。 これは、通常、「副-ゾーン」に現れて、また、「スーパー-ゾーン」に含まれるかもしれません。 しかし、変更しないか、またはどんなセキュリティRRsも加えるように変更できないunsecured subzoneの場合に、「スーパー-ゾーン」署名が「スーパー-ゾーン」にある状態で、「副-ゾーン」が非機密保護されると宣言する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.
と対照的に、ここでの混乱がRFC2535では、機密保護している親が、子供がSAYING NOTHINGによって機密保護されると述べるということである、(「また、あるかもしれない」、「また、あるに違いない」、) これがカウンタ直感的である、データの欠如が何かを意味するという事実は「機密保護されて」ことです。 この概念であり、許容できますが、理論的な設定は操作設定の何らかの不快にあいました。 しかしながら、何かを述べる「沈黙」の使用がこの場合本当に働いているので、定義を変えるために示された十分な必要がありませんでした。
Lewis Standards Track [Page 4] RFC 3090 DNS Security Extension on Zone Status March 2001
ルイスStandardsは2001年3月にゾーン状態でRFC3090DNSセキュリティ拡張子を追跡します[4ページ]。
1.4 Impact on RFC 2535
1.4 RFC2535の上の影響
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.
このドキュメントはRFC2535のセクションをアップデートします。 機密保護しているゾーンの定義はRFCのセクション3.4へのアップデートです。 実験用キーの定義を排除して、提供するためにまだ機能性を達成しているように、それらが設計された方法を例証するためにセクション3.4をアップデートします。 セクション3.1 .3 ゾーンのプロトコル八重奏の値が合わせる指定で、アップデートします。
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.
このドキュメントのキーワード「必要で」、“SHOULD"の、そして、「お勧め」の“MUST"、および「5月」は[RFC2119]で説明されるように解釈されることです。 現在、“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. ZoneがKEY RRに署名して、旗の分野には名前タイプ(ゾーンキーを示す)のための値01があるKEY RRとどちらかが主要なタイプのために00か値01を評価します(データを認証することが許可されたキーを示して)。 (RFC2535、セクション3.1.2を見ます。) また、KEY RRには、DNSSEC(3)かすべての(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.)
定義はRFC2535のゾーンキーの定義をアップデートします。 プロトコル分野が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
2. 木の上のb Validation--親ゾーンだけが信頼のチェーンを子供のものから建てるのにレゾルバによって使用されるDNSSEC重要な署名に供給するために認識される承認モデル
Lewis Standards Track [Page 5] RFC 3090 DNS Security Extension on Zone Status March 2001
ルイスStandardsは2001年3月にゾーン状態でRFC3090DNSセキュリティ拡張子を追跡します[5ページ]。
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.
セキュリティの認識された根のキー。 信じられたキー、おそらくルートキーに達するように、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オフ木のValidation--親のもの以外のドメイン名が子供のゾーンキーの上の署名にそれを提供するのを可能にするどんな承認モデルも、レゾルバがキーを信じるのを可能にするでしょう。
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.
グローバルに機密保護しているゾーンがaが単にアルゴリズムが(RFC2535、セクション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を用意ができさせなければなりません。 KEY RRに署名する少なくとも1つのゾーンがあるに違いありません。(セットでアルゴリズムを実装するために義務的なaの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に署名するゾーンであるに違いありません。(アルゴリズムを実装するために義務的で親の頂点によって所有されているaの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記録を配布しなければなりません。 (RFC2535、セクション2.3.2をはっきりさせます。) 以下に注意してください。 何らかの操作上の不快が現在のNXT記録と共にあります。 2つのことが起こるとき、この要件は変更に開かれています。 まず最初に、NXTへの代替のメカニズムは2番目に、定義されます、ゾーンが代替方法を使用しているのを示すことができる手段。
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。 KEY RRに署名するアペックスのKEY RRセットにあって、ゾーンであるキーでゾーン会員資格への資格を得るそれぞれのRRセットに署名しなければなりません。(アルゴリズムを実装するために義務的なaの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.がある例外で機密保護されて、また、会われて(要件を実装するために義務的な)、規則に従います。
Lewis Standards Track [Page 6] RFC 3090 DNS Security Extension on Zone Status March 2001
ルイスStandardsは2001年3月にゾーン状態でRFC3090DNSセキュリティ拡張子を追跡します[6ページ]。
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。 ゾーンの頂点で、KEY RRを用意ができさせなければなりません。 KEY RRに署名する少なくとも1つのゾーンがあるに違いありません。(セットにおける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「副-節」の1つは有効でなければなりません。
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.
秘密鍵の公共の仲間はKEY RRに署名するゾーンであるに違いありません。2.2. b.2、(ゾーンの頂点の合法化にKEY 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。 KEY RRに署名するアペックスのKEY RRセットにあって、ゾーンであるキーでゾーン会員資格への資格を得るそれぞれのRRセットに署名しなければなりません。(2.a)。 (アップデート2535、セクション2.3.1。)
2.3 Unsecured
2.3はUnsecuredされました。
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.
他のすべてのゾーンが非機密保護されるように資格を得ます。 これは実験的に安全になるようにその話題の後のセクションで定義されるように設計されているゾーンを含んでいます。
Lewis Standards Track [Page 7] RFC 3090 DNS Security Extension on Zone Status March 2001
ルイスStandardsは2001年3月にゾーン状態でRFC3090DNSセキュリティ拡張子を追跡します[7ページ]。
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.
最も制限している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.
実験的に安全な状態の特別な名称なしで移行を容易にする目的を達成できます。 実験的に機密保護されているのは、局所的に機密保護されることの特別なケースです。 ゾーンの管理者は、署名でゾーンを発行して、対応する公開鍵で1セットのテストレゾルバを構成することによって、これを達成できます。 親署名が全くない限り、公開鍵がKEY RRで発行されても、レゾルバは、署名を処理するのを知るために何らかのプレ構成を必要とするでしょう。 これは実験の範囲で機密保護されるゾーンを許容します、一般的なインターネットで非機密保護されるようにまだまだ登録されていて。
4 IANA Considerations
4 IANA問題
This document does not request any action from an assigned number authority nor recommends any actions.
このドキュメントは、規定番号権威から少しの動作も要求しないで、どんな動作も推薦します。
Lewis Standards Track [Page 8] RFC 3090 DNS Security Extension on Zone Status March 2001
ルイスStandardsは2001年3月にゾーン状態でRFC3090DNSセキュリティ拡張子を追跡します[8ページ]。
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ワークショップで関係者の取り組みを通して明らかで、後援されるようになりました。 ドキュメントにつながるさらなる議論がOlafurグドムンソン、ラス・マンディ、ロバート・ワトソン、およびブライアン・ウェリントンを含んでいます。 ロイArends、テッドLindgreen、および他のものはnamedroppersメーリングリストで重要な入力を寄付しました。
7 References
7つの参照箇所
[RFC1034] Mockapetris, P., "Domain Names - Concepts and Facilities", STD 13, RFC 1034, November 1987.
[RFC1034]Mockapetris、P.、「ドメイン名--、概念と施設、」、STD13、RFC1034、11月1987日
[RFC1035] Mockapetris, P., "Domain Names - Implementation and Specification", STD 13, RFC 1035, November 1987.
[RFC1035]Mockapetris、P.、「ドメイン名--、実装と仕様、」、STD13、RFC1035、11月1987日
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119] ブラドナー、S.、「Indicate Requirement LevelsへのRFCsにおける使用のためのキーワード」、BCP14、RFC2119、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.バウンド、「ドメインネームシステムにおけるダイナミックなアップデート」RFC2136(1997年4月)。
[RFC2535] Eastlake, D., "Domain Name System Security Extensions", RFC 2535, March 1999.
[RFC2535] イーストレーク、D.、「ドメインネームシステムセキュリティ拡大」、RFC2535、1999年3月。
[RFC3007] Wellington, B., "Simple Secure Domain Name System (DNS) Dynamic Update", RFC 3007, November 2000.
[RFC3007] ウェリントン、B.、「簡単な安全なドメインネームシステム(DNS)ダイナミック・アップデート」、RFC3007、2000年11月。
[RFC3008] Wellington, B., "Domain Name System Security (DNSSEC) Signing Authority", RFC 3008, November 2000.
[RFC3008] ウェリントン、B.、「ドメインネームシステムセキュリティ(DNSSEC)署名権威」、RFC3008、2000年11月。
Lewis Standards Track [Page 9] RFC 3090 DNS Security Extension on Zone Status March 2001
ルイスStandardsは2001年3月にゾーン状態でRFC3090DNSセキュリティ拡張子を追跡します[9ページ]。
10 Author's Address
10作者のアドレス
Edward Lewis NAI Labs 3060 Washington Road Glenwood MD 21738
エドワードルイスNAI研究室3060ワシントン道路グレンウッドMD 21738
Phone: +1 443 259 2352 EMail: lewis@tislabs.com
以下に電話をしてください。 +1 2352年の443 259メール: lewis@tislabs.com
Lewis Standards Track [Page 10] RFC 3090 DNS Security Extension on Zone Status March 2001
ルイスStandardsは2001年3月にゾーン状態でRFC3090DNSセキュリティ拡張子を追跡します[10ページ]。
11 Full Copyright Statement
11 完全な著作権宣言文
Copyright (C) The Internet Society (2001). All Rights Reserved.
Copyright(C)インターネット協会(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.
それに関するこのドキュメントと翻訳は、コピーして、それが批評するか、またはそうでなければわかる他のもの、および派生している作品に提供するか、または準備されているかもしれなくて、コピーされて、発行されて、全体か一部分配された実装を助けるかもしれません、どんな種類の制限なしでも、上の版権情報とこのパラグラフがそのようなすべてのコピーと派生している作品の上に含まれていれば。 しかしながら、このドキュメント自体は何らかの方法で変更されないかもしれません、インターネット協会か他のインターネット組織の版権情報か参照を取り除くのなどように、それを英語以外の言語に翻訳するのが著作権のための手順がインターネットStandardsプロセスで定義したどのケースに従わなければならないか、必要に応じてさもなければ、インターネット標準を開発する目的に必要であるのを除いて。
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機能のための基金は現在、インターネット協会によって提供されます。
Lewis Standards Track [Page 11]
ルイス標準化過程[11ページ]
一覧
スポンサーリンク