[要約] RFC 4641は、DNSSECの運用上の実践に関するガイドラインであり、DNSセキュリティ拡張の実装と運用に関する情報を提供します。このRFCの目的は、DNSSECの適切な運用手順を定義し、セキュリティの向上と信頼性の確保を支援することです。
Network Working Group O. Kolkman
Request for Comments: 4641 R. Gieben
Obsoletes: 2541 NLnet Labs
Category: Informational September 2006
DNSSEC Operational Practices
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.
このメモは、インターネットコミュニティに情報を提供します。いかなる種類のインターネット標準を指定しません。このメモの配布は無制限です。
Copyright Notice
著作権表示
Copyright (C) The Internet Society (2006).
Copyright（c）The Internet Society（2006）。
Abstract
概要
This document describes a set of practices for operating the DNS with security extensions (DNSSEC). The target audience is zone administrators deploying DNSSEC.
このドキュメントでは、セキュリティ拡張機能（DNSSEC）でDNSを操作するための一連のプラクティスについて説明します。ターゲットオーディエンスは、DNSSECを展開するゾーン管理者です。
The document discusses operational aspects of using keys and signatures in the DNS. It discusses issues of key generation, key storage, signature generation, key rollover, and related policies.
このドキュメントでは、DNSでキーと署名を使用することの運用上の側面について説明します。キー生成、キーストレージ、署名生成、キーロールオーバー、および関連するポリシーの問題について説明します。
This document obsoletes RFC 2541, as it covers more operational ground and gives more up-to-date requirements with respect to key sizes and the new DNSSEC specification.
このドキュメントは、RFC 2541を廃止します。これは、より多くの運用上の根拠をカバーし、キーサイズと新しいDNSSEC仕様に関してより多くの最新の要件を提供します。
Table of Contents
目次
1. Introduction ....................................................3
1.1. The Use of the Term 'key' ..................................4
1.2. Time Definitions ...........................................4
2. Keeping the Chain of Trust Intact ...............................5
3. Keys Generation and Storage .....................................6
3.1. Zone and Key Signing Keys ..................................6
3.1.1. Motivations for the KSK and ZSK Separation ..........6
3.1.2. KSKs for High-Level Zones ...........................7
3.2. Key Generation .............................................8
3.3. Key Effectivity Period .....................................8
3.4. Key Algorithm ..............................................9
3.5. Key Sizes ..................................................9
3.6. Private Key Storage .......................................11
4. Signature Generation, Key Rollover, and Related Policies .......12
4.1. Time in DNSSEC ............................................12
4.1.1. Time Considerations ................................12
4.2. Key Rollovers .............................................14
4.2.1. Zone Signing Key Rollovers .........................14
4.2.1.1. Pre-Publish Key Rollover ..................15
4.2.1.2. Double Signature Zone Signing Key
Rollover ..................................17
4.2.1.3. Pros and Cons of the Schemes ..............18
4.2.2. Key Signing Key Rollovers ..........................18
4.2.3. Difference Between ZSK and KSK Rollovers ...........20
4.2.4. Automated Key Rollovers ............................21
4.3. Planning for Emergency Key Rollover .......................21
4.3.1. KSK Compromise .....................................22
4.3.1.1. Keeping the Chain of Trust Intact .........22
4.3.1.2. Breaking the Chain of Trust ...............23
4.3.2. ZSK Compromise .....................................23
4.3.3. Compromises of Keys Anchored in Resolvers ..........24
4.4. Parental Policies .........................................24
4.4.1. Initial Key Exchanges and Parental Policies
Considerations .....................................24
4.4.2. Storing Keys or Hashes? ............................25
4.4.3. Security Lameness ..................................25
4.4.4. DS Signature Validity Period .......................26
5. Security Considerations ........................................26
6. Acknowledgments ................................................26
7. References .....................................................27
7.1. Normative References ......................................27
7.2. Informative References ....................................28
Appendix A. Terminology ...........................................30
Appendix B. Zone Signing Key Rollover How-To ......................31
Appendix C. Typographic Conventions ...............................32
This document describes how to run a DNS Security (DNSSEC)-enabled environment. It is intended for operators who have knowledge of the DNS (see RFC 1034 [1] and RFC 1035 [2]) and want to deploy DNSSEC. See RFC 4033 [4] for an introduction to DNSSEC, RFC 4034 [5] for the newly introduced Resource Records (RRs), and RFC 4035 [6] for the protocol changes.
このドキュメントでは、DNSセキュリティ（DNSSEC）対応環境の実行方法について説明します。DNSの知識を持つオペレーター（RFC 1034 [1]およびRFC 1035 [2]を参照）を対象としており、DNSSECを展開したいと考えています。DNSSECの紹介については、新しく導入されたリソースレコード（RRS）についてはRFC 4034 [5]、およびプロトコルの変更についてはRFC 4035 [6]については、RFC 4033 [4]を参照してください。
During workshops and early operational deployment tests, operators and system administrators have gained experience about operating the DNS with security extensions (DNSSEC). This document translates these experiences into a set of practices for zone administrators. At the time of writing, there exists very little experience with DNSSEC in production environments; this document should therefore explicitly not be seen as representing 'Best Current Practices'.
ワークショップと早期の運用展開テスト中、オペレーターとシステム管理者は、セキュリティ拡張機能（DNSSEC）でDNSの運用に関する経験を積んでいます。このドキュメントは、これらのエクスペリエンスをゾーン管理者の一連のプラクティスに変換します。執筆時点では、生産環境でDNSSECの経験はほとんど存在しません。したがって、このドキュメントは、明示的に「最良の現在の慣行」を表すものと見なされるべきではありません。
The procedures herein are focused on the maintenance of signed zones (i.e., signing and publishing zones on authoritative servers). It is intended that maintenance of zones such as re-signing or key rollovers be transparent to any verifying clients on the Internet.
ここでの手順は、署名ゾーンのメンテナンスに焦点を当てています（つまり、権威あるサーバーでゾーンの署名と公開）。再署名やキーロールオーバーなどのゾーンのメンテナンスは、インターネット上の検証クライアントに対して透明性があることを意図しています。
The structure of this document is as follows. In Section 2, we discuss the importance of keeping the "chain of trust" intact. Aspects of key generation and storage of private keys are discussed in Section 3; the focus in this section is mainly on the private part of the key(s). Section 4 describes considerations concerning the public part of the keys. Since these public keys appear in the DNS one has to take into account all kinds of timing issues, which are discussed in Section 4.1. Section 4.2 and Section 4.3 deal with the rollover, or supercession, of keys. Finally, Section 4.4 discusses considerations on how parents deal with their children's public keys in order to maintain chains of trust.
このドキュメントの構造は次のとおりです。セクション2では、「信頼の連鎖」をそのまま維持することの重要性について説明します。プライベートキーのキー生成とストレージの側面については、セクション3で説明します。このセクションの焦点は、主にキーのプライベート部分にあります。セクション4では、キーの公開部分に関する考慮事項について説明します。これらのパブリックキーはDNSに表示されるため、セクション4.1で説明するあらゆる種類のタイミングの問題を考慮する必要があります。セクション4.2およびセクション4.3は、キーのロールオーバーまたはスーパーセッションを扱います。最後に、セクション4.4では、信頼の鎖を維持するために、親が子供の公開鍵にどのように対処するかについての考慮事項について説明します。
The typographic conventions used in this document are explained in Appendix C.
このドキュメントで使用されている誤字の規則については、付録Cで説明しています。
Since this is a document with operational suggestions and there are no protocol specifications, the RFC 2119 [7] language does not apply.
これは運用上の提案を含むドキュメントであり、プロトコル仕様がないため、RFC 2119 [7]言語は適用されません。
This document obsoletes RFC 2541 [12] to reflect the evolution of the underlying DNSSEC protocol since then. Changes in the choice of cryptographic algorithms, DNS record types and type names, and the parent-child key and signature exchange demanded a major rewrite and additional information and explanation.
このドキュメントは、RFC 2541 [12]を廃止し、それ以降の基礎となるDNSSECプロトコルの進化を反映しています。暗号化アルゴリズム、DNSの記録タイプとタイプ名の選択の変更、および親子のキーと署名の交換には、主要な書き直しと追加情報と説明が要求されました。
It is assumed that the reader is familiar with the concept of asymmetric keys on which DNSSEC is based (public key cryptography [17]). Therefore, this document will use the term 'key' rather loosely. Where it is written that 'a key is used to sign data' it is assumed that the reader understands that it is the private part of the key pair that is used for signing. It is also assumed that the reader understands that the public part of the key pair is published in the DNSKEY Resource Record and that it is the public part that is used in key exchanges.
読者は、DNSSECが基づいている非対称キーの概念に精通していると想定されています（公開キー暗号[17]）。したがって、このドキュメントは、「キー」という用語をかなりゆるく使用します。「キーがデータに署名するために使用される」と書かれている場合、署名に使用されるのはキーペアのプライベート部分であると読者が理解していると想定されています。また、読者は、キーペアの公開部分がDNSKEYリソースレコードに掲載されていること、およびキー交換で使用されるのは公開部分であることを理解していると想定されています。
In this document, we will be using a number of time-related terms. The following definitions apply:
このドキュメントでは、多くの時間関連用語を使用します。次の定義が適用されます。
o "Signature validity period" The period that a signature is valid. It starts at the time specified in the signature inception field of the RRSIG RR and ends at the time specified in the expiration field of the RRSIG RR.
o 「署名の妥当性期間」署名が有効な期間。RRSIG RRの署名インセプションフィールドで指定された時刻から始まり、RRSIG RRの有効期限フィールドで指定された時間で終了します。
o "Signature publication period" Time after which a signature (made with a specific key) is replaced with a new signature (made with the same key). This replacement takes place by publishing the relevant RRSIG in the master zone file. After one stops publishing an RRSIG in a zone, it may take a while before the RRSIG has expired from caches and has actually been removed from the DNS.
o 「署名の公開期間」時間（特定のキーで作られた署名）が新しい署名（同じキーで作られた）に置き換えられます。この交換は、マスターゾーンファイルに関連するRRSIGを公開することで行われます。ゾーンでRRSIGを公開するのをやめた後、RRSIGがキャッシュから期限切れになり、実際にDNSから削除されるまでに時間がかかる場合があります。
o "Key effectivity period" The period during which a key pair is expected to be effective. This period is defined as the time between the first inception time stamp and the last expiration date of any signature made with this key, regardless of any discontinuity in the use of the key. The key effectivity period can span multiple signature validity periods.
o 「主要な効果期間」キーペアが効果的であると予想される期間。この期間は、キーの使用の不連続性に関係なく、このキーで行われた署名の最初のインセプションタイムスタンプと最後の有効期限の間の時間として定義されます。主要な効果期間は、複数の署名の妥当性期間にまたがる可能性があります。
o "Maximum/Minimum Zone Time to Live (TTL)" The maximum or minimum value of the TTLs from the complete set of RRs in a zone. Note that the minimum TTL is not the same as the MINIMUM field in the SOA RR. See [11] for more information.
o ゾーン内のRRの完全なセットからのTTLの最大値または最小値は、「最大/最小ゾーン時間（TTL）」です。最小TTLは、SOA RRの最小フィールドと同じではないことに注意してください。詳細については、[11]を参照してください。
Maintaining a valid chain of trust is important because broken chains of trust will result in data being marked as Bogus (as defined in [4] Section 5), which may cause entire (sub)domains to become invisible to verifying clients. The administrators of secured zones have to realize that their zone is, to verifying clients, part of a chain of trust.
信頼の壊れたチェーンチェーンが偽物（[4]セクション5で定義されているように）としてマークされ、（サブ）ドメイン全体がクライアントの検証に見えないようになる可能性があるため、有効な信頼の連鎖を維持することが重要です。セキュリティで保護されたゾーンの管理者は、彼らのゾーンがクライアントを検証することであり、信頼の連鎖の一部であることを認識する必要があります。
As mentioned in the introduction, the procedures herein are intended to ensure that maintenance of zones, such as re-signing or key rollovers, will be transparent to the verifying clients on the Internet.
導入部で述べたように、本書の手順は、再署名やキーロールオーバーなどのゾーンのメンテナンスがインターネット上の検証クライアントに対して透明になることを保証することを目的としています。
Administrators of secured zones will have to keep in mind that data published on an authoritative primary server will not be immediately seen by verifying clients; it may take some time for the data to be transferred to other secondary authoritative nameservers and clients may be fetching data from caching non-authoritative servers. In this light, note that the time for a zone transfer from master to slave is negligible when using NOTIFY [9] and incremental transfer (IXFR) [8]. It increases when full zone transfers (AXFR) are used in combination with NOTIFY. It increases even more if you rely on full zone transfers based on only the SOA timing parameters for refresh.
保護されたゾーンの管理者は、信頼できるプライマリサーバーで公開されたデータは、クライアントを確認することによってすぐには見えないことに留意する必要があります。データが他の二次権威ある名前アーバーに転送されるまでには時間がかかる場合があり、クライアントはキャッシュされていない非承認サーバーからデータを取得している場合があります。この観点から、Notify [9]および増分転送（IXFR）[8]を使用する場合、マスターからスレーブへのゾーン転送の時間はごくわずかであることに注意してください。フルゾーン転送（AXFR）がNotifyと組み合わせて使用されると増加します。更新用のSOAタイミングパラメーターのみに基づいてフルゾーン転送に依存すると、さらに増加します。
For the verifying clients, it is important that data from secured zones can be used to build chains of trust regardless of whether the data came directly from an authoritative server, a caching nameserver, or some middle box. Only by carefully using the available timing parameters can a zone administrator ensure that the data necessary for verification can be obtained.
検証するクライアントの場合、保護されたゾーンからのデータを使用して、データが権威あるサーバー、キャッシングネームサーバー、または中間ボックスから直接送られたかどうかに関係なく、信頼のチェーンを構築できることが重要です。利用可能なタイミングパラメーターを慎重に使用することによってのみ、ゾーン管理者は、検証に必要なデータを取得できることを確認できます。
The responsibility for maintaining the chain of trust is shared by administrators of secured zones in the chain of trust. This is most obvious in the case of a 'key compromise' when a trade-off between maintaining a valid chain of trust and replacing the compromised keys as soon as possible must be made. Then zone administrators will have to make a trade-off, between keeping the chain of trust intact -- thereby allowing for attacks with the compromised key -- or deliberately breaking the chain of trust and making secured subdomains invisible to security-aware resolvers. Also see Section 4.3.
信頼のチェーンを維持する責任は、信頼のチェーンにおける担保付きゾーンの管理者によって共有されます。これは、有効な信頼チェーンを維持し、妥協したキーをできるだけ早く置き換えることとのトレードオフをできるだけ早く行う必要がある場合に、「重要な妥協」の場合に最も明白です。その後、ゾーン管理者は、信頼のチェーンを無傷に保つことと、それによって侵害されたキーで攻撃を可能にすることと、意図的に信頼のチェーンを破壊することと、セキュリティ対応のリゾルバーに秘密のサブドメインを不可表示にすることとのトレードオフを行う必要があります。セクション4.3も参照してください。
This section describes a number of considerations with respect to the security of keys. It deals with the generation, effectivity period, size, and storage of private keys.
このセクションでは、キーのセキュリティに関する多くの考慮事項について説明します。プライベートキーの生成、有効期間、サイズ、および保管を扱います。
The DNSSEC validation protocol does not distinguish between different types of DNSKEYs. All DNSKEYs can be used during the validation. In practice, operators use Key Signing and Zone Signing Keys and use the so-called Secure Entry Point (SEP) [3] flag to distinguish between them during operations. The dynamics and considerations are discussed below.
To make zone re-signing and key rollover procedures easier to implement, it is possible to use one or more keys as Key Signing Keys (KSKs). These keys will only sign the apex DNSKEY RRSet in a zone. Other keys can be used to sign all the RRSets in a zone and are referred to as Zone Signing Keys (ZSKs). In this document, we assume that KSKs are the subset of keys that are used for key exchanges with the parent and potentially for configuration as trusted anchors -- the SEP keys. In this document, we assume a one-to-one mapping between KSK and SEP keys and we assume the SEP flag to be set on all KSKs.
ゾーンの再署名とキーロールオーバー手順を実装しやすくするために、1つ以上のキーをキー署名キー（KSK）として使用することができます。これらのキーは、ゾーン内のapex dnskey rrsetのみに署名します。他のキーを使用して、ゾーン内のすべてのrrsetsに署名し、ゾーン署名キー（zsks）と呼ばれます。このドキュメントでは、KSKSは、親とのキー交換に使用され、潜在的に信頼できるアンカーとしての構成に使用されるキーのサブセットであると仮定します。このドキュメントでは、KSKとSEPキーの間の1対1のマッピングを想定しており、SEPフラグがすべてのKSKに設定されると仮定します。
Differentiating between the KSK and ZSK functions has several advantages:
KSK機能とZSK関数を区別するには、いくつかの利点があります。
o No parent/child interaction is required when ZSKs are updated.
o ZSKを更新する場合、親/子の相互作用は必要ありません。
o The KSK can be made stronger (i.e., using more bits in the key material). This has little operational impact since it is only used to sign a small fraction of the zone data. Also, the KSK is only used to verify the zone's key set, not for other RRSets in the zone.
o KSKはより強くすることができます（つまり、キーマテリアルでより多くのビットを使用します）。ゾーンデータのごく一部に署名するためにのみ使用されるため、これはほとんど動作的な影響を与えません。また、KSKは、ゾーン内の他のrrsetではなく、ゾーンのキーセットの検証にのみ使用されます。
o As the KSK is only used to sign a key set, which is most probably updated less frequently than other data in the zone, it can be stored separately from and in a safer location than the ZSK.
o KSKはキーセットに署名するためにのみ使用されるため、おそらくゾーン内の他のデータよりも頻繁に更新されない可能性が高いため、ZSKとは別に安全な場所に保存できます。
o A KSK can have a longer key effectivity period.
o KSKは、より長いキー効果期間を持つことができます。
For almost any method of key management and zone signing, the KSK is used less frequently than the ZSK. Once a key set is signed with the KSK, all the keys in the key set can be used as ZSKs. If a ZSK is compromised, it can be simply dropped from the key set. The new key set is then re-signed with the KSK.
主要な管理とゾーンの署名のほぼすべての方法で、KSKはZSKよりも使用されなくなります。キーセットがKSKで署名されると、キーセットのすべてのキーをZSKとして使用できます。ZSKが侵害された場合、キーセットから単純に削除できます。新しいキーセットは、KSKに再署名されます。
Given the assumption that for KSKs the SEP flag is set, the KSK can be distinguished from a ZSK by examining the flag field in the DNSKEY RR. If the flag field is an odd number it is a KSK. If it is an even number it is a ZSK.
KSKのSEPフラグが設定されているという仮定を考えると、DNSKEY RRのフラグフィールドを調べることにより、KSKをZSKと区別できます。フラグフィールドが奇数の場合、それはKSKです。偶数の場合はZSKです。
The Zone Signing Key can be used to sign all the data in a zone on a regular basis. When a Zone Signing Key is to be rolled, no interaction with the parent is needed. This allows for signature validity periods on the order of days.
ゾーン署名キーを使用して、定期的にすべてのデータに署名できます。ゾーン署名キーをロールする場合、親との相互作用は必要ありません。これにより、日数の署名の妥当性期間が可能になります。
The Key Signing Key is only to be used to sign the DNSKEY RRs in a zone. If a Key Signing Key is to be rolled over, there will be interactions with parties other than the zone administrator. These can include the registry of the parent zone or administrators of verifying resolvers that have the particular key configured as secure entry points. Hence, the key effectivity period of these keys can and should be made much longer. Although, given a long enough key, the key effectivity period can be on the order of years, we suggest planning for a key effectivity on the order of a few months so that a key rollover remains an operational routine.
キー署名キーは、ゾーン内のDNSKEY RRSに署名するためにのみ使用されることです。キー署名キーがロールオーバーすることである場合、ゾーン管理者以外の当事者とのやり取りがあります。これらには、親ゾーンのレジストリまたは特定のキーを安全なエントリポイントとして構成しているリゾルバーを検証する管理者を含めることができます。したがって、これらのキーの重要な効果期間は、はるかに長くすることができます。十分に長いキーを考えると、重要な効果の期間は数年の順序である可能性がありますが、キーロールオーバーが運用ルーチンのままであるように、数ヶ月の順序でキー効果を計画することをお勧めします。
Higher-level zones are generally more sensitive than lower-level zones. Anyone controlling or breaking the security of a zone thereby obtains authority over all of its subdomains (except in the case of resolvers that have locally configured the public key of a subdomain, in which case this, and only this, subdomain wouldn't be affected by the compromise of the parent zone). Therefore, extra care should be taken with high-level zones, and strong keys should be used.
一般に、高レベルのゾーンは低レベルのゾーンよりも感度が高くなります。それにより、ゾーンのセキュリティを制御または破壊する人は、そのすべてのサブドメインに対する権限を取得します（サブドメインの公開鍵をローカルに構成したリゾルバーの場合を除き、この場合、これのみ、サブドメインは影響を受けません親ゾーンの妥協によって）。したがって、高レベルのゾーンでは特別な注意を払う必要があり、強力なキーを使用する必要があります。
The root zone is the most critical of all zones. Someone controlling or compromising the security of the root zone would control the entire DNS namespace of all resolvers using that root zone (except in the case of resolvers that have locally configured the public key of a subdomain). Therefore, the utmost care must be taken in the securing of the root zone. The strongest and most carefully handled keys should be used. The root zone private key should always be kept off-line.
Many resolvers will start at a root server for their access to and authentication of DNS data. Securely updating the trust anchors in an enormous population of resolvers around the world will be extremely difficult.
Careful generation of all keys is a sometimes overlooked but absolutely essential element in any cryptographically secure system. The strongest algorithms used with the longest keys are still of no use if an adversary can guess enough to lower the size of the likely key space so that it can be exhaustively searched. Technical suggestions for the generation of random keys will be found in RFC 4086 [14]. One should carefully assess if the random number generator used during key generation adheres to these suggestions.
すべてのキーを慎重に生成することは、暗号化されたシステムで見落とされがちですが絶対に不可欠な要素です。最長のキーで使用される最も強力なアルゴリズムは、敵が可能性のあるキー空間のサイズを縮小して徹底的に検索できるように十分に推測できる場合でも、まだ役に立ちません。ランダムキーの生成に関する技術的な提案は、RFC 4086 [14]にあります。キー生成中に使用される乱数ジェネレーターがこれらの提案を順守するかどうかを慎重に評価する必要があります。
Keys with a long effectivity period are particularly sensitive as they will represent a more valuable target and be subject to attack for a longer time than short-period keys. It is strongly recommended that long-term key generation occur off-line in a manner isolated from the network via an air gap or, at a minimum, high-level secure hardware.
長い有効期間のキーは、より価値のあるターゲットを表し、短期キーよりも長い時間攻撃を受ける可能性があるため、特に敏感です。長期的なキー生成は、エアギャップを介してネットワークから分離された方法または少なくとも高レベルの安全なハードウェアを介してオフラインで発生することを強くお勧めします。
For various reasons, keys in DNSSEC need to be changed once in a while. The longer a key is in use, the greater the probability that it will have been compromised through carelessness, accident, espionage, or cryptanalysis. Furthermore, when key rollovers are too rare an event, they will not become part of the operational habit and there is risk that nobody on-site will remember the procedure for rollover when the need is there.
さまざまな理由で、DNSSECのキーを時々変更する必要があります。キーが長く使用されているほど、不注意、事故、スパイ、または暗号化によって侵害される可能性が高くなります。さらに、キーロールオーバーがイベントがあまりにもまれである場合、それらは運用習慣の一部にならず、必要なときに現場で誰もロールオーバーの手順を覚えていないというリスクがあります。
From a purely operational perspective, a reasonable key effectivity period for Key Signing Keys is 13 months, with the intent to replace them after 12 months. An intended key effectivity period of a month is reasonable for Zone Signing Keys.
For key sizes that match these effectivity periods, see Section 3.5.
As argued in Section 3.1.2, securely updating trust anchors will be extremely difficult. On the other hand, the "operational habit" argument does also apply to trust anchor reconfiguration. If a short key effectivity period is used and the trust anchor configuration has to be revisited on a regular basis, the odds that the configuration tends to be forgotten is smaller. The trade-off is against a system that is so dynamic that administrators of the validating clients will not be able to follow the modifications.
セクション3.1.2で議論されているように、信頼のアンカーを安全に更新することは非常に困難です。一方、「運用習慣」の議論は、信頼のアンカー再構成にも適用されます。短いキー効果期間が使用され、トラストアンカー構成を定期的に再検討する必要がある場合、構成が忘れられる傾向があるオッズは小さくなります。トレードオフは、非常に動的なシステムに反しているため、検証済みのクライアントの管理者は変更に従うことができません。
Key effectivity periods can be made very short, as in a few minutes. But when replacing keys one has to take the considerations from Section 4.1 and Section 4.2 into account.
数分のように、主要な効果期間は非常に短くすることができます。ただし、キーを交換する場合は、セクション4.1とセクション4.2の考慮事項を考慮する必要があります。
There are currently three different types of algorithms that can be used in DNSSEC: RSA, DSA, and elliptic curve cryptography. The latter is fairly new and has yet to be standardized for usage in DNSSEC.
現在、DNSSECで使用できる3つの異なるタイプのアルゴリズムがあります：RSA、DSA、および楕円曲線暗号化。後者はかなり新しく、DNSSECでの使用のためにまだ標準化されていません。
RSA has been developed in an open and transparent manner. As the patent on RSA expired in 2000, its use is now also free.
RSAは、オープンで透明な方法で開発されています。2000年にRSAの特許が期限切れになったため、その使用も無料になりました。
DSA has been developed by the National Institute of Standards and Technology (NIST). The creation of signatures takes roughly the same time as with RSA, but is 10 to 40 times as slow for verification [17].
DSAは、国立標準技術研究所（NIST）によって開発されました。署名の作成には、RSAとほぼ同じ時間がかかりますが、検証のために10〜40倍遅いです[17]。
We suggest the use of RSA/SHA-1 as the preferred algorithm for the key. The current known attacks on RSA can be defeated by making your key longer. As the MD5 hashing algorithm is showing cracks, we recommend the usage of SHA-1.
キーの優先アルゴリズムとしてRSA/SHA-1を使用することをお勧めします。RSAに対する現在の既知の攻撃は、キーを長くすることで敗北する可能性があります。MD5ハッシュアルゴリズムが亀裂を示しているため、SHA-1の使用をお勧めします。
At the time of publication, it is known that the SHA-1 hash has cryptanalysis issues. There is work in progress on addressing these issues. We recommend the use of public key algorithms based on hashes stronger than SHA-1 (e.g., SHA-256), as soon as these algorithms are available in protocol specifications (see [19] and [20]) and implementations.
出版時には、SHA-1ハッシュに暗号化の問題があることが知られています。これらの問題に対処する作業が進行中です。これらのアルゴリズムがプロトコル仕様（[19]および[20]を参照）および実装で利用可能になるとすぐに、SHA-1（例：SHA-256）よりも強いハッシュに基づいた公開キーアルゴリズムの使用をお勧めします。
When choosing key sizes, zone administrators will need to take into account how long a key will be used, how much data will be signed during the key publication period (see Section 8.10 of [17]), and, optionally, how large the key size of the parent is. As the chain of trust really is "a chain", there is not much sense in making one of the keys in the chain several times larger then the others. As always, it's the weakest link that defines the strength of the entire chain. Also see Section 3.1.1 for a discussion of how keys serving different roles (ZSK vs. KSK) may need different key sizes.
キーサイズを選択する場合、ゾーン管理者は、キーの使用期間、キーの公開期間中に署名されるデータの量（[17]のセクション8.10を参照）、およびオプションでキーの大きさを考慮する必要があります。親のサイズは。信頼のチェーンは本当に「チェーン」であるため、チェーン内の鍵の1つを他の鍵よりも数倍大きくすることにはあまり意味がありません。いつものように、チェーン全体の強度を定義するのは最も弱いリンクです。また、さまざまな役割（ZSK対KSK）に役立つキーが異なるキーサイズを必要とする方法についての議論については、セクション3.1.1も参照してください。
Generating a key of the correct size is a difficult problem; RFC 3766 [13] tries to deal with that problem. The first part of the selection procedure in Section 1 of the RFC states:
正しいサイズのキーを生成することは難しい問題です。RFC 3766 [13]は、その問題に対処しようとします。RFCのセクション1の選択手順の最初の部分は次のとおりです。
1. Determine the attack resistance necessary to satisfy the security requirements of the application. Do this by estimating the minimum number of computer operations that the attacker will be forced to do in order to compromise the security of the system and then take the logarithm base two of that number. Call that logarithm value "n".
1. アプリケーションのセキュリティ要件を満たすために必要な攻撃抵抗を決定します。これを行うと、システムのセキュリティを妥協し、その数の対数ベースを取得するために、攻撃者が強制されることを余儀なくされるコンピューター操作の最小数を推定します。その対数値「n」を呼び出します。
A 1996 report recommended 90 bits as a good all-around choice for system security. The 90 bit number should be increased by about 2/3 bit/year, or about 96 bits in 2005.
1996年のレポートでは、システムセキュリティのための総合的な選択肢として90ビットを推奨しました。90ビット数は、2005年には約2/3ビット/年、または約96ビット増加する必要があります。
[13] goes on to explain how this number "n" can be used to calculate the key sizes in public key cryptography. This culminated in the table given below (slightly modified for our purpose):
[13] さらに、この数字「n」を使用して、公開キーの暗号化のキーサイズを計算する方法を説明します。これは、以下の表に頂点に達しました（私たちの目的のためにわずかに変更されました）：
+-------------+-----------+--------------+
| System | | |
| requirement | Symmetric | RSA or DSA |
| for attack | key size | modulus size |
| resistance | (bits) | (bits) |
| (bits) | | |
+-------------+-----------+--------------+
| 70 | 70 | 947 |
| 80 | 80 | 1228 |
| 90 | 90 | 1553 |
| 100 | 100 | 1926 |
| 150 | 150 | 4575 |
| 200 | 200 | 8719 |
| 250 | 250 | 14596 |
+-------------+-----------+--------------+
The key sizes given are rather large. This is because these keys are resilient against a trillionaire attacker. Assuming this rich attacker will not attack your key and that the key is rolled over once a year, we come to the following recommendations about KSK sizes: 1024 bits for low-value domains, 1300 bits for medium-value domains, and 2048 bits for high-value domains.
与えられたキーサイズはかなり大きいです。これは、これらのキーが兆候の攻撃者に対して回復力があるためです。この豊富な攻撃者があなたのキーを攻撃しないと仮定し、キーが年に一度ロールオーバーされていると仮定すると、KSKサイズに関する次の推奨事項に至ります：価値の低いドメインでは1024ビット、中価値ドメインの1300ビット、および2048ビット高価値ドメイン。
Whether a domain is of low, medium, or high value depends solely on the views of the zone owner. One could, for instance, view leaf nodes in the DNS as of low value, and top-level domains (TLDs) or the root zone of high value. The suggested key sizes should be safe for the next 5 years.
ドメインが低い、中、または高い値であるかどうかは、ゾーン所有者のビューのみに依存します。たとえば、DNSの葉のノードを低い値として表示することができます。上位レベルのドメイン（TLD）または高い値のルートゾーンを表示できます。提案されたキーサイズは、今後5年間安全でなければなりません。
As ZSKs can be rolled over more easily (and thus more often), the key sizes can be made smaller. But as said in the introduction of this paragraph, making the ZSKs' key sizes too small (in relation to the KSKs' sizes) doesn't make much sense. Try to limit the difference in size to about 100 bits.
ZSKSはより簡単にロールオーバーすることができるため（したがってより頻繁に）、キーサイズを小さくすることができます。しかし、この段落の導入で述べたように、ZSKSのキーサイズが小さすぎる（KSKSのサイズに関連して）あまり意味がありません。サイズの差を約100ビットに制限してみてください。
Note that nobody can see into the future and that these key sizes are only provided here as a guide. Further information can be found in [16] and Section 7.5 of [17]. It should be noted though that [16] is already considered overly optimistic about what key sizes are considered safe.
誰も未来を見ることができず、これらのキーサイズはここでガイドとしてのみ提供されることに注意してください。詳細については、[16]および[17]のセクション7.5をご覧ください。ただし、[16]は、キーサイズが安全であると考えられていることについて、すでに過度に楽観的であると考えられていることに注意する必要があります。
One final note concerning key sizes. Larger keys will increase the sizes of the RRSIG and DNSKEY records and will therefore increase the chance of DNS UDP packet overflow. Also, the time it takes to validate and create RRSIGs increases with larger keys, so don't needlessly double your key sizes.
キーサイズに関する1つの最後のメモ。キーを大きくすると、RRSIGおよびDNSKEYレコードのサイズが増加するため、DNS UDPパケットオーバーフローの可能性が高まります。また、RRSIGを検証して作成するのにかかる時間は、より大きなキーで増加するため、キーサイズを不必要に2倍にしないでください。
It is recommended that, where possible, zone private keys and the zone file master copy that is to be signed be kept and used in off-line, non-network-connected, physically secure machines only. Periodically, an application can be run to add authentication to a zone by adding RRSIG and NSEC RRs. Then the augmented file can be transferred.
可能であれば、ゾーンプライベートキーと署名されるゾーンファイルマスターコピーは、オフラインでネットワークに接続されていない物理的に安全なマシンのみで保持され、使用することをお勧めします。定期的にアプリケーションを実行して、RRSIGとNSEC RRSを追加してゾーンに認証を追加できます。その後、拡張ファイルを転送できます。
When relying on dynamic update to manage a signed zone [10], be aware that at least one private key of the zone will have to reside on the master server. This key is only as secure as the amount of exposure the server receives to unknown clients and the security of the host. Although not mandatory, one could administer the DNS in the following way. The master that processes the dynamic updates is unavailable from generic hosts on the Internet, it is not listed in the NS RR set, although its name appears in the SOA RRs MNAME field. The nameservers in the NS RRSet are able to receive zone updates through NOTIFY, IXFR, AXFR, or an out-of-band distribution mechanism. This approach is known as the "hidden master" setup.
署名ゾーン[10]を管理するために動的アップデートに依存する場合、ゾーンの少なくとも1つの秘密鍵がマスターサーバーに存在する必要があることに注意してください。このキーは、サーバーが未知のクライアントに受け取る露出とホストのセキュリティと同じくらい安全です。必須ではありませんが、次の方法でDNSを管理できます。動的更新を処理するマスターは、インターネット上の汎用ホストから利用できません。NSRRセットにはリストされていませんが、その名前はSOA RRS MNAMEフィールドに表示されます。NS RRSTの名前サーバーは、Notify、IXFR、AXFR、または帯域外配布メカニズムを通じてゾーンアップデートを受信できます。このアプローチは、「隠されたマスター」セットアップとして知られています。
The ideal situation is to have a one-way information flow to the network to avoid the possibility of tampering from the network. Keeping the zone master file on-line on the network and simply cycling it through an off-line signer does not do this. The on-line version could still be tampered with if the host it resides on is compromised. For maximum security, the master copy of the zone file should be off-net and should not be updated based on an unsecured network mediated communication.
理想的な状況は、ネットワークからの改ざんの可能性を回避するために、ネットワークへの一方向の情報フローを持つことです。ゾーンマスターファイルをネットワーク上にオンラインに保ち、オフラインの署名者を介して単純にサイクリングしてもこれは行われません。オンラインバージョンは、ホストが存在する場合でも改ざんされる可能性があります。最大のセキュリティのために、ゾーンファイルのマスターコピーはネットから外れている必要があり、無担保ネットワーク媒介通信に基づいて更新しないでください。
In general, keeping a zone file off-line will not be practical and the machines on which zone files are maintained will be connected to a network. Operators are advised to take security measures to shield unauthorized access to the master copy.
一般に、ゾーンファイルをオフラインにすることは実用的ではなく、ゾーンファイルが維持されるマシンがネットワークに接続されます。オペレーターは、マスターコピーへの不正アクセスを保護するためにセキュリティ対策を講じることをお勧めします。
For dynamically updated secured zones [10], both the master copy and the private key that is used to update signatures on updated RRs will need to be on-line.
動的に更新されたセキュリティゾーン[10]の場合、マスターコピーと更新されたRRの署名を更新するために使用される秘密鍵の両方がオンラインである必要があります。
Without DNSSEC, all times in the DNS are relative. The SOA fields REFRESH, RETRY, and EXPIRATION are timers used to determine the time elapsed after a slave server synchronized with a master server. The Time to Live (TTL) value and the SOA RR minimum TTL parameter [11] are used to determine how long a forwarder should cache data after it has been fetched from an authoritative server. By using a signature validity period, DNSSEC introduces the notion of an absolute time in the DNS. Signatures in DNSSEC have an expiration date after which the signature is marked as invalid and the signed data is to be considered Bogus.
DNSSECがなければ、DNSの常に相対的です。SOAフィールドの更新、再試行、および有効期限は、マスターサーバーと同期したスレーブサーバーの後に経過する時間を決定するために使用されるタイマーです。ライブ（TTL）値とSOA RR最小TTLパラメーター[11]を使用して、信頼できるサーバーからフェッチされた後、フォワーダーがデータをキャッシュする期間を判断します。署名の妥当性期間を使用することにより、DNSSECはDNSの絶対時間の概念を導入します。DNSSECの署名は有効期限があり、その後署名は無効としてマークされ、署名されたデータは偽物と見なされます。
Because of the expiration of signatures, one should consider the following:
署名の満了のため、次を考慮する必要があります。
o We suggest the Maximum Zone TTL of your zone data to be a fraction of your signature validity period.
o ゾーンデータの最大ゾーンTTLは、署名の妥当性期間のほんの一部であることをお勧めします。
If the TTL would be of similar order as the signature validity period, then all RRSets fetched during the validity period would be cached until the signature expiration time. Section 7.1 of [4] suggests that "the resolver may use the time remaining before expiration of the signature validity period of a signed RRSet as an upper bound for the TTL". As a result, query load on authoritative servers would peak at signature expiration time, as this is also the time at which records simultaneously expire from caches.
TTLが署名の有効期間と同様の順序である場合、有効期間中にフェッチされたすべてのrrsetsは、署名の有効期限までキャッシュされます。[4]のセクション7.1は、「Resolverは、署名されたRRSetの署名妥当性の期限がTTLの上限として有効期限が切れる前の残りの時間を使用する可能性があることを示唆しています。その結果、権威あるサーバーのクエリ負荷は、署名の有効期限にピークに達します。これは、記録がキャッシュから同時に期限切れになる時間でもあるためです。
To avoid query load peaks, we suggest the TTL on all the RRs in your zone to be at least a few times smaller than your signature validity period.
クエリの負荷ピークを回避するために、ゾーン内のすべてのRRSのTTLが、署名の妥当性期間よりも少なくとも数倍小さくなることをお勧めします。
o We suggest the signature publication period to end at least one Maximum Zone TTL duration before the end of the signature validity period.
o 署名の公開期間は、署名の妥当性期間が終了する前に少なくとも1つの最大ゾーンTTL期間を終了することをお勧めします。
Re-signing a zone shortly before the end of the signature validity period may cause simultaneous expiration of data from caches. This in turn may lead to peaks in the load on authoritative servers.
署名の妥当性期間の終了の少し前にゾーンを再署名すると、キャッシュからのデータの同時有効期限が生じる可能性があります。これにより、権威あるサーバーの負荷がピークに達する可能性があります。
o We suggest the Minimum Zone TTL to be long enough to both fetch and verify all the RRs in the trust chain. In workshop environments, it has been demonstrated [18] that a low TTL (under 5 to 10 minutes) caused disruptions because of the following two problems:
o 最小ゾーンTTLは、信頼チェーン内のすべてのRRを取得および検証するのに十分な長さであることをお勧めします。ワークショップ環境では、次の2つの問題のために、低TTL（5〜10分未満）が混乱を引き起こすことが実証されています。
1. During validation, some data may expire before the validation is complete. The validator should be able to keep all data until it is completed. This applies to all RRs needed to complete the chain of trust: DSes, DNSKEYs, RRSIGs, and the final answers, i.e., the RRSet that is returned for the initial query.
1. 検証中、検証が完了する前に一部のデータが期限切れになる場合があります。バリデーターは、完了するまですべてのデータを保持できる必要があります。これは、信頼のチェーンを完了するために必要なすべてのRRに適用されます：DSE、DNSKEYS、RRSIGS、および最終回答、つまり初期クエリのために返されるRRSET。
2. Frequent verification causes load on recursive nameservers. Data at delegation points, DSes, DNSKEYs, and RRSIGs benefit from caching. The TTL on those should be relatively long.
2. 頻繁に検証すると、再帰的な名前サーバーに負荷がかかります。委任ポイント、DSES、DNSKEYS、およびRRSIGのデータは、キャッシュの恩恵を受けます。それらのTTLは比較的長い必要があります。
o Slave servers will need to be able to fetch newly signed zones well before the RRSIGs in the zone served by the slave server pass their signature expiration time.
o スレーブサーバーは、スレーブサーバーが提供するゾーン内のRRSIGが署名の有効期限を渡すかなり前に、新しく署名されたゾーンを取得できる必要があります。
When a slave server is out of sync with its master and data in a zone is signed by expired signatures, it may be better for the slave server not to give out any answer.
スレーブサーバーがマスターと同期していない場合、ゾーン内のデータが期限切れの署名によって署名されている場合、スレーブサーバーが答えを出さない方が良いかもしれません。
Normally, a slave server that is not able to contact a master server for an extended period will expire a zone. When that happens, the server will respond differently to queries for that zone. Some servers issue SERVFAIL, whereas others turn off the 'AA' bit in the answers. The time of expiration is set in the SOA record and is relative to the last successful refresh between the master and the slave servers. There exists no coupling between the signature expiration of RRSIGs in the zone and the expire parameter in the SOA.
通常、長期間マスターサーバーに連絡できないスレーブサーバーは、ゾーンの有効期限が切れます。それが起こると、サーバーはそのゾーンのクエリに対して異なる方法で応答します。一部のサーバーはServFailを発行しますが、他のサーバーは回答の「AA」ビットをオフにします。有効期限はSOAレコードに設定されており、マスターとスレーブサーバーの間の最後の成功した更新に関連しています。ゾーン内のRRSIGの署名の有効期限とSOAの有効期限パラメーターの間には結合は存在しません。
If the server serves a DNSSEC zone, then it may well happen that the signatures expire well before the SOA expiration timer counts down to zero. It is not possible to completely prevent this from happening by tweaking the SOA parameters. However, the effects can be minimized where the SOA expiration time is equal to or shorter than the signature validity period. The consequence of an authoritative server not being able to update a zone, whilst that zone includes expired signatures, is that non-secure resolvers will continue to be able to resolve data served by the particular slave servers while security-aware resolvers will experience problems because of answers being marked as Bogus.
サーバーがDNSSECゾーンにサービスを提供する場合、SOA有効期限タイマーがゼロにカウントされる前に、署名がかなり終了することが発生する可能性があります。SOAパラメーターを微調整して、これが発生するのを完全に防ぐことはできません。ただし、SOAの有効期限が署名の妥当性期間と等しい、または短い場合、効果は最小限に抑えることができます。権威あるサーバーがゾーンを更新できないことの結果、そのゾーンには期限切れの署名が含まれていますが、非セキュアリゾルバーは特定の奴隷サーバーが提供するデータを解決し続けることができ、セキュリティ対応のリゾルバーは問題が発生するためです。偽物としてマークされている答えの。
We suggest the SOA expiration timer being approximately one third or one fourth of the signature validity period. It will allow problems with transfers from the master server to be noticed before the actual signature times out. We also suggest that operators of nameservers that supply secondary services develop 'watch dogs' to spot upcoming signature expirations in zones they slave, and take appropriate action.
SOA有効期限タイマーは、署名の妥当性期間の約3分の1または4分の1であることをお勧めします。マスターサーバーからの転送の問題が、実際の署名時間が出る前に気付くことができます。また、セカンダリサービスを提供する名前の名前サーバーのオペレーターが「犬」を開発して、奴隷ゾーンで今後の署名の満了を見つけ、適切な行動を起こすことをお勧めします。
When determining the value for the expiration parameter one has to take the following into account: What are the chances that all my secondaries expire the zone? How quickly can I reach an administrator of secondary servers to load a valid zone? These questions are not DNSSEC specific but may influence the choice of your signature validity intervals.
有効期限パラメーターの値を決定するとき、次のことを考慮する必要があります。有効なゾーンをロードするために、セカンダリサーバーの管理者にどれだけ早くリーチできますか？これらの質問はDNSSEC固有ではありませんが、署名の妥当性間隔の選択に影響を与える可能性があります。
A DNSSEC key cannot be used forever (see Section 3.3). So key rollovers -- or supercessions, as they are sometimes called -- are a fact of life when using DNSSEC. Zone administrators who are in the process of rolling their keys have to take into account that data published in previous versions of their zone still lives in caches. When deploying DNSSEC, this becomes an important consideration; ignoring data that may be in caches may lead to loss of service for clients.
DNSSECキーは永遠に使用することはできません（セクション3.3を参照）。したがって、キーロールオーバー、または時々呼ばれるスーパーセッションは、DNSSECを使用するときの人生の事実です。キーを転がす過程にあるゾーン管理者は、ゾーンの以前のバージョンで公開されていたデータがまだキャッシュに住んでいることを考慮する必要があります。DNSSECを展開するとき、これは重要な考慮事項になります。キャッシュにある可能性のあるデータを無視すると、クライアントのサービスが失われる可能性があります。
The most pressing example of this occurs when zone material signed with an old key is being validated by a resolver that does not have the old zone key cached. If the old key is no longer present in the current zone, this validation fails, marking the data "Bogus". Alternatively, an attempt could be made to validate data that is signed with a new key against an old key that lives in a local cache, also resulting in data being marked "Bogus".
これの最も差し迫った例は、古いキーで署名されたゾーンマテリアルが古いゾーンキーがキャッシュされていないリゾルバーによって検証されているときに発生します。古いキーが現在のゾーンに存在しなくなった場合、この検証は失敗し、データ「偽」をマークします。あるいは、ローカルキャッシュに住んでいる古いキーに対して新しいキーで署名されたデータを検証する試みを行うことができます。
For "Zone Signing Key rollovers", there are two ways to make sure that during the rollover data still cached can be verified with the new key sets or newly generated signatures can be verified with the keys still in caches. One schema, described in Section 4.2.1.2, uses double signatures; the other uses key pre-publication (Section 4.2.1.1). The pros, cons, and recommendations are described in Section 4.2.1.3.
「ゾーン署名キーロールオーバー」の場合、ロールオーバーデータの間にまだキャッシュされた新しいキーセットで検証できるか、キャッシュのキーを使用して新しく生成された署名を検証できることを確認するには、2つの方法があります。セクション4.2.1.2で説明されている1つのスキーマは、二重署名を使用しています。もう1つは、キーの事前公開を使用します（セクション4.2.1.1）。長所、短所、および推奨事項については、セクション4.2.1.3で説明します。
This section shows how to perform a ZSK rollover without the need to sign all the data in a zone twice -- the "pre-publish key rollover". This method has advantages in the case of a key compromise. If the old key is compromised, the new key has already been distributed in the DNS. The zone administrator is then able to quickly switch to the new key and remove the compromised key from the zone. Another major advantage is that the zone size does not double, as is the case with the double signature ZSK rollover. A small "how-to" for this kind of rollover can be found in Appendix B.
このセクションでは、ゾーン内のすべてのデータに2回署名する必要なく、ZSKロールオーバーを実行する方法を示しています。この方法には、重要な妥協の場合には利点があります。古いキーが侵害されている場合、新しいキーはすでにDNSに分散されています。ゾーン管理者は、新しいキーにすばやく切り替えて、ゾーンから侵害されたキーを削除できます。もう1つの大きな利点は、ゾーンサイズが2倍にならないことです。これは、ZSKロールオーバーのダブルの場合のように。この種のロールオーバーのための小さな「ハウツー」は、付録Bにあります。
Pre-publish key rollover involves four stages as follows:
Preublishキーロールオーバーには、次のように4つの段階が含まれます。
----------------------------------------------------------------
initial new DNSKEY new RRSIGs DNSKEY removal
----------------------------------------------------------------
SOA0 SOA1 SOA2 SOA3
RRSIG10(SOA0) RRSIG10(SOA1) RRSIG11(SOA2) RRSIG11(SOA3)
DNSKEY1 DNSKEY1 DNSKEY1 DNSKEY1
DNSKEY10 DNSKEY10 DNSKEY10 DNSKEY11
DNSKEY11 DNSKEY11
RRSIG1 (DNSKEY) RRSIG1 (DNSKEY) RRSIG1(DNSKEY) RRSIG1 (DNSKEY)
RRSIG10(DNSKEY) RRSIG10(DNSKEY) RRSIG11(DNSKEY) RRSIG11(DNSKEY)
----------------------------------------------------------------
Pre-Publish Key Rollover
キーロールオーバーを事前に公開します
initial: Initial version of the zone: DNSKEY 1 is the Key Signing Key. DNSKEY 10 is used to sign all the data of the zone, the Zone Signing Key.
初期：ゾーンの初期バージョン：DNSKEY 1がキー署名キーです。DNSKEY 10は、ゾーンの署名キーであるゾーンのすべてのデータに署名するために使用されます。
new DNSKEY: DNSKEY 11 is introduced into the key set. Note that no signatures are generated with this key yet, but this does not secure against brute force attacks on the public key. The minimum duration of this pre-roll phase is the time it takes for the data to propagate to the authoritative servers plus TTL value of the key set.
新しいdnskey：dnskey 11がキーセットに導入されています。このキーではまだ署名が生成されていないことに注意してくださいが、これは公開鍵に対するブルートフォース攻撃に対して保護されていないことに注意してください。このプレロール段階の最小期間は、データが権威あるサーバーとキーセットのTTL値に伝播するのにかかる時間です。
new RRSIGs: At the "new RRSIGs" stage (SOA serial 2), DNSKEY 11 is used to sign the data in the zone exclusively (i.e., all the signatures from DNSKEY 10 are removed from the zone). DNSKEY 10 remains published in the key set. This way data that was loaded into caches from version 1 of the zone can still be verified with key sets fetched from version 2 of the zone. The minimum time that the key set including DNSKEY 10 is to be published is the time that it takes for zone data from the previous version of the zone to expire from old caches, i.e., the time it takes for this zone to propagate to all authoritative servers plus the Maximum Zone TTL value of any of the data in the previous version of the zone.
新しいRRSIGS：「新しいRRSIGS」ステージ（SOAシリアル2）で、DNSKEY 11はゾーンのみのデータに署名するために使用されます（つまり、DNSKEY 10のすべての署名がゾーンから削除されます）。dnskey 10はキーセットで公開されたままです。この方法で、ゾーンのバージョン1からキャッシュにロードされたデータは、ゾーンのバージョン2から取得されたキーセットで検証できます。DNSKEY 10を含むキーセットが公開される最小時間は、以前のバージョンのゾーンデータが古いキャッシュから期限切れになるのにかかる時間、つまり、このゾーンがすべての権威あるものに伝播するのにかかる時間です。サーバーに加えて、ゾーンの以前のバージョンのデータの最大ゾーンTTL値。
DNSKEY removal: DNSKEY 10 is removed from the zone. The key set, now only containing DNSKEY 1 and DNSKEY 11, is re-signed with the DNSKEY 1.
DNSKEY削除：DNSKEY 10がゾーンから削除されます。キーセットは、DNSKEY 1とDNSKEY 11のみを含むだけで、DNSKEY 1と再署名されています。
The above scheme can be simplified by always publishing the "future" key immediately after the rollover. The scheme would look as follows (we show two rollovers); the future key is introduced in "new DNSKEY" as DNSKEY 12 and again a newer one, numbered 13, in "new DNSKEY (II)":
上記のスキームは、ロールオーバーの直後に「将来」キーを常に公開することで簡素化できます。スキームは次のように見えます（2つのロールオーバーを示します）。将来のキーは、「新しいdnskey」でdnskey 12として紹介され、再び新しいものとして紹介されます。
----------------------------------------------------------------
initial new RRSIGs new DNSKEY
----------------------------------------------------------------
SOA0 SOA1 SOA2
RRSIG10(SOA0) RRSIG11(SOA1) RRSIG11(SOA2)
DNSKEY1 DNSKEY1 DNSKEY1
DNSKEY10 DNSKEY10 DNSKEY11
DNSKEY11 DNSKEY11 DNSKEY12
RRSIG1(DNSKEY) RRSIG1 (DNSKEY) RRSIG1(DNSKEY)
RRSIG10(DNSKEY) RRSIG11(DNSKEY) RRSIG11(DNSKEY)
----------------------------------------------------------------
----------------------------------------------------------------
new RRSIGs (II) new DNSKEY (II)
----------------------------------------------------------------
SOA3 SOA4
RRSIG12(SOA3) RRSIG12(SOA4)
DNSKEY1 DNSKEY1
DNSKEY11 DNSKEY12
DNSKEY12 DNSKEY13
RRSIG1(DNSKEY) RRSIG1(DNSKEY)
RRSIG12(DNSKEY) RRSIG12(DNSKEY)
----------------------------------------------------------------
Pre-Publish Key Rollover, Showing Two Rollovers
キーロールオーバーを事前に公開し、2つのロールオーバーを示しています
Note that the key introduced in the "new DNSKEY" phase is not used for production yet; the private key can thus be stored in a physically secure manner and does not need to be 'fetched' every time a zone needs to be signed.
「新しいDNSKEY」フェーズで導入されたキーは、まだ生産には使用されていないことに注意してください。したがって、秘密鍵は物理的に安全な方法で保存することができ、ゾーンを署名する必要があるたびに「フェッチ」する必要はありません。
This section shows how to perform a ZSK key rollover using the double zone data signature scheme, aptly named "double signature rollover".
このセクションでは、「Double Signature Rollover」という名前のダブルゾーンデータ署名スキームを使用してZSKキーロールオーバーを実行する方法を示します。
During the "new DNSKEY" stage the new version of the zone file will need to propagate to all authoritative servers and the data that exists in (distant) caches will need to expire, requiring at least the Maximum Zone TTL.
「新しいdnskey」ステージ中、ゾーンファイルの新しいバージョンはすべての権威あるサーバーに伝播する必要があり、（遠い）キャッシュに存在するデータは期限切れになる必要があり、少なくとも最大ゾーンTTLが必要です。
Double signature ZSK rollover involves three stages as follows:
二重署名ZSKロールオーバーには、次のように3つのステージが含まれます。
----------------------------------------------------------------
initial new DNSKEY DNSKEY removal
----------------------------------------------------------------
SOA0 SOA1 SOA2
RRSIG10(SOA0) RRSIG10(SOA1) RRSIG11(SOA2)
RRSIG11(SOA1)
DNSKEY1 DNSKEY1 DNSKEY1
DNSKEY10 DNSKEY10 DNSKEY11
DNSKEY11
RRSIG1(DNSKEY) RRSIG1(DNSKEY) RRSIG1(DNSKEY)
RRSIG10(DNSKEY) RRSIG10(DNSKEY) RRSIG11(DNSKEY)
RRSIG11(DNSKEY)
----------------------------------------------------------------
Double Signature Zone Signing Key Rollover
キーロールオーバーに署名するダブルシグネチャーゾーン
initial: Initial Version of the zone: DNSKEY 1 is the Key Signing Key. DNSKEY 10 is used to sign all the data of the zone, the Zone Signing Key.
初期：ゾーンの初期バージョン：DNSKEY 1がキー署名キーです。DNSKEY 10は、ゾーンの署名キーであるゾーンのすべてのデータに署名するために使用されます。
new DNSKEY: At the "New DNSKEY" stage (SOA serial 1) DNSKEY 11 is introduced into the key set and all the data in the zone is signed with DNSKEY 10 and DNSKEY 11. The rollover period will need to continue until all data from version 0 of the zone has expired from remote caches. This will take at least the Maximum Zone TTL of version 0 of the zone.
新しいDNSKEY：「新しいDNSKEY」ステージ（SOAシリアル1）では、DNSKEY 11がキーセットに導入され、ゾーン内のすべてのデータがDNSKEY 10およびDNSKEY 11で署名されます。ゾーンのバージョン0は、リモートキャッシュから期限切れになりました。これには、少なくともゾーンのバージョン0の最大ゾーンTTLが必要になります。
DNSKEY removal: DNSKEY 10 is removed from the zone. All the signatures from DNSKEY 10 are removed from the zone. The key set, now only containing DNSKEY 11, is re-signed with DNSKEY 1.
DNSKEY削除：DNSKEY 10がゾーンから削除されます。DNSKEY 10のすべての署名はゾーンから削除されます。現在、DNSKEY 11のみを含むキーセットには、DNSKEY 1が再署名されています。
At every instance, RRSIGs from the previous version of the zone can be verified with the DNSKEY RRSet from the current version and the other way around. The data from the current version can be verified with the data from the previous version of the zone. The duration of the "new DNSKEY" phase and the period between rollovers should be at least the Maximum Zone TTL.
すべてのインスタンスで、ゾーンの以前のバージョンのRRSIGは、現在のバージョンとその他の方法からDNSKEY RRSetで検証できます。現在のバージョンのデータは、ゾーンの以前のバージョンのデータで検証できます。「新しいDNSKEY」フェーズの期間とロールオーバー間の期間は、少なくとも最大ゾーンTTLでなければなりません。
Making sure that the "new DNSKEY" phase lasts until the signature expiration time of the data in initial version of the zone is recommended. This way all caches are cleared of the old signatures. However, this duration could be considerably longer than the Maximum Zone TTL, making the rollover a lengthy procedure.
ゾーンの初期バージョンのデータの署名の有効期限が推奨されるまで、「新しいDNSKEY」フェーズが続くことを確認します。このようにして、すべてのキャッシュは古い署名からクリアされています。ただし、この期間は最大ゾーンTTLよりもかなり長くなる可能性があるため、ロールオーバーは長い手順になります。
Note that in this example we assumed that the zone was not modified during the rollover. New data can be introduced in the zone as long as it is signed with both keys.
この例では、ロールオーバー中にゾーンが変更されていないと仮定したことに注意してください。両方のキーで署名されている限り、ゾーンに新しいデータを導入できます。
Pre-publish key rollover: This rollover does not involve signing the zone data twice. Instead, before the actual rollover, the new key is published in the key set and thus is available for cryptanalysis attacks. A small disadvantage is that this process requires four steps. Also the pre-publish scheme involves more parental work when used for KSK rollovers as explained in Section 4.2.3.
事前に公開されたキーロールオーバー：このロールオーバーには、ゾーンデータに2回署名することは含まれません。代わりに、実際のロールオーバーの前に、新しいキーがキーセットに公開されるため、暗号化攻撃に使用できます。わずかな欠点は、このプロセスに4つのステップが必要であることです。また、セクション4.2.3で説明されているように、KSKロールオーバーに使用する場合、出版前スキームには、より多くの親の仕事が含まれます。
Double signature ZSK rollover: The drawback of this signing scheme is that during the rollover the number of signatures in your zone doubles; this may be prohibitive if you have very big zones. An advantage is that it only requires three steps.
二重署名ZSKロールオーバー：この署名スキームの欠点は、ロールオーバー中にゾーンの署名の数が2倍になるということです。あなたが非常に大きなゾーンを持っている場合、これは法外なかもしれません。利点は、3つのステップのみが必要なことです。
For the rollover of a Key Signing Key, the same considerations as for the rollover of a Zone Signing Key apply. However, we can use a double signature scheme to guarantee that old data (only the apex key set) in caches can be verified with a new key set and vice versa. Since only the key set is signed with a KSK, zone size considerations do not apply.
キー署名キーのロールオーバーの場合、ゾーン署名キーのロールオーバーと同じ考慮事項が適用されます。ただし、二重署名スキームを使用して、キャッシュの古いデータ（Apexキーセットのみ）を新しいキーセットで検証できることを保証できます。キーセットのみがKSKで署名されているため、ゾーンサイズの考慮事項は適用されません。
--------------------------------------------------------------------
initial new DNSKEY DS change DNSKEY removal
--------------------------------------------------------------------
Parent:
SOA0 --------> SOA1 -------->
RRSIGpar(SOA0) --------> RRSIGpar(SOA1) -------->
DS1 --------> DS2 -------->
RRSIGpar(DS) --------> RRSIGpar(DS) -------->
Child:
SOA0 SOA1 --------> SOA2
RRSIG10(SOA0) RRSIG10(SOA1) --------> RRSIG10(SOA2)
-------->
DNSKEY1 DNSKEY1 --------> DNSKEY2
DNSKEY2 -------->
DNSKEY10 DNSKEY10 --------> DNSKEY10
RRSIG1 (DNSKEY) RRSIG1 (DNSKEY) --------> RRSIG2 (DNSKEY)
RRSIG2 (DNSKEY) -------->
RRSIG10(DNSKEY) RRSIG10(DNSKEY) --------> RRSIG10(DNSKEY)
--------------------------------------------------------------------
Stages of Deployment for a Double Signature Key Signing Key Rollover
二重署名キーの署名キーロールオーバーの展開段階
initial: Initial version of the zone. The parental DS points to DNSKEY1. Before the rollover starts, the child will have to verify what the TTL is of the DS RR that points to DNSKEY1 -- it is needed during the rollover and we refer to the value as TTL_DS.
初期：ゾーンの初期バージョン。親のDSはDNSKEY1を指します。ロールオーバーが開始される前に、子供はDNSKEY1を指すDS RRのTTLが何であるかを検証する必要があります。ロールオーバー中に必要であり、値をTTL_DSと呼びます。
new DNSKEY: During the "new DNSKEY" phase, the zone administrator generates a second KSK, DNSKEY2. The key is provided to the parent, and the child will have to wait until a new DS RR has been generated that points to DNSKEY2. After that DS RR has been published on all servers authoritative for the parent's zone, the zone administrator has to wait at least TTL_DS to make sure that the old DS RR has expired from caches.
新しいDNSKEY：「新しいDNSKEY」フェーズでは、ゾーン管理者が2番目のKSK、DNSKEY2を生成します。キーは親に提供され、子供はdnskey2にポイントを生成する新しいDS RRが生成されるまで待たなければなりません。その後、DS RRが親のゾーンで権威あるすべてのサーバーで公開された後、ゾーン管理者は少なくともTTL_DSを待って、古いDS RRがキャッシュから期限切れになっていることを確認する必要があります。
DS change: The parent replaces DS1 with DS2.
DS変更：親はDS1をDS2に置き換えます。
DNSKEY removal: DNSKEY1 has been removed.
DNSKEY削除：DNSKEY1が削除されました。
The scenario above puts the responsibility for maintaining a valid chain of trust with the child. It also is based on the premise that the parent only has one DS RR (per algorithm) per zone. An alternative mechanism has been considered. Using an established trust relation, the interaction can be performed in-band, and the removal of the keys by the child can possibly be signaled by the parent. In this mechanism, there are periods where there are two DS RRs at the parent. Since at the moment of writing the protocol for this interaction has not been developed, further discussion is out of scope for this document.
上記のシナリオは、子供との有効な信頼の連鎖を維持する責任を負います。また、親はゾーンごとに1つのDS RR（アルゴリズムごと）しかないという前提に基づいています。別のメカニズムが考慮されています。確立された信頼関係を使用して、相互作用を帯域内で実行でき、子供による鍵の除去は、親によって信号を送ることができます。このメカニズムには、親に2つのDS RRがある期間があります。この相互作用のプロトコルを作成した瞬間に開発されていないため、このドキュメントのさらなる議論は範囲外です。
Note that KSK rollovers and ZSK rollovers are different in the sense that a KSK rollover requires interaction with the parent (and possibly replacing of trust anchors) and the ensuing delay while waiting for it.
KSKロールオーバーとZSKロールオーバーは、KSKロールオーバーが親との相互作用（およびおそらく信頼アンカーの置き換え）とそれを待っている間にその後の遅延を必要とするという意味で異なることに注意してください。
A zone key rollover can be handled in two different ways: pre-publish (Section 4.2.1.1) and double signature (Section 4.2.1.2).
ゾーンキーロールオーバーは、2つの異なる方法で処理できます：事前発行（セクション4.2.1.1）と二重署名（セクション4.2.1.2）。
As the KSK is used to validate the key set and because the KSK is not changed during a ZSK rollover, a cache is able to validate the new key set of the zone. The pre-publish method would also work for a KSK rollover. The records that are to be pre-published are the parental DS RRs. The pre-publish method has some drawbacks for KSKs. We first describe the rollover scheme and then indicate these drawbacks.
KSKはキーセットの検証に使用され、ZSKロールオーバー中にKSKが変更されないため、キャッシュはゾーンの新しいキーセットを検証できます。出版前の方法は、KSKロールオーバーにも機能します。事前に公開される記録は、親のDS RRSです。出版前の方法には、KSKにいくつかの欠点があります。最初にロールオーバースキームについて説明し、次にこれらの欠点を示します。
--------------------------------------------------------------------
initial new DS new DNSKEY DS/DNSKEY removal
--------------------------------------------------------------------
Parent:
SOA0 SOA1 --------> SOA2
RRSIGpar(SOA0) RRSIGpar(SOA1) --------> RRSIGpar(SOA2)
DS1 DS1 --------> DS2
DS2 -------->
RRSIGpar(DS) RRSIGpar(DS) --------> RRSIGpar(DS)
Child:
SOA0 --------> SOA1 SOA1
RRSIG10(SOA0) --------> RRSIG10(SOA1) RRSIG10(SOA1)
-------->
DNSKEY1 --------> DNSKEY2 DNSKEY2
-------->
DNSKEY10 --------> DNSKEY10 DNSKEY10
RRSIG1 (DNSKEY) --------> RRSIG2(DNSKEY) RRSIG2 (DNSKEY)
RRSIG10(DNSKEY) --------> RRSIG10(DNSKEY) RRSIG10(DNSKEY)
--------------------------------------------------------------------
Stages of Deployment for a Pre-Publish Key Signing Key Rollover
出版前のキー署名キーロールオーバーの展開段階
When the child zone wants to roll, it notifies the parent during the "new DS" phase and submits the new key (or the corresponding DS) to the parent. The parent publishes DS1 and DS2, pointing to DNSKEY1 and DNSKEY2, respectively. During the rollover ("new DNSKEY" phase), which can take place as soon as the new DS set propagated through the DNS, the child replaces DNSKEY1 with DNSKEY2. Immediately after that ("DS/DNSKEY removal" phase), it can notify the parent that the old DS record can be deleted.
チャイルドゾーンが転がしたい場合、「新しいDS」フェーズ中に親に通知し、新しいキー（または対応するDS）を親に提出します。親はDS1とDS2を公開し、それぞれDNSKEY1とDNSKEY2を指しています。新しいDSセットがDNSを介して伝播するとすぐに、ロールオーバー（「新しいDNSKEY」フェーズ）中に、子供はDNSKEY1をDNSKey2に置き換えます。その直後（「DS/DNSKEY削除」フェーズ）、古いDSレコードを削除できることを親に通知できます。
The drawbacks of this scheme are that during the "new DS" phase the parent cannot verify the match between the DS2 RR and DNSKEY2 using the DNS -- as DNSKEY2 is not yet published. Besides, we introduce a "security lame" key (see Section 4.4.3). Finally, the child-parent interaction consists of two steps. The "double signature" method only needs one interaction.
このスキームの欠点は、「新しいDS」フェーズ中に、DNSKey2がまだ公開されていないため、DNSを使用してDS2 RRとDNSKEY2の一致を検証できないことです。その上、「セキュリティラメ」キーを紹介します（セクション4.4.3を参照）。最後に、子どもの親の相互作用は2つのステップで構成されています。「二重署名」メソッドには、1つのインタラクションのみが必要です。
As keys must be renewed periodically, there is some motivation to automate the rollover process. Consider the following:
キーは定期的に更新する必要があるため、ロールオーバープロセスを自動化する動機があります。以下を検討してください。
o ZSK rollovers are easy to automate as only the child zone is involved.
o ZSKロールオーバーは、チャイルドゾーンのみが関与しているため、自動化するのが簡単です。
o A KSK rollover needs interaction between parent and child. Data exchange is needed to provide the new keys to the parent; consequently, this data must be authenticated and integrity must be guaranteed in order to avoid attacks on the rollover.
o KSKロールオーバーには、親と子の間の相互作用が必要です。親に新しいキーを提供するには、データ交換が必要です。したがって、このデータは認証され、ロールオーバーへの攻撃を避けるために整合性を保証する必要があります。
This section deals with preparation for a possible key compromise. Our advice is to have a documented procedure ready for when a key compromise is suspected or confirmed.
このセクションでは、可能な重要な妥協の準備を扱います。私たちのアドバイスは、重要な妥協が疑われるか、確認されたときに、文書化された手順を準備することです。
When the private material of one of your keys is compromised it can be used for as long as a valid trust chain exists. A trust chain remains intact for
鍵のいずれかのプライベート素材が損なわれると、有効な信頼チェーンが存在する限り使用できます。信頼チェーンはそのままのままです
o as long as a signature over the compromised key in the trust chain is valid,
o トラストチェーンの妥協したキーをめぐる署名が有効である限り、
o as long as a parental DS RR (and signature) points to the compromised key,
o 親のDS RR（および署名）が侵害されたキーを指している限り、
o as long as the key is anchored in a resolver and is used as a starting point for validation (this is generally the hardest to update).
o キーがリゾルバーに固定され、検証の出発点として使用されている限り（これは一般に更新が最も難しいです）。
While a trust chain to your compromised key exists, your namespace is vulnerable to abuse by anyone who has obtained illegitimate possession of the key. Zone operators have to make a trade-off if the abuse of the compromised key is worse than having data in caches that cannot be validated. If the zone operator chooses to break the trust chain to the compromised key, data in caches signed with this key cannot be validated. However, if the zone administrator chooses to take the path of a regular rollover, the malicious key holder can spoof data so that it appears to be valid.
妥協したキーへの信頼チェーンが存在しますが、名前空間は、キーの非giatialな所持を取得した人の虐待に対して脆弱です。侵害されたキーの乱用が検証できないキャッシュにデータを持っているよりも悪い場合、ゾーンオペレーターはトレードオフをする必要があります。ゾーンオペレーターが侵害されたキーにトラストチェーンを破ることを選択した場合、このキーに署名されたキャッシュのデータを検証することはできません。ただし、ゾーン管理者が定期的なロールオーバーの道を進むことを選択した場合、悪意のあるキーホルダーはデータが有効であるように見えるようにデータをスプーフィングできます。
A zone containing a DNSKEY RRSet with a compromised KSK is vulnerable as long as the compromised KSK is configured as trust anchor or a parental DS points to it.
侵害されたKSKを備えたDNSKEY RRSTを含むゾーンは、侵害されたKSKが信頼アンカーとして構成されているか、親のDSがそれを指している限り、脆弱です。
A compromised KSK can be used to sign the key set of an attacker's zone. That zone could be used to poison the DNS.
侵害されたKSKを使用して、攻撃者のゾーンのキーセットに署名できます。そのゾーンは、DNSを毒するために使用できます。
Therefore, when the KSK has been compromised, the trust anchor or the parental DS should be replaced as soon as possible. It is local policy whether to break the trust chain during the emergency rollover. The trust chain would be broken when the compromised KSK is removed from the child's zone while the parent still has a DS pointing to the compromised KSK (the assumption is that there is only one DS at the parent. If there are multiple DSes this does not apply -- however the chain of trust of this particular key is broken).
したがって、KSKが侵害された場合、信頼のアンカーまたは親のDSをできるだけ早く交換する必要があります。緊急ロールオーバー中に信頼チェーンを破るかどうかは、ローカルポリシーです。妥協したKSKが子供のゾーンから削除されると、親が侵害されたKSKを指しているDSを持っている場合、信頼チェーンは壊れます（親にDSは1つしかないという仮定です。複数のDSEがある場合、これはそうしません適用 - ただし、この特定のキーの信頼の連鎖は壊れています）。
Note that an attacker's zone still uses the compromised KSK and the presence of a parental DS would cause the data in this zone to appear as valid. Removing the compromised key would cause the attacker's zone to appear as valid and the child's zone as Bogus. Therefore, we advise not to remove the KSK before the parent has a DS to a new KSK in place.
攻撃者のゾーンは依然として侵害されたKSKを使用しており、親のDSの存在により、このゾーンのデータが有効に見えるようになることに注意してください。妥協したキーを削除すると、攻撃者のゾーンが有効になり、子供のゾーンが偽のように見えます。したがって、親が新しいKSKにDSを設置する前に、KSKを削除しないようにアドバイスします。
If we follow this advice, the timing of the replacement of the KSK is somewhat critical. The goal is to remove the compromised KSK as soon as the new DS RR is available at the parent. And also make sure that the signature made with a new KSK over the key set with the compromised KSK in it expires just after the new DS appears at the parent, thus removing the old cruft in one swoop.
このアドバイスに従うと、KSKの交換のタイミングはやや重要です。目標は、新しいDS RRが親で利用可能になるとすぐに、侵害されたKSKを削除することです。また、新しいDSが親に現れた直後に、侵害されたKSKを使用してキーセットを介して新しいKSKを使用して作成された署名が有効であることを確認してください。
The procedure is as follows:
手順は次のとおりです。
1. Introduce a new KSK into the key set, keep the compromised KSK in the key set.
1. 新しいKSKをキーセットに導入し、妥協したKSKをキーセットに保ちます。
2. Sign the key set, with a short validity period. The validity period should expire shortly after the DS is expected to appear in the parent and the old DSes have expired from caches.
2. 妥当性の期間が短いキーセットに署名します。有効期間は、親にDSが現れると予想され、古いDSEがキャッシュから期限切れになった直後に期限切れになるはずです。
3. Upload the DS for this new key to the parent.
3. この新しいキーのDSを親にアップロードします。
4. Follow the procedure of the regular KSK rollover: Wait for the DS to appear in the authoritative servers and then wait as long as the TTL of the old DS RRs. If necessary re-sign the DNSKEY RRSet and modify/extend the expiration time.
4. 通常のKSKロールオーバーの手順に従ってください。DSが権威あるサーバーに表示されるのを待ってから、古いDS RRSのTTLだけを待ちます。必要に応じて、dnskey rrsetを再署名し、有効期限を変更/延長します。
5. Remove the compromised DNSKEY RR from the zone and re-sign the key set using your "normal" validity interval.
5. 侵害されたDNSKEY RRをゾーンから削除し、「通常の」妥当性間隔を使用してキーセットを再署名します。
An additional danger of a key compromise is that the compromised key could be used to facilitate a legitimate DNSKEY/DS rollover and/or nameserver changes at the parent. When that happens, the domain may be in dispute. An authenticated out-of-band and secure notify mechanism to contact a parent is needed in this case.
重要な妥協の追加の危険は、妥協したキーを使用して、親の正当なDNSKEY/DSロールオーバーおよび/または名前サーバーの変更を促進できることです。それが起こると、ドメインが争っている可能性があります。この場合、認証された帯域外で安全な通知メカニズムが親に接触する必要があります。
Note that this is only a problem when the DNSKEY and or DS records are used for authentication at the parent.
これは、DNSKEYおよびDSレコードが親の認証に使用される場合にのみ問題であることに注意してください。
There are two methods to break the chain of trust. The first method causes the child zone to appear 'Bogus' to validating resolvers. The other causes the child zone to appear 'insecure'. These are described below.
信頼の連鎖を破る方法は2つあります。最初の方法により、子ゾーンはリゾルバーの検証に「偽」に表示されます。もう1つは、子ゾーンが「不安」に見えるようにします。これらを以下に説明します。
In the method that causes the child zone to appear 'Bogus' to validating resolvers, the child zone replaces the current KSK with a new one and re-signs the key set. Next it sends the DS of the new key to the parent. Only after the parent has placed the new DS in the zone is the child's chain of trust repaired.
子ゾーンがリゾルバーの検証に「偽」に見えるようにする方法では、チャイルドゾーンは現在のKSKを新しいものに置き換え、キーセットを再署名します。次に、新しいキーのDSを親に送信します。親がゾーンに新しいDSを配置した後にのみ、子どもの信頼のチェーンが修復されます。
An alternative method of breaking the chain of trust is by removing the DS RRs from the parent zone altogether. As a result, the child zone would become insecure.
信頼のチェーンを破る別の方法は、親ゾーンからDS RRを完全に削除することです。その結果、子ゾーンは不安定になります。
Primarily because there is no parental interaction required when a ZSK is compromised, the situation is less severe than with a KSK compromise. The zone must still be re-signed with a new ZSK as soon as possible. As this is a local operation and requires no communication between the parent and child, this can be achieved fairly quickly. However, one has to take into account that just as with a normal rollover the immediate disappearance of the old compromised key may lead to verification problems. Also note that as long as the RRSIG over the compromised ZSK is not expired the zone may be still at risk.
主に、ZSKが侵害されたときに親の相互作用が必要ないため、状況はKSKの妥協点よりも深刻ではありません。ゾーンは、できるだけ早く新しいZSKに再署名する必要があります。これはローカル操作であり、親と子の間でコミュニケーションを必要としないため、これはかなり迅速に達成できます。ただし、通常のロールオーバーと同様に、古い侵害されたキーの即時消失が検証の問題につながる可能性があることを考慮する必要があります。また、侵害されたZSK上のRRSIGが有効期限が切れない限り、ゾーンはまだ危険にさらされている可能性があることに注意してください。
A key can also be pre-configured in resolvers. For instance, if DNSSEC is successfully deployed the root key may be pre-configured in most security aware resolvers.
キーは、リゾルバーで事前に構成することもできます。たとえば、DNSSECが正常に展開された場合、ルートキーはほとんどのセキュリティ認識リゾルバーで事前に構成されている可能性があります。
If trust-anchor keys are compromised, the resolvers using these keys should be notified of this fact. Zone administrators may consider setting up a mailing list to communicate the fact that a SEP key is about to be rolled over. This communication will of course need to be authenticated, e.g., by using digital signatures.
信託アンカーキーが侵害されている場合、これらのキーを使用したリゾルバーにこの事実を通知する必要があります。ゾーン管理者は、SEPキーがロールオーバーしようとしているという事実を伝えるために、メーリングリストの設定を検討する場合があります。もちろん、この通信は、たとえば、デジタル署名を使用することにより、認証する必要があります。
End-users faced with the task of updating an anchored key should always validate the new key. New keys should be authenticated out-of-band, for example, through the use of an announcement website that is secured using secure sockets (TLS) [21].
固定されたキーを更新するタスクに直面したエンドユーザーは、常に新しいキーを検証する必要があります。たとえば、セキュアソケット（TLS）を使用して保護されているアナウンスWebサイトの使用を通じて、新しいキーを帯域外に認証する必要があります[21]。
The initial key exchange is always subject to the policies set by the parent. When designing a key exchange policy one should take into account that the authentication and authorization mechanisms used during a key exchange should be as strong as the authentication and authorization mechanisms used for the exchange of delegation information between parent and child. That is, there is no implicit need in DNSSEC to make the authentication process stronger than it was in DNS.
最初のキー交換は、常に親によって設定されたポリシーの対象となります。主要な交換ポリシーを設計する場合、キー交換中に使用される認証と承認のメカニズムは、親と子供の間の委任情報の交換に使用される認証と承認のメカニズムと同じくらい強力でなければならないことを考慮する必要があります。つまり、DNSSECでは、認証プロセスをDNSよりも強力にすることを暗黙のニーズはありません。
Using the DNS itself as the source for the actual DNSKEY material, with an out-of-band check on the validity of the DNSKEY, has the benefit that it reduces the chances of user error. A DNSKEY query tool can make use of the SEP bit [3] to select the proper key from a DNSSEC key set, thereby reducing the chance that the wrong DNSKEY is sent. It can validate the self-signature over a key; thereby verifying the ownership of the private key material. Fetching the DNSKEY from the DNS ensures that the chain of trust remains intact once the parent publishes the DS RR indicating the child is secure.
DNS自体を実際のDNSKEY素材のソースとして使用し、DNSKEYの有効性を帯域外でチェックすることで、ユーザーエラーの可能性を減らすという利点があります。DNSKEYクエリツールは、SEPビット[3]を使用して、DNSSECキーセットから適切なキーを選択することで、間違ったDNSKEYが送信される可能性を減らします。キーを介して自己署名を検証できます。これにより、秘密のキー資料の所有権を検証します。DNSからDNSKEYを取得すると、親がDS RRを公開して子供が安全であることを示すと、信頼のチェーンがそのままであることが保証されます。
Note: the out-of-band verification is still needed when the key material is fetched via the DNS. The parent can never be sure whether or not the DNSKEY RRs have been spoofed.
注：キーマテリアルがDNSを介してフェッチされている場合、帯域外検証が必要です。親は、DNSKEY RRSがスプーフィングされているかどうかを確認することはできません。
When designing a registry system one should consider which of the DNSKEYs and/or the corresponding DSes to store. Since a child zone might wish to have a DS published using a message digest algorithm not yet understood by the registry, the registry can't count on being able to generate the DS record from a raw DNSKEY. Thus, we recommend that registry systems at least support storing DS records.
レジストリシステムを設計するとき、保存するDNSKEYおよび/または対応するDSEのどれを考慮する必要があります。チャイルドゾーンは、レジストリでまだ理解されていないメッセージダイジェストアルゴリズムを使用してDSを公開したい場合があるため、レジストリはRAW DNSKEYからDSレコードを生成できることを期待できません。したがって、レジストリシステムは少なくともDSレコードの保存をサポートすることをお勧めします。
It may also be useful to store DNSKEYs, since having them may help during troubleshooting and, as long as the child's chosen message digest is supported, the overhead of generating DS records from them is minimal. Having an out-of-band mechanism, such as a registry directory (e.g., Whois), to find out which keys are used to generate DS Resource Records for specific owners and/or zones may also help with troubleshooting.
また、DNSKEYSを保存すると便利かもしれません。トラブルシューティング中に役立つ可能性があり、子供が選択したメッセージダイジェストがサポートされている限り、DSレコードを生成するオーバーヘッドは最小限です。レジストリディレクトリ（WHOISなど）などのバンド外のメカニズムがあるため、特定の所有者および/またはゾーンのDSリソースレコードを生成するために使用されるキーを見つけることも、トラブルシューティングに役立つ場合があります。
The storage considerations also relate to the design of the customer interface and the method by which data is transferred between registrant and registry; Will the child zone administrator be able to upload DS RRs with unknown hash algorithms or does the interface only allow DNSKEYs? In the registry-registrar model, one can use the DNSSEC extensions to the Extensible Provisioning Protocol (EPP) [15], which allows transfer of DS RRs and optionally DNSKEY RRs.
ストレージの考慮事項は、顧客インターフェイスの設計と、登録者とレジストリ間でデータが転送される方法にも関連しています。チャイルドゾーン管理者は、不明なハッシュアルゴリズムを使用してDS RRをアップロードできますか、それともインターフェイスはDNSKEYのみを許可しますか？レジストリレジストラモデルでは、DNSSEC拡張機能を拡張可能なプロビジョニングプロトコル（EPP）[15]に使用できます。
Security lameness is defined as what happens when a parent has a DS RR pointing to a non-existing DNSKEY RR. When this happens, the child's zone may be marked "Bogus" by verifying DNS clients.
セキュリティラメネスは、親が存在しないDNSKEY RRを指すDS RRを持っている場合に起こることとして定義されます。これが発生すると、DNSクライアントを検証することにより、子供のゾーンに「偽」とマークされる場合があります。
As part of a comprehensive delegation check, the parent could, at key exchange time, verify that the child's key is actually configured in the DNS. However, if a parent does not understand the hashing algorithm used by child, the parental checks are limited to only comparing the key id.
包括的な委任チェックの一環として、親はキー交換時間に、子供のキーが実際にDNSで構成されていることを確認できます。ただし、親が子供が使用するハッシュアルゴリズムを理解していない場合、親のチェックはキーIDのみを比較するために制限されます。
Child zones should be very careful in removing DNSKEY material, specifically SEP keys, for which a DS RR exists.
子ゾーンは、DSKEYの材料、特にDS RRが存在するSEPキーを削除する際に非常に注意する必要があります。
Once a zone is "security lame", a fix (e.g., removing a DS RR) will take time to propagate through the DNS.
ゾーンが「セキュリティラメ」になると、修正（DS RRを削除するなど）がDNSを介して伝播するのに時間がかかります。
Since the DS can be replayed as long as it has a valid signature, a short signature validity period over the DS minimizes the time a child is vulnerable in the case of a compromise of the child's KSK(s). A signature validity period that is too short introduces the possibility that a zone is marked "Bogus" in case of a configuration error in the signer. There may not be enough time to fix the problems before signatures expire. Something as mundane as operator unavailability during weekends shows the need for DS signature validity periods longer than 2 days. We recommend an absolute minimum for a DS signature validity period of a few days.
DSは有効な署名を持っている限り再生できるため、DSの短い署名の妥当性期間は、子供のKSKの妥協の場合に子供が脆弱である時間を最小限に抑えます。短すぎる署名の妥当性期間は、署名者の構成エラーの場合、ゾーンが「偽」とマークされる可能性を導入します。署名が期限切れになる前に問題を修正するのに十分な時間がないかもしれません。週末にはオペレーターのように平凡なものは、2日以上長いDSの署名妥当性期間が必要であることを示しています。数日間のDS署名妥当性期間については、絶対的な最小値をお勧めします。
The maximum signature validity period of the DS record depends on how long child zones are willing to be vulnerable after a key compromise. On the other hand, shortening the DS signature validity interval increases the operational risk for the parent. Therefore, the parent may have policy to use a signature validity interval that is considerably longer than the child would hope for.
DSレコードの最大署名の妥当性期間は、重要な妥協後に子供ゾーンが脆弱になることをいとわない期間に依存します。一方、DS署名の妥当性間隔を短縮すると、親の運用リスクが高まります。したがって、親は、子供が期待するよりもかなり長い署名の妥当性間隔を使用するポリシーを持っている場合があります。
A compromise between the operational constraints of the parent and minimizing damage for the child may result in a DS signature validity period somewhere between a week and months.
親の運用上の制約と子供の損傷を最小限に抑えることとの間の妥協は、1週間から数か月の間にDS署名の妥当性期間をもたらす可能性があります。
In addition to the signature validity period, which sets a lower bound on the number of times the zone owner will need to sign the zone data and which sets an upper bound to the time a child is vulnerable after key compromise, there is the TTL value on the DS RRs. Shortening the TTL means that the authoritative servers will see more queries. But on the other hand, a short TTL lowers the persistence of DS RRSets in caches thereby increasing the speed with which updated DS RRSets propagate through the DNS.
ゾーン所有者がゾーンデータに署名する必要がある回数の数に下限を設定する署名の妥当性期間に加えて、重要な妥協後に子供が脆弱な時間の上限を設定すると、TTL値がありますDS RRSで。TTLを短縮するということは、権威あるサーバーがより多くのクエリを見ることを意味します。しかし、一方で、短いTTLはキャッシュ中のDS rrsetsの持続性を低下させ、それにより、更新されたDS rrsetsがDNSを通して伝播する速度を高めます。
DNSSEC adds data integrity to the DNS. This document tries to assess the operational considerations to maintain a stable and secure DNSSEC service. Not taking into account the 'data propagation' properties in the DNS will cause validation failures and may make secured zones unavailable to security-aware resolvers.
DNSSECは、DNSにデータの整合性を追加します。このドキュメントは、安定した安全なDNSSECサービスを維持するために、運用上の考慮事項を評価しようとします。DNSの「データ伝播」プロパティを考慮しないと、検証障害が発生し、セキュリティを認識するリゾルバーが保護されたゾーンを利用できなくなる可能性があります。
Most of the ideas in this document were the result of collective efforts during workshops, discussions, and tryouts.
このドキュメントのアイデアのほとんどは、ワークショップ、ディスカッション、トライアウト中の集団的努力の結果でした。
At the risk of forgetting individuals who were the original contributors of the ideas, we would like to acknowledge people who were actively involved in the compilation of this document. In random order: Rip Loomis, Olafur Gudmundsson, Wesley Griffin, Michael Richardson, Scott Rose, Rick van Rein, Tim McGinnis, Gilles Guette Olivier Courtay, Sam Weiler, Jelte Jansen, Niall O'Reilly, Holger Zuleger, Ed Lewis, Hilarie Orman, Marcos Sanz, and Peter Koch.
アイデアの元の貢献者である個人を忘れるリスクがあるため、この文書の編集に積極的に関与していた人々を認めたいと思います。ランダムな順序で：Rip Loomis、Olafur Gudmundsson、Wesley Griffin、Michael Richardson、Scott Rose、Rick Van Rein、Tim McGinnis、Gilles Guette Olivier Courtay、Sam Weiler、Jelte Jansen、Niall O'Reilly、Holger Zuleger、Ed Lewis、Hirarie Orman、マルコス・サンツとピーター・コッホ。
Some material in this document has been copied from RFC 2541 [12].
このドキュメントのいくつかの資料は、RFC 2541 [12]からコピーされています。
Mike StJohns designed the key exchange between parent and child mentioned in the last paragraph of Section 4.2.2
マイク・セントジョンズは、セクション4.2.2の最後の段落で言及された親と子の間の重要な交換を設計しました
Section 4.2.4 was supplied by G. Guette and O. Courtay.
セクション4.2.4は、G。GuetteとO. Courtayによって提供されました。
Emma Bretherick, Adrian Bedford, and Lindy Foster corrected many of the spelling and style issues.
エマ・ブレザリック、エイドリアン・ベッドフォード、リンディ・フォスターは、スペルとスタイルの問題の多くを修正しました。
Kolkman and Gieben take the blame for introducing all miscakes (sic).
コルトマンとギーベンは、すべてのミスケーキ（原文）を導入することで責任を負います。
While working on this document, Kolkman was employed by the RIPE NCC and Gieben was employed by NLnet Labs.
この文書に取り組んでいる間、コルクマンは熟したNCCに雇用され、ギーベンはNLNET Labsに雇用されました。
[1] Mockapetris, P., "Domain names - concepts and facilities", STD 13, RFC 1034, November 1987.
[1] Mockapetris、P。、「ドメイン名 - 概念と施設」、STD 13、RFC 1034、1987年11月。
[2] Mockapetris, P., "Domain names - implementation and specification", STD 13, RFC 1035, November 1987.
[2] Mockapetris、P。、「ドメイン名 - 実装と仕様」、STD 13、RFC 1035、1987年11月。
[3] Kolkman, O., Schlyter, J., and E. Lewis, "Domain Name System KEY (DNSKEY) Resource Record (RR) Secure Entry Point (SEP) Flag", RFC 3757, May 2004.
[3] Kolkman、O.、Schlyter、J。、およびE. Lewis、「ドメイン名システムキー（DNSKEY）リソースレコード（RR）セキュアエントリポイント（SEP）フラグ」、RFC 3757、2004年5月。
[4] Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose, "DNS Security Introduction and Requirements", RFC 4033, March 2005.
[4] Arends、R.、Austein、R.、Larson、M.、Massey、D。、およびS. Rose、「DNSセキュリティの紹介と要件」、RFC 4033、2005年3月。
[5] Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose, "Resource Records for the DNS Security Extensions", RFC 4034, March 2005.
[5] Arends、R.、Austein、R.、Larson、M.、Massey、D。、およびS. Rose、「DNSセキュリティ拡張のリソースレコード」、RFC 4034、2005年3月。
[6] Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose, "Protocol Modifications for the DNS Security Extensions", RFC 4035, March 2005.
[6] Arends、R.、Austein、R.、Larson、M.、Massey、D。、およびS. Rose、「DNSセキュリティ拡張機能のプロトコル変更」、RFC 4035、2005年3月。
[7] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[7] Bradner、S。、「要件レベルを示すためにRFCで使用するためのキーワード」、BCP 14、RFC 2119、1997年3月。
[8] Ohta, M., "Incremental Zone Transfer in DNS", RFC 1995, August 1996.
[8] Ohta、M。、「DNSの増分ゾーン転送」、RFC 1995、1996年8月。
[9] Vixie, P., "A Mechanism for Prompt Notification of Zone Changes (DNS NOTIFY)", RFC 1996, August 1996.
[9] Vixie、P。、「ゾーン変更の迅速な通知のメカニズム（DNS Notify）」、RFC 1996、1996年8月。
[10] Wellington, B., "Secure Domain Name System (DNS) Dynamic Update", RFC 3007, November 2000.
[10] ウェリントン、B。、「セキュアドメイン名システム（DNS）動的更新」、RFC 3007、2000年11月。
[11] Andrews, M., "Negative Caching of DNS Queries (DNS NCACHE)", RFC 2308, March 1998.
[11] Andrews、M。、「DNSクエリのネガティブキャッシュ（DNS ncache）」、RFC 2308、1998年3月。
[12] Eastlake, D., "DNS Security Operational Considerations", RFC 2541, March 1999.
[12] Eastlake、D。、「DNSセキュリティ運用上の考慮事項」、RFC 2541、1999年3月。
[13] Orman, H. and P. Hoffman, "Determining Strengths For Public Keys Used For Exchanging Symmetric Keys", BCP 86, RFC 3766, April 2004.
[13] Orman、H。およびP. Hoffman、「対称キーの交換に使用される公共キーの強度の決定」、BCP 86、RFC 3766、2004年4月。
[14] Eastlake, D., Schiller, J., and S. Crocker, "Randomness Requirements for Security", BCP 106, RFC 4086, June 2005.
[14] Eastlake、D.、Schiller、J。、およびS. Crocker、「セキュリティのランダム性要件」、BCP 106、RFC 4086、2005年6月。
[15] Hollenbeck, S., "Domain Name System (DNS) Security Extensions Mapping for the Extensible Provisioning Protocol (EPP)", RFC 4310, December 2005.
[15] Hollenbeck、S。、「ドメイン名システム（DNS）拡張プロビジョニングプロトコル（EPP）のセキュリティ拡張マッピング」、RFC 4310、2005年12月。
[16] Lenstra, A. and E. Verheul, "Selecting Cryptographic Key Sizes", The Journal of Cryptology 14 (255-293), 2001.
[16] Lenstra、A。and E. Verheul、「暗号化キーサイズの選択」、Journal of Cryptology 14（255-293）、2001。
[17] Schneier, B., "Applied Cryptography: Protocols, Algorithms, and Source Code in C", ISBN (hardcover) 0-471-12845-7, ISBN (paperback) 0-471-59756-2, Published by John Wiley & Sons Inc., 1996.
[17] Schneier、B。、「適用された暗号化：プロトコル、アルゴリズム、およびcのソースコード」、ISBN（ハードカバー）0-471-12845-7、ISBN（ペーパーバック）0-471-59756-2、John Wiley＆Sonsによって発行Inc.、1996年。
[18] Rose, S., "NIST DNSSEC workshop notes", June 2001.
[18] Rose、S。、「Nist DNSSECワークショップノート」、2001年6月。
[19] Jansen, J., "Use of RSA/SHA-256 DNSKEY and RRSIG Resource Records in DNSSEC", Work in Progress, January 2006.
[19] Jansen、J。、「DNSSECでのRSA/SHA-256 DNSKEYおよびRRSIGリソースレコードの使用」、2006年1月、進行中の作業。
[20] Hardaker, W., "Use of SHA-256 in DNSSEC Delegation Signer (DS) Resource Records (RRs)", RFC 4509, May 2006.
[20] Hardaker、W。、「DNSSEC Delegation Signer（DS）Resource Records（RRS）でのSHA-256の使用」、RFC 4509、2006年5月。
[21] Blake-Wilson, S., Nystrom, M., Hopwood, D., Mikkelsen, J., and T. Wright, "Transport Layer Security (TLS) Extensions", RFC 4366, April 2006.
[21] Blake-Wilson、S.、Nystrom、M.、Hopwood、D.、Mikkelsen、J。、およびT. Wright、「Transport Layer Security（TLS）Extensions」、RFC 4366、2006年4月。
In this document, there is some jargon used that is defined in other documents. In most cases, we have not copied the text from the documents defining the terms but have given a more elaborate explanation of the meaning. Note that these explanations should not be seen as authoritative.
このドキュメントには、他のドキュメントで定義されているいくつかの専門用語が使用されています。ほとんどの場合、用語を定義するドキュメントからテキストをコピーしていませんが、意味のより精巧な説明を提供しました。これらの説明は権威あると見なされるべきではないことに注意してください。
Anchored key: A DNSKEY configured in resolvers around the globe. This key is hard to update, hence the term anchored.
固定キー：世界中のリゾルバーで構成されたDNSKEY。このキーは更新するのが難しいため、固定された用語です。
Bogus: Also see Section 5 of [4]. An RRSet in DNSSEC is marked "Bogus" when a signature of an RRSet does not validate against a DNSKEY.
偽：[4]のセクション5も参照してください。DNSSECのRRSetは、RRSETの署名がDNSKEYに対して検証されない場合、「偽」とマークされます。
Key Signing Key or KSK: A Key Signing Key (KSK) is a key that is used exclusively for signing the apex key set. The fact that a key is a KSK is only relevant to the signing tool.
キー署名キーまたはKSK：キー署名キー（KSK）は、Apexキーセットに署名するためだけに使用されるキーです。キーがKSKであるという事実は、署名ツールにのみ関連しています。
Key size: The term 'key size' can be substituted by 'modulus size' throughout the document. It is mathematically more correct to use modulus size, but as this is a document directed at operators we feel more at ease with the term key size.
キーサイズ：「キーサイズ」という用語は、ドキュメント全体の「弾性サイズ」で置き換えることができます。モジュラスサイズを使用する方が数学的には正しいですが、これはオペレーターに向けられたドキュメントであるため、キーサイズという用語により安心感があります。
Private and public keys: DNSSEC secures the DNS through the use of public key cryptography. Public key cryptography is based on the existence of two (mathematically related) keys, a public key and a private key. The public keys are published in the DNS by use of the DNSKEY Resource Record (DNSKEY RR). Private keys should remain private.
プライベートキーおよびパブリックキー：DNSSECは、公開キー暗号化を使用してDNSを保護します。公開キーの暗号化は、2つの（数学的に関連する）キー、公開鍵、秘密鍵の存在に基づいています。パブリックキーは、DNSKEYリソースレコード（DNSKEY RR）を使用してDNSに公開されています。プライベートキーはプライベートのままである必要があります。
Key rollover: A key rollover (also called key supercession in some environments) is the act of replacing one key pair with another at the end of a key effectivity period.
キーロールオーバー：キーロールオーバー（一部の環境ではキースーパーセッションとも呼ばれます）は、キー効果期間の終了時に1つのキーペアを別のキーペアに置き換える行為です。
Secure Entry Point (SEP) key: A KSK that has a parental DS record pointing to it or is configured as a trust anchor. Although not required by the protocol, we recommend that the SEP flag [3] is set on these keys.
セキュアエントリポイント（SEP）キー：それを指している親のDSレコードを持つKSK、または信頼アンカーとして構成されています。プロトコルでは必要ありませんが、これらのキーにSEPフラグ[3]を設定することをお勧めします。
Self-signature: This only applies to signatures over DNSKEYs; a signature made with DNSKEY x, over DNSKEY x is called a self-signature. Note: without further information, self-signatures convey no trust. They are useful to check the authenticity of the DNSKEY, i.e., they can be used as a hash.
自己署名：これは、DNSKEYS上の署名にのみ適用されます。DNSKEY Xを介してDNSKEY Xで作られた署名は、自己署名と呼ばれます。注：詳細がなければ、自己署名は信頼を伝えません。DNSKEYの信ity性を確認するのに役立ちます。つまり、ハッシュとして使用できます。
Singing the zone file: The term used for the event where an administrator joyfully signs its zone file while producing melodic sound patterns.
ゾーンファイルの歌：メロディックサウンドパターンを作成しながら、管理者がゾーンファイルに喜んで署名するイベントに使用される用語。
Signer: The system that has access to the private key material and signs the Resource Record sets in a zone. A signer may be configured to sign only parts of the zone, e.g., only those RRSets for which existing signatures are about to expire.
署名者：秘密のキー資料にアクセスし、ゾーン内のリソースレコードが設定するシステム。署名者は、ゾーンの一部のみに署名するように構成されている場合があります。たとえば、既存の署名が期限切れになっているrrsetのみです。
Zone Signing Key (ZSK): A key that is used for signing all data in a zone. The fact that a key is a ZSK is only relevant to the signing tool.
ゾーン署名キー（ZSK）：ゾーン内のすべてのデータに署名するために使用されるキー。キーがZSKであるという事実は、署名ツールにのみ関連しています。
Zone administrator: The 'role' that is responsible for signing a zone and publishing it on the primary authoritative server.
ゾーン管理者：ゾーンに署名し、プライマリの権威あるサーバーでゾーンを公開する責任がある「役割」。
Using the pre-published signature scheme and the most conservative method to assure oneself that data does not live in caches, here follows the "how-to".
事前に公開された署名スキームと最も保守的な方法を使用して、データがキャッシュに存在しないことを保証するために、ここで「ハウツー」に従います。
Step 0: The preparation: Create two keys and publish both in your key set. Mark one of the keys "active" and the other "published". Use the "active" key for signing your zone data. Store the private part of the "published" key, preferably off-line. The protocol does not provide for attributes to mark a key as active or published. This is something you have to do on your own, through the use of a notebook or key management tool.
ステップ0：準備：2つのキーを作成し、キーセットで両方を公開します。キーの1つを「アクティブ」ともう1つの「公開」マークします。「アクティブ」キーを使用して、ゾーンデータに署名します。「公開された」キーのプライベート部分を保存します。できればオフラインです。このプロトコルは、キーをアクティブまたは公開されたものとしてマークするための属性を提供しません。これは、ノートブックまたはキー管理ツールを使用して、自分でやらなければならないことです。
Step 1: Determine expiration: At the beginning of the rollover make a note of the highest expiration time of signatures in your zone file created with the current key marked as active. Wait until the expiration time marked in Step 1 has passed.
ステップ1：有効期限の決定：ロールオーバーの開始時に、アクティブとしてマークされた現在のキーで作成されたゾーンファイルの署名の有効期限が最も高いことをメモします。ステップ1でマークされた有効期限が過ぎるまで待ちます。
Step 2: Then start using the key that was marked "published" to sign your data (i.e., mark it "active"). Stop using the key that was marked "active"; mark it "rolled".
ステップ2：次に、「公開」とマークされたキーの使用を開始して、データに署名します（つまり、「アクティブ」にマークします）。「アクティブ」とマークされたキーの使用を停止します。「転がった」にマークします。
Step 3: It is safe to engage in a new rollover (Step 1) after at least one signature validity period.
ステップ3：少なくとも1つの署名妥当性期間の後、新しいロールオーバー（ステップ1）に参加することは安全です。
The following typographic conventions are used in this document:
このドキュメントでは、次のタイポグラフィ規則が使用されています。
Key notation: A key is denoted by DNSKEYx, where x is a number or an identifier, x could be thought of as the key id.
キー表記：キーはdnskeyxで示されます。xは数字または識別子であり、xはキーIDと考えることができます。
RRSet notations: RRs are only denoted by the type. All other information -- owner, class, rdata, and TTL--is left out. Thus: "example.com 3600 IN A 192.0.2.1" is reduced to "A". RRSets are a list of RRs. A example of this would be "A1, A2", specifying the RRSet containing two "A" records. This could again be abbreviated to just "A".
RRSET表記：RRSは、タイプでのみ示されます。他のすべての情報（所有者、クラス、RDATA、およびTTL）は除外されています。したがって、「192.0.2.1の例3600」は「A」に縮小されます。RRSetsはRRSのリストです。この例は、「A1、A2」で、2つの「A」レコードを含むRRSETを指定します。これは再び「A」と略される可能性があります。
Signature notation: Signatures are denoted as RRSIGx(RRSet), which means that RRSet is signed with DNSKEYx.
署名表記：署名はRRSIGX（RRSET）として示されます。つまり、RRSetはDNSKeyxで署名されます。
Zone representation: Using the above notation we have simplified the representation of a signed zone by leaving out all unnecessary details such as the names and by representing all data by "SOAx"
ゾーン表現：上記の表記法を使用して、名前などの不要な詳細をすべて除外し、すべてのデータを「SOAX」で表現することにより、署名ゾーンの表現を簡素化しました。
SOA representation: SOAs are represented as SOAx, where x is the serial number.
SOA表現：SOAはSOAXとして表され、Xはシリアル番号です。
Using this notation the following signed zone:
この表記法を使用して、次の署名ゾーンを使用します。
example.net. 86400 IN SOA ns.example.net. bert.example.net. ( 2006022100 ; serial 86400 ; refresh ( 24 hours) 7200 ; retry ( 2 hours) 3600000 ; expire (1000 hours) 28800 ) ; minimum ( 8 hours) 86400 RRSIG SOA 5 2 86400 20130522213204 ( 20130422213204 14 example.net. cmL62SI6iAX46xGNQAdQ... ) 86400 NS a.iana-servers.net. 86400 NS b.iana-servers.net. 86400 RRSIG NS 5 2 86400 20130507213204 ( 20130407213204 14 example.net. SO5epiJei19AjXoUpFnQ ... ) 86400 DNSKEY 256 3 5 ( EtRB9MP5/AvOuVO0I8XDxy0... ) ; id = 14 86400 DNSKEY 257 3 5 ( gsPW/Yy19GzYIY+Gnr8HABU... ) ; id = 15 86400 RRSIG DNSKEY 5 2 86400 20130522213204 ( 20130422213204 14 example.net. J4zCe8QX4tXVGjV4e1r9... )
example.net。86400 in Soa ns.example.net。bert.example.net。（2006022100;シリアル86400;更新（24時間）7200; retry（2時間）3600000;期限切れ（1000時間）28800）;最小（8時間）86400 RRSIG SOA 5 2 86400 201305222213204（201304222213204 14Example.Net。CML62SI6IAX46XGNQADQ...）86400 NS A.IANA-SERVERS.NET。86400 NS B.IANA-SERVERS.NET。86400 RRSIG NS 5 2 86400 20130507213204（20130407213204 14example.net。so5epijei19ajxoupfnq...）86400 dnskey 256 3 5（etrb9mp5/avouvo0i8xdy0 ...）;ID = 14 86400 DNSKEY 257 3 5（GSPW/YY19GZYIY GNR8HABU ...）;ID = 15 86400 RRSIG DNSKEY 5 2 86400 2013052222213204（20130422213204 14Example.Net。J4ZCE8QX4TXVGJV4E1R9...）
86400 RRSIG DNSKEY 5 2 86400 20130522213204 ( 20130422213204 15 example.net. keVDCOpsSeDReyV6O... ) 86400 RRSIG NSEC 5 2 86400 20130507213204 ( 20130407213204 14 example.net. obj3HEp1GjnmhRjX... ) a.example.net. 86400 IN TXT "A label" 86400 RRSIG TXT 5 3 86400 20130507213204 ( 20130407213204 14 example.net. IkDMlRdYLmXH7QJnuF3v... ) 86400 NSEC b.example.com. TXT RRSIG NSEC 86400 RRSIG NSEC 5 3 86400 20130507213204 ( 20130407213204 14 example.net. bZMjoZ3bHjnEz0nIsPMM... ) ...
86400 RRSIG DNSKEY 5 2 86400 20130522213204（2013042222213204 15example.net。kevdcopsedreyv6o...）86400 rrsig nsec 5 2 86400 20130507213204（2013040407213204 14例14例et。86400 in txt "a label" 86400 rrsig txt 5 3 86400 20130507213204（20130407213204 14example.net。ikdmlrdylmxh7qjnuf3v...）86400 nsec b.example.com。TXT RRSIG NSEC 86400 RRSIG NSEC 5 3 86400 20130507213204（20130407213204 14example.net。bzmjoz3bhjnez0nispmm...）...
is reduced to the following representation:
次の表現に還元されます。
SOA2006022100 RRSIG14(SOA2006022100) DNSKEY14 DNSKEY15
SOA2006022100 RRSIG14（SOA2006022100）DNSKEY14 DNSKEY15
RRSIG14(KEY) RRSIG15(KEY)
rrsig14（key）rrsig15（key）
The rest of the zone data has the same signature as the SOA record, i.e., an RRSIG created with DNSKEY 14.
ゾーンデータの残りの部分は、SOAレコードと同じ署名、つまりDNSKEY 14で作成されたRRSIGです。
Authors' Addresses
著者のアドレス
Olaf M. Kolkman NLnet Labs Kruislaan 419 Amsterdam 1098 VA The Netherlands
Olaf M. Kolkman Nlnet Labs Kruislaan 419 Amsterdam 1098 VA The Netherlands
EMail: olaf@nlnetlabs.nl
URI: http://www.nlnetlabs.nl
R. (Miek) Gieben
R.（Miek）Gieben
EMail: miek@miek.nl
Full Copyright Statement
完全な著作権声明
Copyright (C) The Internet Society (2006).
Copyright（c）The Internet Society（2006）。
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 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.
このドキュメントとここに含まれる情報は、「現状のまま」に基づいて提供されています。また、貢献者、彼/彼女が代表する組織（もしあれば）が後援する組織、インターネット協会とインターネット工学タスクフォースは、すべての保証、明示的または明示的、またはすべての保証を否認します。本書の情報の使用が、商品性または特定の目的に対する適合性の権利または黙示的な保証を侵害しないという保証を含むがこれらに限定されないことを含む。
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への情報をお問い合わせください。
Acknowledgement
謝辞
Funding for the RFC Editor function is provided by the IETF Administrative Support Activity (IASA).
RFCエディター機能の資金は、IETF管理サポートアクティビティ（IASA）によって提供されます。