Network Working Group H. Eland
Request for Comments: 4986 Afilias Limited
Category: Informational R. Mundy
SPARTA, Inc.
S. Crocker
Shinkuro Inc.
S. Krishnaswamy
SPARTA, Inc.
August 2007
Requirements Related to DNS Security (DNSSEC) Trust Anchor Rollover
DNSセキュリティ（DNSSEC）トラストアンカーのロールオーバーに関する要求事項
Status of This Memo
このメモのステータス
This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited.
このメモはインターネットコミュニティのための情報を提供します。それはどんな種類のインターネット標準を指定しません。このメモの配布は無制限です。
Abstract
抽象
Every DNS security-aware resolver must have at least one Trust Anchor to use as the basis for validating responses from DNS signed zones. For various reasons, most DNS security-aware resolvers are expected to have several Trust Anchors. For some operations, manual monitoring and updating of Trust Anchors may be feasible, but many operations will require automated methods for updating Trust Anchors in their security-aware resolvers. This document identifies the requirements that must be met by an automated DNS Trust Anchor rollover solution for security-aware DNS resolvers.
すべてのDNSのセキュリティ対応リゾルバは、ゾーンに署名したDNSからの応答を検証するための基礎として使用するには、少なくとも1つのトラストアンカーを持っている必要があります。様々な理由から、ほとんどのDNSのセキュリティ対応リゾルバは、いくつかのトラストアンカーを有することが期待されます。いくつかの操作については、トラストアンカーの手動監視と更新が可能かもしれないが、多くの操作は、彼らのセキュリティ対応リゾルバでトラストアンカーを更新するための自動化された方法が必要になります。この文書では、セキュリティ対応のDNSリゾルバのための自動化されたDNSトラストアンカーのロールオーバー・ソリューションによって満たされなければならない要件を識別します。
Table of Contents
目次
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. Background . . . . . . . . . . . . . . . . . . . . . . . . . . 3
4. Definitions . . . . . . . . . . . . . . . . . . . . . . . . . . 4
5. Requirements . . . . . . . . . . . . . . . . . . . . . . . . . 6
5.1. Scalability . . . . . . . . . . . . . . . . . . . . . . . . 6
5.2. No Known Intellectual Property Encumbrance . . . . . . . . 6
5.3. General Applicability . . . . . . . . . . . . . . . . . . . 7
5.4. Support Private Networks . . . . . . . . . . . . . . . . . 7
5.5. Detection of Stale Trust Anchors . . . . . . . . . . . . . 7
5.6. Manual Operations Permitted . . . . . . . . . . . . . . . . 7
5.7. Planned and Unplanned Rollovers . . . . . . . . . . . . . . 7
5.8. Timeliness . . . . . . . . . . . . . . . . . . . . . . . . 8
5.9. High Availability . . . . . . . . . . . . . . . . . . . . . 8
5.10. New RR Types . . . . . . . . . . . . . . . . . . . . . . . 8
5.11. Support for Trust Anchor Maintenance Operations . . . . . . 8
5.12. Recovery from Compromise . . . . . . . . . . . . . . . . . 8
5.13. Non-Degrading Trust . . . . . . . . . . . . . . . . . . . . 8
6. Security Considerations . . . . . . . . . . . . . . . . . . . . 9
7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 9
8. Normative References . . . . . . . . . . . . . . . . . . . . . 9
The Domain Name System Security Extensions (DNSSEC), as described in [2], [3], and [4], define new records and protocol modifications to DNS that permit security-aware resolvers to validate DNS Resource Records (RRs) from one or more Trust Anchors held by such security-aware resolvers.
ドメインネームシステム1からDNSリソースレコード（RR）を検証するセキュリティ対応リゾルバを許可するセキュリティで説明したように拡張機能（DNSSEC）、[2]、[3]、[4]、DNSに新しいレコードとプロトコルの変更を定義します以上の信頼アンカーは、セキュリティ対応リゾルバが保持しています。
Security-aware resolvers will have to initially obtain their Trust Anchors in a trustworthy manner to ensure the Trust Anchors are correct and valid. There are a number of ways that this initial step can be accomplished; however, details of this step are beyond the scope of this document. Once an operator has obtained Trust Anchors, initially entering the Trust Anchors into their security-aware resolvers will in many instances be a manual operation.
セキュリティ対応リゾルバは、最初はトラストアンカーが正しく、有効であることを確認するために信頼できる方法で自分のトラストアンカーを取得する必要があります。この最初のステップを達成することができますいくつかの方法があります。しかし、このステップの詳細は、このドキュメントの範囲を超えています。オペレータが最初に彼らのセキュリティ対応リゾルバにトラストアンカーを入力、トラストアンカーを取得した後は、多くの場合、手動操作になります。
For some operational environments, manual management of Trust Anchors might be a viable approach. However, many operational environments will require a more automated, specification-based method for updating and managing Trust Anchors. This document provides a list of requirements that can be used to measure the effectiveness of any proposed automated Trust Anchor rollover mechanism in a consistent manner.
いくつかの運用環境では、トラストアンカーの手動管理が実行可能なアプローチであるかもしれません。しかし、多くの運用環境は、トラストアンカーを更新し、管理するためのより自動化、仕様ベースの方法が必要になります。この文書では、一貫性のある方法で任意の提案自動トラストアンカーのロールオーバーメカニズムの有効性を測定するために使用することができる要件のリストを提供します。
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [1].
この文書のキーワード "MUST"、 "MUST NOT"、 "REQUIRED"、、、、 "べきではない" "べきである" "ないもの" "ものとし"、 "推奨"、 "MAY"、および "OPTIONAL" はありますRFC 2119に記載されるように解釈される[1]。
The use of RFC 2119 words in the requirements is intended to unambiguously describe a requirement. If a tradeoff is to be made between conflicting requirements when choosing a solution, the requirement with MUST language will have higher preference than requirements with SHOULD, MAY, or RECOMMENDED language. It is understood that a tradeoff may need to be made between requirements that both contain RFC 2119 language.
RFCを使用することが要件で2119個の単語が明確な要件を記述することを意図しています。トレードオフは、ソリューションを選択する際に相反する要件の間で行われるのであれば、MUST言語と要件はSHOULD、MAY、または推奨言語と要件よりも高い優先順位を持つことになります。トレードオフの両方がRFC 2119の言語が含まれている要件の間で行われる必要があり得ることが理解されます。
DNS resolvers need to have one or more starting points to use in obtaining DNS answers. The starting points for stub resolvers are normally the IP addresses for one or more recursive name servers. The starting points for recursive name servers are normally IP addresses for DNS Root name servers. Similarly, security-aware resolvers must have one or more starting points to use for building the authenticated chain to validate a signed DNS response. Instead of IP addresses, DNSSEC requires that each resolver trust one or more
DNSリゾルバは、DNSの答えを得ることに使用するために、1つの以上の開始点を持っている必要があります。スタブリゾルバのための出発点は、通常、1つまたは複数の再帰ネームサーバのIPアドレスです。再帰ネームサーバのための出発点は、通常はDNSルートネームサーバのIPアドレスです。同様に、セキュリティ対応リゾルバは、署名されたDNS応答を検証するために、認証チェーンを構築するために使用する1つのまたは複数の開始点を持っている必要があります。 IPアドレスの代わりに、DNSSECは、各リゾルバの信頼一つ以上が必要です
DNSKEY RRs or DS RRs as their starting point. Each of these starting points is called a Trust Anchor.
その出発点としてDNSKEYのRRやDSのRR。これらの開始点のそれぞれは、トラストアンカーと呼ばれています。
It should be noted that DNSKEY RRs and DS RRs are not Trust Anchors when they are created by the signed zone operator nor are they Trust Anchors because the records are published in the signed zone. A DNSKEY RR or DS RR becomes a Trust Anchor when an operator of a security-aware resolver determines that the public key or hash will be used as a Trust Anchor. Thus, the signed zone operator that created and/or published these RRs may not know if any of the DNSKEY RRs or DS RRs associated with their zone are being used as Trust Anchors by security-aware resolvers. The obvious exceptions are the DNSKEY RRs for the Root Zone, which will be used as Trust Anchors by many security-aware resolvers. For various reasons, DNSKEY RRs or DS RRs from zones other than Root can be used by operators of security-aware resolvers as Trust Anchors. It follows that responsibility lies with the operator of the security-aware resolver to ensure that the DNSKEY and/or DS RRs they have chosen to use as Trust Anchors are valid at the time they are used by the security-aware resolver as the starting point for building the authentication chain to validate a signed DNS response.
彼らが署名ゾーンオペレータによって作成されたものレコードが署名したゾーンで公開されているので、彼らはアンカーを信頼されているときDNSKEYのRRとDSのRRはアンカーを信頼していないことに留意すべきです。セキュリティ対応リゾルバの演算子は、公開鍵またはハッシュは、トラストアンカーとして使用されると判断した場合DNSKEYのRRまたはDS RRは、トラストアンカーとなります。そのゾーンに関連付けられているDNSKEYのRRのか、DSのRRのいずれかがセキュリティ対応リゾルバでトラストアンカーとして使用されている場合はこのように、これらのRRを作成および/または公開署名ゾーンオペレータは知らないかもしれません。明らかな例外は、多くのセキュリティ対応リゾルバでトラストアンカーとして使用されるルートゾーンのためのDNSKEYのRRです。様々な理由から、root以外のゾーンからのDNSKEYのRRまたはDS RRはトラストアンカーとしてセキュリティ対応リゾルバのオペレータによって使用することができます。責任はそれらがトラストアンカーとして使用することを選択したDNSKEYおよび/またはDSのRRは、彼らが出発点として、セキュリティ対応リゾルバが使用している時に有効であることを保証するために、セキュリティ対応リゾルバのオペレータであるということになります認証チェーンを構築するために署名したDNS応答を検証します。
When operators of security-aware resolvers choose one or more Trust Anchors, they must also determine the method(s) they will use to ensure that they are using valid RRs and that they are able to determine when RRs being used as Trust Anchors should be replaced or removed. Early adopters of DNS signed zones have published information about the processes and methods they will use when their DNSKEY and/or DS RRs change so that operators of security-aware resolvers can manually change the Trust Anchors at the appropriate time. This manual approach will not scale and, therefore, drives the need for an automated specification-based approach for rollover of Trust Anchors for security-aware resolvers.
セキュリティ対応リゾルバのオペレータは、1つまたは複数のトラストアンカーを選択すると、彼らはまた、彼らは有効なRRを使用していることとトラストアンカーがあるべきなのRRが使用されたとき、彼らは決定することができることを保証するために使用する方法（複数可）を決定する必要があります交換または削除。 DNSの早期導入は、ゾーンがセキュリティ対応リゾルバのオペレーターが手動で適切な時間にトラストアンカーを変更することができるように、彼らは彼らのDNSKEYおよび/またはDS RRを変更する際に使用するプロセスおよび方法についての情報を公開している署名しました。このマニュアルのアプローチは、そのため、セキュリティ対応リゾルバのためのトラストアンカーのロールオーバーのための自動化された仕様に基づいたアプローチの必要性を駆動し、スケールとしません。
This document uses the definitions contained in RFC 4033, section 2, plus the following additional definitions:
この文書は、RFC 4033に含まれる定義、セクション2に加え、以下の追加の定義を使用します。
Trust Anchor: From RFC 4033, "A configured DNSKEY RR or DS RR hash of a DNSKEY RR. A validating security-aware resolver uses this public key or hash as a starting point for building the authentication chain to a signed DNS response." Additionally, a DNSKEY RR or DS RR is associated with precisely one point in the DNS hierarchy, i.e., one DNS zone. Multiple Trust Anchors MAY be associated with each DNS zone and MAY be held by any number of security-aware resolvers. Security-aware resolvers MAY have Trust Anchors from multiple DNS zones. Those responsible for the operation of security-aware resolvers are responsible for determining the set of RRs that will be used as Trust Anchors by that resolver.
トラストアンカー：RFC 4033から、「構成されたDNSKEYのRRやDNSKEY RRのDS RRハッシュ検証をセキュリティ対応リゾルバが署名したDNS応答への認証チェーンを構築するための出発点として、この公開キーまたはハッシュを使用しています。」また、DNSKEYのRRまたはDS RRは、DNS階層の正確に1つの点、すなわち1つのDNSゾーンに関連付けられています。複数のトラストアンカーは、各DNSゾーンに関連付けられてもよく、セキュリティ対応リゾルバの任意の数によって保持されてもよいです。セキュリティ対応リゾルバは、複数のDNSゾーンからトラストアンカーを持っているかもしれません。セキュリティ対応リゾルバの動作の責任者は、リゾルバでトラストアンカーとして使用されるRRのセットを決定する責任があります。
Initial Trust Relationship: Operators of security-aware resolvers must ensure that they initially obtain any Trust Anchors in a trustworthy manner. For example, the correctness of the Root Zone DNSKEY RR(s) could be verified by comparing what the operator believes to be the Root Trust Anchor(s) with several 'well-known' sources such as the IANA web site, the DNS published Root Zone and the publication of the public key in well-known hard-copy forms. For other Trust Anchors, the operator must ensure the accuracy and validity of the DNSKEY and/or DS RRs before designating them Trust Anchors. This might be accomplished through a combination of technical, procedural, and contractual relationships, or use other existing trust relationships outside the current DNS protocol.
初期信頼関係：セキュリティ対応リゾルバのオペレータは、彼らが最初に信頼できる方法で任意のトラストアンカーを取得することを確認する必要があります。たとえば、ルートゾーンDNSKEY RR（S）の正しさは、オペレータは、このようなIANAのウェブサイトなど、いくつかの「有名」ソースとのルートトラストアンカー（S）であると信じるものを比較することで検証することができ、DNSが公開しますルートゾーンと、よく知られたハードコピーの形で公開鍵の発行。他のトラストアンカーのために、オペレータは彼らにトラストアンカーを指定する前に、DNSKEYおよび/またはDS RRの正確性と妥当性を確認する必要があります。これは、技術的な手続き、および契約関係の組み合わせを通じて達成、または現在のDNSプロトコル外の他の既存の信頼関係を使用している可能性があります。
Trust Anchor Distribution: The method or methods used to convey the DNSKEY and/or DS RR(s) between the signed zone operator and the security-aware resolver operator. The method or methods MUST be deemed sufficiently trustworthy by the operator of the security-aware resolver to ensure source authenticity and integrity of the new RRs to maintain the Initial Trust Relationship required to designate those RRs as Trust Anchors.
トラストアンカー分布：署名されたゾーンのオペレータとセキュリティ対応リゾルバオペレータ間DNSKEYおよび/またはDS RR（S）を搬送するために使用される方法または方法。方法または方法は、トラストアンカーとしてそれらのRRを指定するために必要な最初の信頼関係を維持するために新しいRRのソース信憑性と完全性を保証するために、セキュリティ対応リゾルバのオペレータによって十分に信頼できるとみなされなければなりません。
Trust Anchor Maintenance: Any change in a validating security-aware resolver to add a new Trust Anchor, delete an existing Trust Anchor, or replace an existing Trust Anchor with another. This change might be accomplished manually or in some automated manner. Those responsible for the operation of the security-aware resolver are responsible for establishing policies and procedures to ensure that a sufficient Initial Trust Relationship is in place before adding Trust Anchors for a particular DNS zone to their security-aware resolver configuration.
トラストアンカーメンテナンス：検証し、セキュリティ対応リゾルバの変更、新しいトラストアンカーを追加し、既存のトラストアンカーを削除するか、別の既存のトラストアンカーを交換します。この変更は、手動または自動化されたいくつかの方法で達成される可能性があります。セキュリティ対応リゾルバの動作の責任者は、十分な初期信頼関係が彼らのセキュリティ対応リゾルバ設定に特定のDNSゾーンのトラストアンカーを追加する前に、所定の位置にあることを保証するためのポリシーと手順を確立する責任があります。
Trust Anchor Revocation and Removal: The invalidation of a particular Trust Anchor that results when the operator of the signed zone revokes or removes a DNSKEY RR or DS RR that is being used as a Trust Anchor by any security-aware resolver. It is possible that a zone administrator may invalidate more than one RR at one point in time; therefore, it MUST be clear to both the zone administrator and the security-aware resolver the exact RR(s) that have been revoked or removed so the proper Trust Anchor or Trust Anchors are removed.
トラストアンカー失効および取り外し：署名されたゾーンのオペレータはDNSKEYのRR、または任意のセキュリティ対応リゾルバによって信頼アンカーとして使用されているDS RRを取り消しまたは削除したときに生じる特定のトラストアンカーの無効化。ゾーン管理者は、ある時点で複数のRRを無効にする可能性があります。従って、除去され、適切なトラストアンカーまたはトラストアンカーに失効又は除去された正確なRR（S）リゾルバゾーン管理者とセキュリティ対応の両方に明確でなければなりません。
Trust Anchor Rollover: The method or methods necessary for the secure replacement of one or multiple Trust Anchors held by security-aware resolvers. Trust Anchor Rollover should be considered a subset of Trust Anchor Maintenance.
トラストアンカーロールオーバー：方法またはセキュリティ対応リゾルバに保持された一つまたは複数のトラストアンカーのセキュアな交換のために必要なメソッド。トラストアンカーのロールオーバーは、トラストアンカーメンテナンスのサブセットと考えるべきです。
Normal or Pre-Scheduled Trust Anchor Rollover: The operator of a DNSSEC signed zone has issued a new DNSKEY and/or DS RR(s) as a part of an operational routine.
ノーマルまたはトラストアンカーのロールオーバー事前にスケジュール：DNSSEC署名済みゾーンのオペレータは、操作ルーチンの一部として新しいDNSKEYおよび/またはDS RR（複数可）を発行しました。
Emergency or Non-Scheduled Trust Anchor Rollover: The operator of a signed zone has issued a new DNSKEY and/or DS RR(s) as part of an exceptional event.
緊急または非スケジュールトラストアンカーロールオーバー：署名されたゾーンのオペレータは、例外イベントの一環として、新しいDNSKEYおよび/またはDS RR（単数または複数）を発行しました。
Emergency Trust Anchor Revocation: The operator of a signed zone wishes to indicate that the current DNSKEY and/or DS RR(s) are no longer valid as part of an exceptional event.
緊急トラストアンカー失効：署名されたゾーンのオペレータは、現在のDNSKEYおよび/またはDS RR（s）は、例外イベントの一部としてもはや有効でないことを示すことを望みます。
Following are the requirements for DNSSEC automated specification-based Trust Anchor Rollover:
DNSSEC自動化された仕様ベースのトラストアンカーのロールオーバーのための要件は次のとおりです。
The automated Trust Anchor Rollover solution MUST be capable of scaling to Internet-wide usage. The probable largest number of instances of security-aware resolvers needing to rollover a Trust Anchor will be those that use the public key(s) for the Root Zone as Trust Anchor(s). This number could be extremely large if a number of applications have embedded security-aware resolvers.
自動化されたトラストアンカーのロールオーバー・ソリューションは、インターネット全体の利用状況にスケーリングすることができなければなりません。トラストアンカーをロールオーバーする必要がセキュリティ対応リゾルバのインスタンスの最大の可能性の数は、トラストアンカー（S）としてルートゾーンの公開鍵を使用するものになります。アプリケーションの数は、セキュリティ対応リゾルバが埋め込まれている場合は、この数は非常に大きくなる可能性があります。
The automated Trust Anchor Rollover solution MUST be able to support Trust Anchors for multiple zones and multiple Trust Anchors for each DNS zone. The number of Trust Anchors that might be configured into any one validating security-aware resolver is not known with certainty at this time; in most cases it will be less than 20 but it may even be as high as one thousand.
自動化されたトラストアンカーのロールオーバー・ソリューションは、各DNSゾーンに対して複数のゾーンのトラストアンカーと、複数のトラストアンカーをサポートすることができなければなりません。セキュリティ対応リゾルバを検証いずれかに構成されるかもしれないトラストアンカーの数は、この時点では確実には知られていません。ほとんどの場合、それが20未満になりますが、それも千の高さであってもよいです。
Because trust anchor rollover is likely to be "mandatory-to-implement", section 8 of [5] requires that the technical solution chosen must not be known to be encumbered or must be available under royalty-free terms.
トラストアンカーのロールオーバーは、「実装に必須の」可能性があるので、[5]のセクション8は、選択された技術的な解決策を妨げされることが知られてはならないか、ロイヤリティフリーの条件の下で利用可能でなければならないことを要求しています。
For this purpose, "royalty-free" is defined as follows: worldwide, irrevocable, perpetual right to use, without fee, in commerce or otherwise, where "use" includes descriptions of algorithms, distribution and/or use of hardware implementations, distribution and/or use of software systems in source and/or binary form, in all DNS or DNSSEC applications including registry, registrar, domain name service including authority, recursion, caching, forwarding, stub resolver, or similar.
世界中で、「使用」はアルゴリズム、分布および/またはハードウェア実装の使用の説明、配布を含む使用する取消不能、永続的権利、手数料なしに、商業的にまたは他の方法を、以下のように、この目的のために、「無償」が定義されていますおよび/またはソースおよび/またはバイナリ形式で、権威、再帰、キャッシュ、転送、スタブリゾルバ、または類似含むレジストリ、レジストラ、ドメイン・ネーム・サービスを含むすべてのDNSやDNSSECアプリケーションにおけるソフトウェアシステムの使用。
In summary, no implementor, distributor, or operator of the technology chosen for trust anchor management shall be expected or required to pay any fee to any IPR holder for the right to implement, distribute, or operate a system which includes the chosen mandatory-to-implement solution.
要約すると、トラストアンカーの管理のために選択された技術のいかなる実装、ディストリビューター、またはオペレータが期待できない、または選択された必須の対を含むシステムを実装配布、又は運営する権利のために任意のIPRホルダに任意の料金を支払うために必要とされなければなりません-implementソリューション。
The solution MUST provide the capability to maintain Trust Anchors in security-aware resolvers for any and all DNS zones.
ソリューションは、任意およびすべてのDNSゾーンのセキュリティ対応リゾルバでトラストアンカーを維持するための機能を提供しなければなりません。
The solution MUST support private networks with their own DNS hierarchy.
ソリューションは、独自のDNS階層とプライベートネットワークをサポートしなければなりません。
The Trust Anchor Rollover solution MUST allow a validating security-aware resolver to be able to detect if the DNSKEY and/or DS RR(s) can no longer be updated given the current set of actual trust-anchors. In these cases, the resolver should inform the operator of the need to reestablish initial trust.
トラストアンカーロールオーバー溶液が検証セキュリティ対応リゾルバが検出できるように許可しなければならない場合DNSKEYおよび/またはDS RR（s）は、もはや実際の信頼アンカーの現在のセットを与えられていない更新することができます。これらのケースでは、リゾルバは最初の信頼を再確立する必要性をオペレータに通知する必要があります。
The operator of a security-aware resolver may choose manual or automated rollover, but the rollover protocol must allow the implementation to support both automated and manual Trust Anchor Maintenance operations. Implementation of the rollover protocol is likely to be mandatory, but that's out of scope for this requirements document.
セキュリティ対応リゾルバのオペレータは、手動または自動ロールオーバーを選ぶかもしれませんが、ロールオーバープロトコルが実装は、両方の自動および手動トラストアンカーのメンテナンス操作をサポートできるようにする必要があります。ロールオーバープロトコルの実装は必須である可能性が高いですが、それは、この要件ドキュメントの範囲外です。
The solution MUST permit both planned (pre-scheduled) and unplanned (non-scheduled) rollover of Trust Anchors. Support for providing an Initial Trust Relationship is OPTIONAL.
解決策は、トラストアンカーの両方の計画（事前にスケジュール）と計画されていない（非スケジュール）ロールオーバーを許可する必要があります。初期の信頼関係を提供するためのサポートはオプションです。
Resource Records used as Trust Anchors SHOULD be able to be distributed to security-aware resolvers in a timely manner.
トラストアンカーとして使用されるリソースレコードは、タイムリーにセキュリティ対応リゾルバに配布することができなければなりません。
Security-aware resolvers need to acquire new and remove revoked DNSKEY and/or DS RRs that are being used as Trust Anchors for a zone such that no old RR is used as a Trust Anchor for long after the zone issues new or revokes existing RRs.
セキュリティ対応リゾルバは、新たに取得し、ゾーンが新しい発行したり、既存のRRを取り消した後、何の古いRRが長いためトラストアンカーとして使用されていないようなゾーンのトラストアンカーとして使用されている取り消さDNSKEYおよび/またはDS RRを削除する必要があります。
Information about the zone administrator's view of the state of Resource Records used as Trust Anchors SHOULD be available in a trustworthy manner at all times to security-aware resolvers. Information about Resource Records that a zone administrator has invalidated and that are known to be used as Trust Anchors should be available in a trustworthy manner for a reasonable length of time.
トラストアンカーとして使用されるリソースレコードの状態のゾーン管理者のビューについての情報は、セキュリティ対応リゾルバにすべての回で信頼できる方法で利用可能であるべきです。ゾーン管理者が無効にしており、それがトラストアンカーとして使用されることが知られていることをリソースレコードに関する情報は、時間の合理的な長さのために信頼できる方法で利用可能であるべきです。
If a Trust Anchor Rollover solution requires new RR types or protocol modifications, this should be considered in the evaluation of solutions. The working group needs to determine whether such changes are a good thing or a bad thing or something else.
トラストアンカーロールオーバー溶液が新しいRRタイプまたはプロトコルの変更を必要とする場合、これは、溶液の評価において考慮されるべきです。ワーキンググループは、このような変化は良いことか悪いことか、何か他のものであるかどうかを決定する必要があります。
The Trust Anchor Rollover solution MUST support operations that allow a validating security-aware resolver to add a new Trust Anchor, delete an existing Trust Anchor, or replace an existing Trust Anchor with another.
トラストアンカーのロールオーバーソリューションは、検証セキュリティ対応リゾルバは、新しいトラストアンカーを追加し、既存のトラストアンカーを削除するか、別の既存のトラストアンカーを交換できるようにする操作をサポートしなければなりません。
The Trust Anchor Rollover solution MUST allow a security-aware resolver to be able to recover from the compromise of any of its configured Trust Anchors for a zone so long as at least one other key, which is known to have not been compromised, is configured as a Trust Anchor for that same zone at that resolver.
トラストアンカーロールオーバーソリューションは、セキュリティ対応リゾルバが損なわれていないことが知られているゾーン限り、少なくとも一つの他のキーのために構成されたトラストアンカーの任意の妥協から回復できるようにすることを可能にしなければならない、構成されていますそのリゾルバでその同じゾーンのトラストアンカーとして。
The Trust Anchor Rollover solution MUST provide sufficient means to ensure authenticity and integrity so that the existing trust relation does not degrade by performing the rollover.
トラストアンカーのロールオーバー・ソリューションは、既存の信頼関係がロールオーバーを行うことで、劣化しないように、信頼性と整合性を確保するための十分な手段を提供しなければなりません。
This document defines overall requirements for an automated specification-based Trust Anchor Rollover solution for security-aware resolvers but specifically does not define the security mechanisms needed to meet these requirements.
この文書では、セキュリティ対応リゾルバのための自動化された仕様ベースのトラストアンカーのロールオーバー・ソリューションの全体的な要件を定義していますが、特にこれらの要件を満たすために必要なセキュリティメカニズムを定義していません。
This document reflects the majority opinion of the DNSEXT Working Group members on the topic of requirements related to DNSSEC trust anchor rollover. The contributions made by various members of the working group to improve the readability and style of this document are graciously acknowledged.
この文書はDNSSECトラストアンカーのロールオーバーに関連する要件のトピックに関するDNSEXTワーキンググループのメンバーの過半数の意見を反映しています。この文書の読みやすさとスタイルを改善するために、ワーキンググループの様々なメンバーの貢献は丁重に認めています。
[1] Bradner, S., "Key Words for Use in RFCs to Indicate Requirement Levels", RFC 2119, March 1997.
[1]ブラドナーの、S.、 "要件レベルを示すためにRFCsにおける使用のためのキーワード"、RFC 2119、1997年3月を。
[2] Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose, "DNS Security Introduction and Requirements", RFC 4033, March 2005.
[2]アレンズ、R.、Austeinと、R.、ラーソン、M.、マッシー、D.、およびS.ローズ、 "DNSセキュリティ序論と要件"、RFC 4033、2005年3月。
[3] Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose, "Resource Records for the DNS Security Extensions", RFC 4034, March 2005.
[3]アレンズ、R.、Austeinと、R.、ラーソン、M.、マッシー、D.、およびS.ローズ、 "DNSセキュリティ拡張のためのリソースレコード"、RFC 4034、2005年3月。
[4] Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose, "Protocol Modifications for the DNS Security Extensions", RFC 4035, March 2005.
[4]アレンズ、R.、Austeinと、R.、ラーソン、M.、マッシー、D.、およびS.ローズ、 "DNSセキュリティ拡張のためのプロトコル変更"、RFC 4035、2005年3月。
[5] Bradner, S., "Intellectual Property Rights in IETF Technology", RFC 3979, March 2005.
[5]ブラドナーの、S.、 "IETF技術の知的財産権"、RFC 3979、2005年3月。
Authors' Addresses
著者のアドレス
Howard Eland Afilias Limited 300 Welsh Road Building 3, Suite 105 Horsham, PA 19044 USA
ハワードエランドAfilias限定300ウェルシュロードビル3、スイート105ホーシャム、PA 19044 USA
EMail: heland@afilias.info
メールアドレス：heland@afilias.info
Russ Mundy SPARTA, Inc. 7110 Samuel Morse Dr. Columbia, MD 21046 USA
ラス・マンディSPARTA、Inc.の7110サミュエル・モールス博士はコロンビア、MD 21046 USA
EMail: mundy@sparta.com
メールアドレス：mundy@sparta.com
Steve Crocker Shinkuro Inc. 1025 Vermont Ave, Suite 820 Washington, DC 20005 USA
スティーブクロッカーShinkuro株式会社1025バーモントアベニュー、スイート820ワシントンD.C. 20005 USA
EMail: steve@shinkuro.com
メールアドレス：steve@shinkuro.com
Suresh Krishnaswamy SPARTA, Inc. 7110 Samuel Morse Dr. Columbia, MD 21046 USA
スレシュKrishnaswamyスパルタ株式会社7110サミュエル・モールスDR。コロンビア、および21046 USA
EMail: suresh@sparta.com
メールアドレス：suresh@sparta.com
Full Copyright Statement
完全な著作権声明
Copyright (C) The IETF Trust (2007).
著作権（C）IETFトラスト（2007）。
This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights.
この文書では、BCP 78に含まれる権利と許可と制限の適用を受けており、その中の記載を除いて、作者は彼らのすべての権利を保有します。
This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
この文書とここに含まれている情報は、基礎とCONTRIBUTOR「そのまま」、ORGANIZATION HE / SHEが表すまたはインターネットSOCIETY、（もしあれば）を後援し、IETF TRUST ANDインターネットエンジニアリングタスクフォース放棄ALLに設けられています。保証は、明示または黙示、この情報の利用および特定目的に対する権利または商品性または適合性の黙示の保証を侵害しない任意の保証がこれらに限定されません。
Intellectual Property
知的財産
The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79.
IETFは、本書またはそのような権限下で、ライセンスがたりないかもしれない程度に記載された技術の実装や使用に関係すると主張される可能性があります任意の知的財産権やその他の権利の有効性または範囲に関していかなる位置を取りません利用可能です。またそれは、それがどのような権利を確認する独自の取り組みを行ったことを示すものでもありません。 RFC文書の権利に関する手続きの情報は、BCP 78およびBCP 79に記載されています。
Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.
IPRの開示のコピーが利用できるようにIETF事務局とライセンスの保証に行われた、または本仕様の実装者または利用者がそのような所有権の使用のための一般的なライセンスまたは許可を取得するために作られた試みの結果を得ることができますhttp://www.ietf.org/iprのIETFのオンラインIPRリポジトリから。
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org.
IETFは、その注意にこの標準を実装するために必要とされる技術をカバーすることができる任意の著作権、特許または特許出願、またはその他の所有権を持ってすべての利害関係者を招待します。 ietf-ipr@ietf.orgのIETFに情報を記述してください。