[要約] RFC 4986は、DNSセキュリティ（DNSSEC）トラストアンカーロールオーバーに関連する要件を定義しています。その目的は、DNSSECの信頼アンカーの更新プロセスを安全かつ効果的に実施するためのガイドラインを提供することです。
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.
[2]、[3]、および[4]で説明されているドメイン名システムセキュリティ拡張機能（DNSSEC）は、セキュリティ対応リゾルバーがDNSリソースレコード（RRS）を1つから検証できるようにする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].
「必須」、「そうしない」、「必須」、「shall」、「shall "、" ingle "、" should "、" not "、" becommended "、" bay "、および「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言語の要件は、必要、または推奨言語の要件よりも優先されます。両方とも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 DNSKEY RRs or DS RRs as their starting point. Each of these starting points is called a Trust Anchor.
DNSリゾルバーには、DNS回答の取得に使用する1つ以上の出発点が必要です。スタブリゾルバーの出発点は、通常、1つ以上の再帰名サーバーのIPアドレスです。再帰名サーバーの出発点は、通常、DNSルート名サーバーのIPアドレスです。同様に、セキュリティ対応のリゾルバーには、署名されたDNS応答を検証するために、認証されたチェーンを構築するために使用する1つ以上の出発点が必要です。IPアドレスの代わりに、DNSSECでは、各リゾルバーが1つ以上のDNSKEY RRSまたはDS RRSを出発点として信頼することを要求しています。これらの各出発点は、信頼アンカーと呼ばれます。
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 RRSおよびDS RRSは、署名ゾーンオペレーターによって作成された場合、レコードが署名ゾーンで公開されているため、アンカーを信頼する場合でも、信頼できるアンカーではないことに注意してください。DNSKEY RRまたはDS RRは、セキュリティ認識リゾルバーのオペレーターが公開キーまたはハッシュが信頼アンカーとして使用されると判断した場合、信頼アンカーになります。したがって、これらのRRSを作成および/または公開した署名ゾーンオペレーターは、ゾーンに関連付けられたDNSKEY RRSまたはDS RRのいずれかがセキュリティ対応リゾルバーによって信頼アンカーとして使用されているかどうかを知らない場合があります。明らかな例外は、ルートゾーンのDNSKEY RRSです。これは、多くのセキュリティ対応のリゾルバーによって信頼のアンカーとして使用されます。さまざまな理由で、ルート以外のゾーンからのDNSKEY RRSまたはDS RRSは、セキュリティ認識リゾルバーのオペレーターがトラストアンカーとして使用できます。責任は、セキュリティ対応のリゾルバーのオペレーターにあることに続き、セキュリティアンカーとして使用することを選択したDNSKEYおよび/またはDS RRSが、セキュリティ対応のローバーが出発点として使用しているときに有効であることを保証します。認証チェーンを構築して、署名された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を使用していることを確認するために使用する方法を決定する必要があり、RRSが信頼アンカーとして使用される必要があることを決定できることを確認する必要があります。交換または削除。DNS署名ゾーンの早期採用者は、DNSKEYおよび/またはDS RRSが変更されたときに使用するプロセスと方法に関する情報を公開しているため、セキュリティ認識リゾルバーのオペレーターが適切な時期にトラストアンカーを手動で変更できます。この手動アプローチは拡大せず、したがって、セキュリティ対応のリゾルバーのための信頼アンカーのロールオーバーのための自動仕様ベースのアプローチの必要性を促進します。
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またはDS RRハッシュのDNSKEY RR。さらに、DNSKEY RRまたはDS RRは、DNS階層、つまり1つのDNSゾーンの正確な1つのポイントに関連付けられています。複数の信頼アンカーは、各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の正しさは、オペレーターがルートトラストアンカーであると考えているものを、IANA Webサイトなどのいくつかの「よく知られている」ソースである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を伝えるために使用される方法または方法。メソッドまたは方法は、セキュリティ認識リゾルバーのオペレーターによって十分に信頼できるとみなされなければなりません。これは、これらの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をセキュリティ対応するリゾルバーの両方に明確にする必要があります。
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.
信頼アンカーロールオーバー：セキュリティ認識リゾルバーが保持している1つまたは複数のトラストアンカーを安全に交換するために必要な方法または方法。トラストアンカーロールオーバーは、トラストアンカーメンテナンスのサブセットと見なされる必要があります。
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.
Emergency Trust Anchorの取り消し：署名ゾーンのオペレーターは、現在のDNSKEYおよび/またはDS RRが例外的なイベントの一部としてもはや有効ではないことを示したいと考えています。
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.
自動化されたトラストアンカーロールオーバーソリューションは、インターネット全体の使用法に合わせてスケーリングできる必要があります。信頼のアンカーをロールオーバーする必要があるセキュリティ対応のリゾルバーの可能性が高いインスタンスの数は、ルートゾーンにトラストアンカーとして公開キーを使用するものです。多くのアプリケーションがセキュリティ認識リゾルバーが組み込まれている場合、この数は非常に大きくなる可能性があります。
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歳未満になりますが、1000個も高くなることさえあります。
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.
Trust Anchorロールオーバーは「補完することを強制」する可能性が高いため、[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.
この目的のために、「ロイヤリティフリー」は次のように定義されます。世界中で、取消不能、使用権、料金なし、商取引などで、「使用」にはアルゴリズム、分布、および/またはハードウェアの実装の使用、分布の説明が含まれます。ソースおよび/またはバイナリ形式でのソフトウェアシステムの使用、レジストリ、レジストラ、権限、再帰、キャッシュ、転送、スタブリゾルバーなどを含むドメイン名サービスなどのドメイン名サービスを含む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所有者に料金を支払う必要がありません。 - 実装ソリューション。
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.
Trust Anchorロールオーバーソリューションは、検証済みのセキュリティ対応リゾルバーを、現在の実際の信託アンカーのセットを考慮して、DNSKEYおよび/またはDS RRを更新できなくなったかどうかを検出できるようにする必要があります。これらの場合、リゾルバーは、最初の信頼を再確立する必要性をオペレーターに通知する必要があります。
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.
セキュリティ対応のリゾルバーは、新規を取得し、ゾーンが既存のRRSを発行した後も長い間古い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.
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.
Trust Anchorロールオーバーソリューションは、検証済みのセキュリティ対応リゾルバーが新しいトラストアンカーを追加したり、既存の信頼アンカーを削除したり、既存のトラストアンカーを別の信頼アンカーに置き換えることを可能にする操作をサポートする必要があります。
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.
Trust Anchorロールオーバーソリューションは、セキュリティ対応のリゾルバーが、妥協していないことが知られている他のキーが少なくとも1つあることがわかっている限り、ゾーンの構成された信頼アンカーの妥協から回復できるようにする必要があります。そのリゾルバーの同じゾーンの信頼のアンカーとして。
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] Bradner、S。、「要件レベルを示すためのRFCで使用するためのキーワード」、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]
[3] Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose, "Resource Records for the DNS Security Extensions", RFC 4034, March 2005.
[3] Arends、R.、Austein、R.、Larson、M.、Massey、D。、およびS. Rose、「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] Arends、R.、Austein、R.、Larson、M.、Massey、D。、およびS. Rose、「DNSセキュリティ拡張機能のプロトコル変更」、RFC 4035、2005年3月。
[5] Bradner, S., "Intellectual Property Rights in IETF Technology", RFC 3979, March 2005.
[5] Bradner、S。、「IETFテクノロジーの知的財産権」、RFC 3979、2005年3月。
Authors' Addresses
著者のアドレス
Howard Eland Afilias Limited 300 Welsh Road Building 3, Suite 105 Horsham, PA 19044 USA
ハワード・エランド・アフィリア・リミテッド300ウェールズ・ロード・ビル3、スイート105ホーシャム、ペンシルベニア州19044アメリカ
EMail: heland@afilias.info
Russ Mundy SPARTA, Inc. 7110 Samuel Morse Dr. Columbia, MD 21046 USA
Russ Mundy Sparta、Inc。7110 Samuel Morse Dr. Columbia、MD 21046 USA
EMail: mundy@sparta.com
Steve Crocker Shinkuro Inc. 1025 Vermont Ave, Suite 820 Washington, DC 20005 USA
Steve Crocker Shinkuro Inc. 1025 Vermont Ave、Suite 820 Washington、DC 20005 USA
EMail: steve@shinkuro.com
Suresh Krishnaswamy SPARTA, Inc. 7110 Samuel Morse Dr. Columbia, MD 21046 USA
Suresh Krishnaswamy Sparta、Inc。7110 Samuel Morse Dr. Columbia、MD 21046 USA
EMail: suresh@sparta.com
Full Copyright Statement
完全な著作権声明
Copyright (C) The IETF Trust (2007).
著作権（c）The IETF Trust（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.
このドキュメントとここに含まれる情報は、「現状のまま」に基づいて提供され、貢献者、彼/彼女が代表する組織（もしあれば）、インターネット協会、IETFトラスト、インターネットエンジニアリングタスクフォースがすべてを否認します。明示的または黙示的な保証。ここでの情報の使用は、特定の目的に対する商品性または適合性の権利または暗黙の保証を侵害しないという保証を含むがこれらに限定されない。
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.
IETF事務局に行われたIPR開示のコピーと、利用可能にするライセンスの保証、またはこの仕様の実装者またはユーザーによるそのような独自の権利の使用のための一般的なライセンスまたは許可を取得しようとする試みの結果を取得できます。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への情報をお問い合わせください。