[要約] 要約：RFC 7583は、DNSSECキーロールオーバーのタイミングに関する考慮事項を提供しています。 目的：このRFCの目的は、DNSSECキーロールオーバーのタイミングに関するガイドラインを提供し、セキュリティと信頼性を確保することです。
Internet Engineering Task Force (IETF) S. Morris
Request for Comments: 7583 ISC
Category: Informational J. Ihren
ISSN: 2070-1721 Netnod
J. Dickinson
Sinodun
W. Mekking
Dyn
October 2015
DNSSEC Key Rollover Timing Considerations
DNSSECキーロールオーバーのタイミングに関する考慮事項
Abstract
概要
This document describes the issues surrounding the timing of events in the rolling of a key in a DNSSEC-secured zone. It presents timelines for the key rollover and explicitly identifies the relationships between the various parameters affecting the process.
このドキュメントでは、DNSSECで保護されたゾーンでの鍵のローリングにおけるイベントのタイミングを取り巻く問題について説明します。これは、主要なロールオーバーのタイムラインを示し、プロセスに影響を与えるさまざまなパラメーター間の関係を明示的に識別します。
Status of This Memo
本文書の状態
This document is not an Internet Standards Track specification; it is published for informational purposes.
このドキュメントはInternet Standards Trackの仕様ではありません。情報提供を目的として公開されています。
This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Not all documents approved by the IESG are a candidate for any level of Internet Standard; see Section 2 of RFC 5741.
このドキュメントは、IETF（Internet Engineering Task Force）の製品です。これは、IETFコミュニティのコンセンサスを表しています。公開レビューを受け、インターネットエンジニアリングステアリンググループ（IESG）による公開が承認されました。 IESGによって承認されたすべてのドキュメントが、あらゆるレベルのインターネット標準の候補になるわけではありません。 RFC 5741のセクション2をご覧ください。
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at http://www.rfc-editor.org/info/rfc7583.
このドキュメントの現在のステータス、エラータ、およびフィードバックの提供方法に関する情報は、http：//www.rfc-editor.org/info/rfc7583で入手できます。
Copyright Notice
著作権表示
Copyright (c) 2015 IETF Trust and the persons identified as the document authors. All rights reserved.
Copyright（c）2015 IETF Trustおよびドキュメントの作成者として識別された人物。全著作権所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.
この文書は、BCP 78およびIETF文書に関するIETFトラストの法的規定（http://trustee.ietf.org/license-info）の対象であり、この文書の発行日に有効です。これらのドキュメントは、このドキュメントに関するあなたの権利と制限を説明しているため、注意深く確認してください。このドキュメントから抽出されたコードコンポーネントには、Trust Legal Provisionsのセクション4.eに記載されているSimplified BSD Licenseのテキストが含まれている必要があり、Simplified BSD Licenseに記載されているように保証なしで提供されます。
Table of Contents
目次
1. Introduction ....................................................3
1.1. Key Rolling Considerations .................................3
1.2. Types of Keys ..............................................4
1.3. Terminology ................................................4
1.4. Limitation of Scope ........................................5
2. Rollover Methods ................................................5
2.1. ZSK Rollovers ..............................................5
2.2. KSK Rollovers ..............................................7
3. Key Rollover Timelines ..........................................8
3.1. Key States .................................................8
3.2. ZSK Rollover Timelines ....................................10
3.2.1. Pre-Publication Method .............................10
3.2.2. Double-Signature Method ............................12
3.3. KSK Rollover Timelines ....................................14
3.3.1. Double-KSK Method ..................................14
3.3.2. Double-DS Method ...................................17
3.3.3. Double-RRset Method ................................20
3.3.4. Interaction with Configured Trust Anchors ..........22
3.3.5. Introduction of First Keys .........................24
4. Standby Keys ...................................................24
5. Algorithm Considerations .......................................25
6. Summary ........................................................26
7. Security Considerations ........................................26
8. Normative References ...........................................26
Appendix A. List of Symbols ......................................28
Acknowledgements ..................................................31
Authors' Addresses ................................................31
When a zone is secured with DNSSEC, the zone manager must be prepared to replace ("roll") the keys used in the signing process. The rolling of keys may be caused by compromise of one or more of the existing keys, or it may be due to a management policy that demands periodic key replacement for security or operational reasons. In order to implement a key rollover, the keys need to be introduced into and removed from the zone at the appropriate times. Considerations that must be taken into account are:
ゾーンがDNSSECで保護されている場合、ゾーンマネージャは、署名プロセスで使用されるキーを置き換える（「ロールする」）準備をする必要があります。キーのローリングは、1つ以上の既存のキーの侵害が原因であるか、セキュリティまたは操作上の理由から定期的なキーの交換を要求する管理ポリシーが原因である可能性があります。キーのロールオーバーを実装するには、適切なタイミングでキーをゾーンに導入したり、ゾーンから削除したりする必要があります。考慮しなければならない考慮事項は次のとおりです。
o DNSKEY records and associated information (such as the DS records or RRSIG records created with the key) are not only held at the authoritative nameserver, they are also cached by resolvers. The data on these systems can be interlinked, e.g., a validating resolver may try to validate a signature retrieved from a cache with a key obtained separately.
o DNSKEYレコードと関連情報（DSレコードやキーで作成されたRRSIGレコードなど）は、信頼できるネームサーバーで保持されるだけでなく、リゾルバーによってキャッシュされます。これらのシステム上のデータは相互にリンクすることができます。たとえば、検証リゾルバーは、キャッシュから取得した署名を個別に取得したキーで検証しようとする場合があります。
o Zone "bootstrapping" events, where a zone is signed for the first time, can be common in configurations where a large number of zones are being served. Procedures should be able to cope with the introduction of keys into the zone for the first time as well as "steady-state", where the records are being replaced as part of normal zone maintenance.
o ゾーンが初めて署名されるゾーンの「ブートストラップ」イベントは、多数のゾーンが提供されている構成では一般的です。手順は、ゾーンへのキーの初めての導入と、通常のゾーン保守の一部としてレコードが置き換えられる「定常状態」に対処できる必要があります。
o To allow for an emergency re-signing of the zone as soon as possible after a key compromise has been detected, standby keys (additional keys over and above those used to sign the zone) need to be present.
o キーの危殆化が検出された後、ゾーンの緊急再署名をできるだけ早く許可するには、スタンバイキー（ゾーンへの署名に使用されるもの以上の追加のキー）が存在する必要があります。
o A query for the DNSKEY RRset returns all DNSKEY records in the zone. As there is limited space in the UDP packet (even with EDNS0 support), key records no longer needed must be periodically removed. (For the same reason, the number of standby keys in the zone should be restricted to the minimum required to support the key management policy.)
o DNSKEY RRsetのクエリは、ゾーン内のすべてのDNSKEYレコードを返します。 UDPパケットのスペースは限られているため（EDNS0をサポートしている場合でも）、不要になったキーレコードは定期的に削除する必要があります。 （同じ理由で、ゾーン内のスタンバイキーの数は、キー管理ポリシーをサポートするために必要な最小限に制限する必要があります。）
Management policy, e.g., how long a key is used for, also needs to be considered. However, the point of key management logic is not to ensure that a rollover is completed at a certain time but rather to ensure that no changes are made to the state of keys published in the zone until it is "safe" to do so ("safe" in this context meaning that at no time during the rollover process does any part of the zone ever go bogus). In other words, although key management logic enforces policy, it may not enforce it strictly.
鍵の使用期間などの管理ポリシーも考慮する必要があります。ただし、キー管理ロジックのポイントは、ロールオーバーが特定の時間に完了することを保証することではなく、ゾーンで公開されたキーの状態が「安全」になるまで変更されないようにすることです（ "この文脈での「安全」とは、ロールオーバープロセス中にゾーンのどの部分も決して偽造されないことを意味します）。つまり、キー管理ロジックはポリシーを適用しますが、厳密には適用しない場合があります。
A high-level overview of key rollover can be found in [RFC6781]. In contrast, this document focuses on the low-level timing detail of two classes of operations described there, the rollover of Zone Signing Keys (ZSKs), and the rollover of Key Signing Keys (KSKs).
キーのロールオーバーの概要は[RFC6781]にあります。対照的に、このドキュメントでは、ゾーン署名キー（ZSK）のロールオーバーと、キー署名キー（KSK）のロールオーバーで説明されている2つのクラスの操作の低レベルのタイミングの詳細に焦点を当てています。
Note that the process for the introduction of keys into a zone is different from that of rolling a key; see Section 3.3.5 for more information.
キーをゾーンに導入するプロセスは、キーをローリングするプロセスとは異なることに注意してください。詳細については、セクション3.3.5を参照してください。
Although DNSSEC validation treats all keys equally, [RFC4033] recognizes the broad classification of ZSKs and KSKs. A ZSK is used to authenticate information within the zone; a KSK is used to authenticate the zone's DNSKEY RRset. The main implication for this distinction concerns the consistency of information during a rollover.
DNSSEC検証はすべてのキーを同等に扱いますが、[RFC4033]はZSKとKSKの幅広い分類を認識します。 ZSKは、ゾーン内の情報を認証するために使用されます。 KSKは、ゾーンのDNSKEY RRsetを認証するために使用されます。この違いの主な影響は、ロールオーバー中の情報の一貫性に関係しています。
During operation, a validating resolver must use separate pieces of information to perform an authentication. At the time of authentication, each piece of information may be in its cache or may need to be retrieved from an authoritative server. The rollover process needs to happen in such a way that the information is consistent at all times during the rollover. With a ZSK, the information is the RRSIG (plus associated RRset) and the DNSKEY. These are both obtained from the same zone. In the case of the KSK, the information is the DNSKEY and DS RRset with the latter being obtained from a different zone.
動作中、検証リゾルバーは個別の情報を使用して認証を実行する必要があります。認証時に、各情報はキャッシュにあるか、権限のあるサーバーから取得する必要があります。ロールオーバープロセスは、情報がロールオーバー中に常に一貫するように発生する必要があります。 ZSKの場合、情報はRRSIG（および関連するRRset）とDNSKEYです。これらは両方とも同じゾーンから取得されます。 KSKの場合、情報はDNSKEYとDS RRsetであり、後者は別のゾーンから取得されます。
Although there are similarities in the algorithms to roll ZSKs and KSKs, there are a number of differences. For this reason, the two types of rollovers are described separately.
ZSKとKSKをロールするアルゴリズムには類似点がありますが、いくつかの違いがあります。このため、2種類のロールオーバーは別々に説明されています。
The terminology used in this document is as defined in [RFC4033] and [RFC5011].
このドキュメントで使用されている用語は、[RFC4033]と[RFC5011]で定義されています。
A number of symbols are used to identify times, intervals, etc. All are listed in Appendix A.
時間、間隔などを識別するためにいくつかの記号が使用されています。すべての記号が付録Aにリストされています。
This document represents current thinking at the time of publication. However, the subject matter is evolving and it is not possible for the document to be comprehensive. In particular, it does not cover:
このドキュメントは、発行時の現在の考え方を表しています。ただし、主題は進化しており、ドキュメントを包括的にすることはできません。特に、以下については説明しません。
o Rolling a key that is used as both a ZSK and KSK.
o ZSKとKSKの両方として使用されるキーをローリングします。
o Algorithm rollovers. Only the rolling of keys of the same algorithm is described here: not transitions between algorithms.
o アルゴリズムのロールオーバー。ここでは、同じアルゴリズムのキーのローリングのみを説明します。アルゴリズム間の遷移は説明しません。
o Changing TTLs.
o TTLの変更。
Algorithm rollover is excluded from the document owing to the need for there to be an RRSIG for at least one DNSKEY of each algorithm in the DNSKEY RRset [RFC4035]. This introduces additional constraints on rollovers that are not considered here. Such considerations do not apply where other properties of the key, such as key length, are changed during the rollover: the DNSSEC protocol does not impose any restrictions in these cases.
DNSKEY RRset [RFC4035]の各アルゴリズムの少なくとも1つのDNSKEYにRRSIGが必要なため、アルゴリズムのロールオーバーはドキュメントから除外されています。これは、ここでは考慮されないロールオーバーに追加の制約を導入します。このような考慮事項は、ロールオーバー中にキーの長さなどのキーの他のプロパティが変更される場合には適用されません。これらの場合、DNSSECプロトコルは制限を課しません。
Also excluded from consideration is the effect of changing the Time to Live (TTL) of records in a zone. TTLs can be changed at any time, but doing so around the time of a key rollover may have an impact on event timings. In the timelines below, it is assumed that TTLs are constant.
また、ゾーン内のレコードのTime to Live（TTL）を変更した場合の影響も考慮されません。 TTLはいつでも変更できますが、キーのロールオーバーの前後に変更すると、イベントのタイミングに影響を与える可能性があります。以下のタイムラインでは、TTLは一定であると想定されています。
For ZSKs, the issue for the zone operator/signer is to ensure that any caching validator that has access to a particular signature also has access to the corresponding valid ZSK.
ZSKの場合、ゾーンオペレーター/署名者の問題は、特定の署名にアクセスできるキャッシングバリデーターが、対応する有効なZSKにもアクセスできるようにすることです。
A ZSK can be rolled in one of three ways:
ZSKは、次の3つの方法のいずれかでロールできます。
o Pre-Publication: described in [RFC6781], the new key is introduced into the DNSKEY RRset, which is then re-signed. This state of affairs remains in place for long enough to ensure that any cached DNSKEY RRsets contain both keys. At that point, signatures created with the old key can be replaced by those created with the new key. During the re-signing process (which may or may not be atomic depending on how the zone is managed), it doesn't matter with which key an RRSIG record retrieved by a resolver was created; cached copies of the DNSKEY RRset will contain both the old and new keys.
o 事前公開：[RFC6781]で説明されているように、新しいキーはDNSKEY RRsetに導入され、その後再署名されます。この状況は、キャッシュされたDNSKEY RRsetに両方のキーが含まれることを保証するのに十分な時間、適切に維持されます。その時点で、古いキーで作成された署名は、新しいキーで作成されたものに置き換えることができます。再署名プロセス（ゾーンの管理方法に応じてアトミックである場合とそうでない場合がある）の間、リゾルバーによって取得されたRRSIGレコードがどのキーで作成されたかは問題ではありません。 DNSKEY RRsetのキャッシュされたコピーには、古いキーと新しいキーの両方が含まれます。
Once the zone contains only signatures created with the new key, there is an interval during which RRSIG records created with the old key expire from caches. After this, there will be no signatures anywhere that were created using the old key, and it can be removed from the DNSKEY RRset.
ゾーンに新しいキーで作成された署名のみが含まれるようになると、古いキーで作成されたRRSIGレコードがキャッシュから期限切れになる間隔があります。この後、古いキーを使用して作成された署名はどこにもなくなり、DNSKEY RRsetから削除できます。
o Double-Signature: also mentioned in [RFC6781], this involves introducing the new key into the zone and using it to create additional RRSIG records; the old key and existing RRSIG records are retained. During the period in which the zone is being signed (again, the signing process may not be atomic), validating resolvers are always able to validate RRSIGs: any combination of old and new DNSKEY RRset and RRSIGs allows at least one signature to be validated.
o 二重署名：[RFC6781]でも言及されていますが、これには新しいキーをゾーンに導入し、それを使用して追加のRRSIGレコードを作成することが含まれます。古いキーと既存のRRSIGレコードは保持されます。ゾーンが署名されている間（ここでも、署名プロセスはアトミックでない場合があります）、検証リゾルバーは常にRRSIGを検証できます。新旧のDNSKEY RRsetとRRSIGの任意の組み合わせにより、少なくとも1つの署名を検証できます。
Once the signing process is complete and enough time has elapsed to make sure that all validators that have the DNSKEY and signatures in cache have both the old and new information, the old key and signatures can be removed from the zone. As before, during this period any combination of DNSKEY RRset and RRSIGs will allow validation of at least one signature.
署名プロセスが完了し、DNSKEYと署名がキャッシュにあるすべてのバリデーターに古い情報と新しい情報の両方があることを確認するのに十分な時間が経過したら、古い鍵と署名をゾーンから削除できます。以前と同様に、この期間中、DNSKEY RRsetとRRSIGの任意の組み合わせにより、少なくとも1つの署名の検証が可能になります。
o Double-RRSIG: strictly speaking, the use of the term "Double-Signature" above is a misnomer as the method is not only double signature, it is also double key as well. A true Double-Signature method (here called the Double-RRSIG method) involves introducing new signatures in the zone (while still retaining the old ones) but not introducing the new key.
o Double-RRSIG：厳密に言うと、メソッドは二重署名であるだけでなく、二重鍵でもあるため、上記の「二重署名」という用語の使用は誤称です。真のDouble-Signatureメソッド（ここではDouble-RRSIGメソッドと呼ばれます）では、ゾーンに新しい署名を（古い署名は保持したまま）導入しますが、新しいキーは導入しません。
Once the signing process is complete and enough time has elapsed to ensure that all caches that may contain an RR and associated RRSIG have a copy of both signatures, the key is changed. After a further interval during which the old DNSKEY RRset expires from caches, the old signatures are removed from the zone.
署名プロセスが完了し、RRと関連するRRSIGを含むすべてのキャッシュに両方の署名のコピーがあることを確認するのに十分な時間が経過すると、キーが変更されます。古いDNSKEY RRsetがキャッシュから期限切れになるさらに間隔が経過すると、古い署名はゾーンから削除されます。
Of the three methods, Double-Signature is conceptually the simplest: introduce the new key and new signatures, then approximately one TTL later remove the old key and old signatures. It is also the fastest, but suffers from increasing the size of the zone and the size of responses.
3つの方法のうち、Double-Signatureは概念的に最も単純です。新しい鍵と新しい署名を導入し、その後約1つのTTLで古い鍵と古い署名を削除します。また、これは最速ですが、ゾーンのサイズと応答のサイズを大きくするという問題があります。
Pre-Publication is more complex: introduce the new key, approximately one TTL later sign the records, and approximately one TTL after that remove the old key. It does however keep the zone and response sizes to a minimum.
事前公開はより複雑です。新しいキーを導入し、約1 TTL後にレコードに署名し、その後約1 TTLで古いキーを削除します。ただし、ゾーンと応答のサイズは最小限に抑えられます。
Double-RRSIG is essentially the reverse of Pre-Publication: introduce the new signatures, approximately one TTL later change the key, and approximately one TTL after that remove the old signatures. However, it has the disadvantage of the Pre-Publication method in terms of time taken to perform the rollover, the disadvantage of the Double-Signature rollover in terms of zone and response sizes, and none of the advantages of either. For these reasons, it is unlikely to be used in any real-world situations and so will not be considered further in this document.
Double-RRSIGは基本的に事前公開の逆です。新しい署名を導入し、後で約1 TTLで鍵を変更し、その後約1 TTLで古い署名を削除します。ただし、ロールオーバーの実行にかかる時間の点で事前公開方法の欠点、ゾーンと応答のサイズの点で二重署名のロールオーバーの欠点があり、どちらの利点もありません。これらの理由により、実際の状況で使用される可能性は低いため、このドキュメントではこれ以上検討しません。
In the KSK case, there should be no problem with a caching validator not having access to a signature created with a valid KSK. The KSK is only used for one signature (that over the DNSKEY RRset) and both the key and the signature travel together. Instead, the issue is to ensure that the KSK is trusted.
KSKの場合、キャッシングバリデーターが有効なKSKで作成された署名にアクセスできないという問題はありません。 KSKは1つの署名（DNSKEY RRsetを介したもの）にのみ使用され、鍵と署名の両方が一緒に移動します。代わりに、問題はKSKが信頼されていることを確認することです。
Trust in the KSK is due to either the existence of a signed and validated DS record in the parent zone or an explicitly configured trust anchor. If the former, the rollover algorithm will need to involve the parent zone in the addition and removal of DS records, so timings are not wholly under the control of the zone manager. If the latter, [RFC5011] timings will be needed to roll the keys. (Even in the case where authentication is via a DS record, the zone manager may elect to include [RFC5011] timings in the key rolling process so as to cope with the possibility that the key has also been explicitly configured as a trust anchor.)
KSKでの信頼は、親ゾーンに署名され検証されたDSレコードが存在するか、明示的に構成されたトラストアンカーが原因です。前者の場合、ロールオーバーアルゴリズムはDSレコードの追加と削除に親ゾーンを含める必要があるため、タイミングは完全にゾーンマネージャーの制御下にはありません。後者の場合、[RFC5011]のタイミングでキーをロールする必要があります。 （認証がDSレコードを介して行われる場合でも、ゾーンマネージャは、キーがトラストアンカーとして明示的に構成されている可能性に対処するために、キーローリングプロセスに[RFC5011]タイミングを含めることを選択できます。）
It is important to note that the need to interact with the parent does not preclude the development of key rollover logic; in accordance with the goal of the rollover logic, being able to determine when a state change is "safe", the only effect of being dependent on the parent is that there may be a period of waiting for the parent to respond in addition to any delay the key rollover logic requires. Although this introduces additional delays, even with a parent that is less than ideally responsive, the only effect will be a slowdown in the rollover state transitions. This may cause a policy violation, but will not cause any operational problems.
親と対話する必要があることは、主要なロールオーバーロジックの開発を妨げるものではないことに注意することが重要です。ロールオーバーロジックの目標に従って、状態の変化が「安全」であると判断できる場合、親に依存していることの唯一の効果は、親に応答するのを待機する期間があり、キーロールオーバーロジックに必要な遅延。これにより、追加の遅延が発生しますが、親が理想的な応答性を備えていなくても、ロールオーバー状態の遷移が遅くなるだけの影響があります。これによりポリシー違反が発生する可能性がありますが、運用上の問題は発生しません。
Like the ZSK case, there are three methods for rolling a KSK:
ZSKの場合と同様に、KSKをローリングするには3つの方法があります。
o Double-KSK: the new KSK is added to the DNSKEY RRset, which is then signed with both the old and new key. After waiting for the old RRset to expire from caches, the DS record in the parent zone is changed. After waiting a further interval for this change to be reflected in caches, the old key is removed from the RRset.
o Double-KSK：新しいKSKがDNSKEY RRsetに追加され、古いキーと新しいキーの両方で署名されます。古いRRsetがキャッシュから期限切れになるのを待った後、親ゾーンのDSレコードが変更されます。この変更がキャッシュに反映されるのをさらに待機した後、古いキーはRRsetから削除されます。
o Double-DS: the new DS record is published. After waiting for this change to propagate into caches, the KSK is changed. After a further interval during which the old DNSKEY RRset expires from caches, the old DS record is removed.
o Double-DS：新しいDSレコードが公開されます。この変更がキャッシュに反映されるのを待った後、KSKが変更されます。古いDNSKEY RRsetがキャッシュから期限切れになるさらに間隔が経過すると、古いDSレコードが削除されます。
o Double-RRset: the new KSK is added to the DNSKEY RRset, which is then signed with both the old and new key, and the new DS record is added to the parent zone. After waiting a suitable interval for the old DS and DNSKEY RRsets to expire from caches, the old DNSKEY and DS records are removed.
o Double-RRset：新しいKSKがDNSKEY RRsetに追加されます。これは、古いキーと新しいキーの両方で署名され、新しいDSレコードが親ゾーンに追加されます。古いDSおよびDNSKEY RRsetがキャッシュから期限切れになるまで適切な間隔を待った後、古いDNSKEYおよびDSレコードは削除されます。
In essence, Double-KSK means that the new KSK is introduced first and used to sign the DNSKEY RRset. The DS record is changed, and finally the old KSK is removed. It limits interactions with the parent to a minimum but, for the duration of the rollover, the size of the DNSKEY RRset is increased.
本質的に、Double-KSKは、新しいKSKが最初に導入され、DNSKEY RRsetの署名に使用されることを意味します。 DSレコードが変更され、最後に古いKSKが削除されます。親との対話を最小限に制限しますが、ロールオーバーの間、DNSKEY RRsetのサイズが増加します。
With Double-DS, the order of operations is the other way around: introduce the new DS, change the DNSKEY, then remove the old DS. The size of the DNSKEY RRset is kept to a minimum, but two interactions are required with the parent.
Double-DSでは、操作の順序が逆になります。新しいDSを導入し、DNSKEYを変更してから、古いDSを削除します。 DNSKEY RRsetのサイズは最小限に抑えられますが、親との2つの対話が必要です。
Finally, Double-RRset is the fastest way to roll the KSK, but has the drawbacks of both of the other methods: a larger DNSKEY RRset and two interactions with the parent.
最後に、Double-RRsetはKSKをロールする最も速い方法ですが、他の方法の両方の欠点があります：より大きなDNSKEY RRsetと親との2つの対話。
DNSSEC validation requires both the DNSKEY and information created from it (referred to as "associated data" in this section). In the case of validation of an RR, the data associated with the key is the corresponding RRSIG. Where there is a need to validate a chain of trust, the associated data is the DS record.
DNSSEC検証には、DNSKEYとそれから作成された情報（このセクションでは「関連データ」と呼ばれます）の両方が必要です。 RRの検証の場合、キーに関連付けられたデータは対応するRRSIGです。信頼の連鎖を検証する必要がある場合、関連するデータはDSレコードです。
During the rolling process, keys move through different states. The defined states are:
ローリングプロセス中に、キーはさまざまな状態を移動します。定義されている状態は次のとおりです。
Generated Although keys may be created immediately prior to first use, some implementations may find it convenient to create a pool of keys in one operation and draw from it as required. (Note: such a pre-generated pool must be secured against surreptitious use.) In the timelines below, before the first event, the keys are considered to be created but not yet used: they are said to be in the "Generated" state.
生成されたキーは最初に使用する直前に作成できますが、実装によっては、1回の操作でキーのプールを作成し、必要に応じてそれを使用すると便利な場合があります。 （注：このような事前に生成されたプールは、不正使用から保護する必要があります。）以下のタイムラインでは、最初のイベントの前に、キーは作成されたと見なされますが、まだ使用されていません。「生成済み」状態であると言われます。
Published A key enters the published state when either it or its associated data first appears in the appropriate zone.
公開済みキーまたはその関連データが適切なゾーンに最初に表示されると、キーは公開済み状態になります。
Ready The DNSKEY or its associated data have been published for long enough to guarantee that copies of the key(s) it is replacing (or associated data related to that key) have expired from caches.
準備完了DNSKEYまたはその関連データは、置換されるキー（またはそのキーに関連する関連データ）のコピーがキャッシュから期限切れになることを保証するのに十分な期間公開されています。
Active The data is starting to be used for validation. In the case of a ZSK, it means that the key is now being used to sign RRsets and that both it and the created RRSIGs appear in the zone. In the case of a KSK, it means that it is possible to use it to validate a DNSKEY RRset as both the DNSKEY and DS records are present in their respective zones. Note that when this state is entered, it may not be possible for validating resolvers to use the data for validation in all cases: the zone signing may not have finished or the data might not have reached the resolver because of propagation delays and/or caching issues. If this is the case, the resolver will have to rely on the predecessor data instead.
アクティブデータは検証に使用され始めています。 ZSKの場合、これは、鍵がRRsetの署名に使用されており、それと作成されたRRSIGの両方がゾーンに表示されることを意味します。 KSKの場合は、DNSKEYレコードとDSレコードの両方がそれぞれのゾーンに存在するため、これを使用してDNSKEY RRsetを検証できることを意味します。この状態に入ると、すべてのケースで検証リゾルバーがデータを検証に使用できない場合があることに注意してください。ゾーンの署名が完了していないか、伝播の遅延やキャッシュのためにデータがリゾルバーに到達していない可能性があります。問題。この場合、リゾルバーは代わりに先行データに依存する必要があります。
Retired The data has ceased to be used for validation. In the case of a ZSK, it means that the key is no longer used to sign RRsets. In the case of a KSK, it means that the successor DNSKEY and DS records are in place. In both cases, the key (and its associated data) can be removed as soon as it is safe to do so, i.e., when all validating resolvers are able to use the new key and associated data to validate the zone. However, until this happens, the current key and associated data must remain in their respective zones.
廃止データは検証に使用されなくなりました。 ZSKの場合は、鍵がRRsetへの署名に使用されなくなったことを意味します。 KSKの場合は、後続のDNSKEYおよびDSレコードが配置されていることを意味します。どちらの場合も、安全に削除できるとすぐに、つまりすべての検証リゾルバーが新しいキーと関連データを使用してゾーンを検証できるようになると、キー（およびその関連データ）を削除できます。ただし、これが発生するまで、現在のキーと関連データはそれぞれのゾーンに残っている必要があります。
Dead The key and its associated data are present in their respective zones, but there is no longer information anywhere that requires their presence for use in validation. Hence, they can be removed at any time.
Deadキーとそれに関連するデータはそれぞれのゾーンに存在しますが、検証で使用するためにそれらの存在を必要とする情報はどこにもありません。したがって、それらはいつでも削除できます。
Removed Both the DNSKEY and its associated data have been removed from their respective zones.
削除DNSKEYとその関連データの両方がそれぞれのゾーンから削除されました。
Revoked The DNSKEY is published for a period with the "revoke" bit set as a way of notifying validating resolvers that have configured it as a trust anchor, as used in [RFC5011], that it is about to be removed from the zone. This state is used when [RFC5011] considerations are in effect (see Section 3.3.4).
取り消しDNSKEYは、[RFC5011]で使用されているように、トラストアンカーとして構成されている検証リゾルバーにゾーンから削除されようとしていることを通知する方法として、「取り消し」ビットが設定された期間公開されます。この状態は、[RFC5011]の考慮事項が有効な場合に使用されます（セクション3.3.4を参照）。
The following sections describe the rolling of a ZSK. They show the events in the lifetime of a key (referred to as "key N") and cover its replacement by its successor (key N+1).
次のセクションでは、ZSKのローリングについて説明します。これらは、キーの存続期間中のイベント（「キーN」と呼ばれます）を示し、後継者（キーN + 1）による置き換えをカバーします。
In this method, the new key is introduced into the DNSKEY RRset. After enough time to ensure that any cached DNSKEY RRsets contain both keys, the zone is signed using the new key and the old signatures are removed. Finally, when all signatures created with the old key have expired from caches, the old key is removed.
この方法では、新しいキーがDNSKEY RRsetに導入されます。キャッシュされたDNSKEY RRsetに両方のキーが含まれていることを確認するのに十分な時間の後、ゾーンは新しいキーを使用して署名され、古い署名が削除されます。最後に、古いキーで作成されたすべての署名がキャッシュから期限切れになると、古いキーが削除されます。
The following diagram shows the timeline of a Pre-Publication rollover. Time increases along the horizontal scale from left to right and the vertical lines indicate events in the process. Significant times and time intervals are marked.
次の図は、公開前のロールオーバーのタイムラインを示しています。時間は水平スケールに沿って左から右に増加し、垂直線はプロセス内のイベントを示します。重要な時間と時間間隔がマークされています。
|1| |2| |3| |4| |5| |6| |7| |8|
| | | | | | | |
Key N |<-Ipub->|<--->|<-------Lzsk------>|<-Iret->|<--->|
| | | | | | | |
Key N+1 | | | |<-Ipub->|<-->|<---Lzsk---- - -
| | | | | | | |
Key N Tpub Trdy Tact Tret Tdea Trem
Key N+1 Tpub Trdy Tact
---- Time ---->
Figure 1: Timeline for a Pre-Publication ZSK Rollover
図1：公開前のZSKロールオーバーのタイムライン
Event 1: Key N's DNSKEY record is put into the zone, i.e., it is added to the DNSKEY RRset, which is then re-signed with the currently active KSKs. The time at which this occurs is the publication time (Tpub), and the key is now said to be published. Note that the key is not yet used to sign records.
イベント1：キーNのDNSKEYレコードがゾーンに入れられます。つまり、それはDNSKEY RRsetに追加され、現在アクティブなKSKで再署名されます。これが発生するのは公開時間（Tpub）であり、キーは公開されたと言われています。キーはまだレコードの署名に使用されていないことに注意してください。
Event 2: Before it can be used, the key must be published for long enough to guarantee that any cached version of the zone's DNSKEY RRset includes this key.
イベント2：それを使用する前に、ゾーンのDNSKEY RRsetのキャッシュバージョンにこのキーが含まれることを保証するのに十分な期間、キーを公開する必要があります。
This interval is the publication interval (Ipub) and, for the second or subsequent keys in the zone, is given by:
この間隔は公開間隔（Ipub）であり、ゾーンの2番目以降のキーの場合、次のように指定されます。
Ipub = Dprp + TTLkey
Ipub = Dprp + TTLkey
Here, Dprp is the propagation delay -- the time taken for a change introduced at the master to replicate to all nameservers. TTLkey is the TTL for the DNSKEY records in the zone. The sum is therefore the maximum time taken for existing DNSKEY records to expire from caches, regardless of the nameserver from which they were retrieved.
ここで、Dprpは伝播遅延、つまりマスターで導入された変更がすべてのネームサーバーに複製されるのにかかる時間です。 TTLkeyは、ゾーン内のDNSKEYレコードのTTLです。したがって、合計は、取得元のネームサーバーに関係なく、既存のDNSKEYレコードがキャッシュから期限切れになるまでの最大時間です。
(The case of introducing the first ZSK into the zone is discussed in Section 3.3.5.)
（最初のZSKをゾーンに導入する場合については、セクション3.3.5で説明します。）
After a delay of Ipub, the key is said to be ready and could be used to sign records. The time at which this event occurs is key N's ready time (Trdy), which is given by:
Ipubの遅延後、キーは準備ができていると言われ、レコードの署名に使用できます。このイベントが発生する時間は、キーNの準備時間（Trdy）であり、次のように指定されます。
Trdy(N) = Tpub(N) + Ipub
Event 3: At some later time, the key starts being used to sign RRsets. This point is the activation time (Tact) and after this, key N is said to be active.
イベント3：しばらくして、鍵がRRsetへの署名に使用されるようになります。この時点がアクティブ化時間（Tact）であり、この後、キーNはアクティブであると言われます。
Tact(N) >= Trdy(N)
Event 4: At some point thought must be given to its successor (key N+1). As with the introduction of the currently active key into the zone, the successor key will need to be published at least Ipub before it is activated. The publication time of key N+1 depends on the activation time of key N:
イベント4：ある時点で、後継者（キーN + 1）に考えを与える必要があります。現在アクティブなキーをゾーンに導入する場合と同様に、後続キーは、アクティブ化する前に少なくともIpubを公開する必要があります。キーN + 1の公開時間は、キーNのアクティブ化時間によって異なります。
Tpub(N+1) <= Tact(N) + Lzsk - Ipub
Here, Lzsk is the length of time for which a ZSK will be used (the ZSK lifetime). It should be noted that in the diagrams, the actual key lifetime is represented; this may differ slightly from the intended lifetime set by key management policy.
ここで、LzskはZSKが使用される時間の長さ（ZSK寿命）です。図では、実際のキーの有効期間が表されていることに注意してください。これは、キー管理ポリシーによって設定された予定のライフタイムとは少し異なる場合があります。
Event 5: While key N is still active, its successor becomes ready. From this time onwards, key N+1 could be used to sign the zone.
イベント5：キーNがまだアクティブな間、その後続が準備されます。この時点以降、キーN + 1を使用してゾーンに署名できます。
Event 6: When key N has been in use for an interval equal to the ZSK lifetime, it is retired (i.e., it will never again be used to generate new signatures) and key N+1 activated and used to sign the zone. This is the retire time of key N (Tret), and is given by:
イベント6：キーNがZSKライフタイムと等しい間隔で使用されている場合、キーNは廃棄され（つまり、新しい署名の生成に再び使用されることはありません）、キーN + 1がアクティブ化され、ゾーンの署名に使用されます。これはキーN（Tret）のリタイア時間であり、次の式で与えられます。
Tret(N) = Tact(N) + Lzsk
It is also the activation time of the successor key N+1. Note that operational considerations may cause key N to remain in use for a longer (or shorter) time than the lifetime set by the key management policy.
これは、後続キーN + 1のアクティブ化時間でもあります。運用上の考慮事項により、キーNが、キー管理ポリシーによって設定されたライフタイムよりも長い（または短い）時間使用される可能性があることに注意してください。
Event 7: The retired key needs to be retained in the zone whilst any RRSIG records created using this key are still published in the zone or held in caches. (It is possible that a validating resolver could have an old RRSIG record in the cache, but the old DNSKEY RRset has expired when it is asked to provide both to a client. In this case the DNSKEY RRset would need to be looked up again.) This means that once the key is no longer used to sign records, it should be retained in the zone for at least the retire interval (Iret) given by:
イベント7：このキーを使用して作成されたRRSIGレコードがゾーンで公開されているか、キャッシュに保持されている間、廃止されたキーをゾーンに保持する必要があります。 （検証リゾルバーがキャッシュに古いRRSIGレコードを持っている可能性がありますが、クライアントに両方を提供するように要求されたときに古いDNSKEY RRsetが期限切れになりました。この場合、DNSKEY RRsetを再度検索する必要があります。 ）これは、キーがレコードの署名に使用されなくなったら、少なくとも次の式で与えられるリタイア間隔（Iret）の間、ゾーンに保持する必要があることを意味します。
Iret = Dsgn + Dprp + TTLsig
Dsgn is the delay needed to ensure that all existing RRsets have been re-signed with the new key. Dprp is the propagation delay, required to guarantee that the updated zone information has reached all slave servers, and TTLsig is the maximum TTL of all the RRSIG records in the zone created with the retiring key.
Dsgnは、既存のすべてのRRsetが新しいキーで再署名されていることを確認するために必要な遅延です。 Dprpは伝播遅延であり、更新されたゾーン情報がすべてのスレーブサーバーに到達したことを保証するために必要です。TTLsigは、廃止キーで作成されたゾーン内のすべてのRRSIGレコードの最大TTLです。
The time at which all RRSIG records created with this key have expired from resolver caches is the dead time (Tdea), given by:
このキーで作成されたすべてのRRSIGレコードがリゾルバーキャッシュから期限切れになる時間は、次のようにデッドタイム（Tdea）です。
Tdea(N) = Tret(N) + Iret
... at which point the key is said to be dead.
...その時点で鍵は死んでいると言われています。
Event 8: At any time after the key becomes dead, it can be removed from the zone's DNSKEY RRset, which must then be re-signed with the current KSK. This time is the removal time (Trem), given by:
イベント8：キーが無効になった後はいつでも、ゾーンのDNSKEY RRsetから削除できます。これは、現在のKSKで再署名する必要があります。今回は除去時間（Trem）であり、次の式で与えられます。
Trem(N) >= Tdea(N)
... at which time the key is said to be removed.
...その時点でキーは削除されたと言われます。
In this rollover, a new key is introduced and used to sign the zone; the old key and signatures are retained. Once all cached DNSKEY and/ or RRSIG information contains copies of the new DNSKEY and RRSIGs created with it, the old DNSKEY and RRSIGs can be removed from the zone.
このロールオーバーでは、新しいキーが導入され、ゾーンの署名に使用されます。古い鍵と署名は保持されます。キャッシュされたすべてのDNSKEYおよび/またはRRSIG情報に、それを使用して作成された新しいDNSKEYおよびRRSIGのコピーが含まれると、古いDNSKEYおよびRRSIGをゾーンから削除できます。
The timeline for a Double-Signature rollover is shown below. The diagram follows the convention described in Section 3.2.1.
二重署名ロールオーバーのタイムラインを以下に示します。図は、セクション3.2.1で説明されている規則に従います。
|1| |2| |3| |4|
| | | |
Key N |<-------Lzsk----------->|<--->|
| | | |
| |<--Iret-->| |
| | | |
Key N+1 | |<----Lzsk------- - -
| | | |
Key N Tact Tdea Trem
Key N+1 Tact
---- Time ---->
Figure 2: Timeline for a Double-Signature ZSK Rollover
図2：二重署名ZSKロールオーバーのタイムライン
Event 1: Key N is added to the DNSKEY RRset and is then used to sign the zone; existing signatures in the zone are not removed. The key is published and active: this is key N's activation time (Tact), after which the key is said to be active.
イベント1：キーNがDNSKEY RRsetに追加され、ゾーンの署名に使用されます。ゾーン内の既存の署名は削除されません。キーは公開されてアクティブです。これはキーNのアクティブ化時間（Tact）であり、その後キーはアクティブであると言われます。
Event 2: As the current key (key N) approaches the end of its actual lifetime (Lzsk), the successor key (key N+1) is introduced into the zone and starts being used to sign RRsets: neither the current key nor the signatures created with it are removed. The successor key is now also active.
イベント2：現在のキー（キーN）が実際の有効期間（Lzsk）の終わりに近づくと、後続のキー（キーN + 1）がゾーンに導入され、RRsetへの署名に使用され始めます。現在のキーもそれで作成された署名は削除されます。後続キーもアクティブになりました。
Tact(N+1) = Tact(N) + Lzsk - Iret
Event 3: Before key N can be withdrawn from the zone, all RRsets that need to be signed must have been signed by the successor key (key N+1) and any old RRsets that do not include the new key or new RRSIGs must have expired from caches. Note that the signatures are not replaced: each RRset is signed by both the old and new key.
イベント3：キーNをゾーンから撤回する前に、署名が必要なすべてのRRsetが後続キー（キーN + 1）によって署名されている必要があり、新しいキーまたは新しいRRSIGを含まない古いRRsetは、キャッシュから期限切れ。署名は置き換えられないことに注意してください。各RRsetは古いキーと新しいキーの両方で署名されています。
This takes Iret, the retire interval, given by the expression:
これは、次の式で与えられるIret、リタイア間隔を取ります。
Iret = Dsgn + Dprp + max(TTLkey, TTLsig)
As before, Dsgn is the delay needed to ensure that all existing RRsets have been signed with the new key and Dprp is the propagation delay, required to guarantee that the updated zone information has reached all slave servers. The final term (the maximum of TTLkey and TTLsig) is the period to wait for key and signature data associated with key N to expire from caches. (TTLkey is the TTL of the DNSKEY RRset and TTLsig is the maximum TTL of all the RRSIG records in the zone created with the ZSK. The two may be different: although the TTL of an RRSIG is equal to the TTL of the RRs in the associated RRset [RFC4034], the DNSKEY RRset only needs to be signed with the KSK.)
以前と同様に、Dsgnは既存のすべてのRRsetが新しいキーで署名されていることを確認するために必要な遅延であり、Dprpは更新されたゾーン情報がすべてのスレーブサーバーに到達したことを保証するために必要な伝播遅延です。最後の用語（TTLkeyとTTLsigの最大値）は、キーNに関連付けられたキーと署名データがキャッシュから期限切れになるのを待つ期間です。 （TTLkeyはDNSKEY RRsetのTTLであり、TTLsigはZSKで作成されたゾーン内のすべてのRRSIGレコードの最大TTLです。2つは異なる場合があります。RRSIGのTTLは、関連するRRset [RFC4034]、DNSKEY RRsetはKSKで署名する必要があるだけです。）
At the end of this interval, key N is said to be dead. This occurs at the dead time (Tdea) so:
この間隔の終わりに、キーNは死んでいると言われます。これはデッドタイム（Tdea）で発生するため、次のようになります。
Tdea(N) = Tact(N+1) + Iret
Event 4: At some later time, key N and the signatures generated with it can be removed from the zone. This is the removal time (Trem), given by:
イベント4：後で、キーNとそれを使用して生成された署名をゾーンから削除できます。これは、以下によって与えられる除去時間（Trem）です。
Trem(N) >= Tdea(N)
The following sections describe the rolling of a KSK. They show the events in the lifetime of a key (referred to as "key N") and cover it replacement by its successor (key N+1). (The case of introducing the first KSK into the zone is discussed in Section 3.3.5.)
次のセクションでは、KSKのローリングについて説明します。これらは、キーの有効期間中のイベント（「キーN」と呼ばれます）を示し、後継者（キーN + 1）による交換をカバーします。 （最初のKSKをゾーンに導入する場合については、セクション3.3.5で説明します。）
In this rollover, the new DNSKEY is added to the zone. After an interval long enough to guarantee that any cached DNSKEY RRsets contain the new DNSKEY, the DS record in the parent zone is changed. After a further interval to allow the old DS record to expire from caches, the old DNSKEY is removed from the zone.
このロールオーバーでは、新しいDNSKEYがゾーンに追加されます。キャッシュされたDNSKEY RRsetに新しいDNSKEYが含まれることを保証するのに十分な間隔が経過すると、親ゾーンのDSレコードが変更されます。キャッシュから古いDSレコードが期限切れになるまでの間隔がさらに経過すると、古いDNSKEYがゾーンから削除されます。
The timeline for a Double-KSK rollover is shown below. The diagram follows the convention described in Section 3.2.1.
Double-KSKロールオーバーのタイムラインを以下に示します。図は、セクション3.2.1で説明されている規則に従います。
|1| |2| |3| |4|
| | | |
Key N |<-IpubC->|<--->|<-Dreg->|<-----Lksk--- - -
| | | |
Key N+1 | | | |
| | | |
Key N Tpub Trdy Tsbm Tact
Key N+1
---- Time ---->
(continued ...)
（続き...）
|5| |6| |7| |8| |9| |10|
| | | | | |
Key N - - --------------Lksk------->|<-Iret->|<----->|
| | | | | |
Key N+1 |<-IpubC->|<--->|<-Dreg->|<--------Lksk----- - -
| | | | | |
Key N Tret Tdea Trem
Key N+1 Tpub Trdy Tsbm Tact
---- Time (cont.) ---->
Figure 3: Timeline for a Double-KSK Rollover
図3：ダブルKSKロールオーバーのタイムライン
Event 1: Key N is introduced into the zone; it is added to the DNSKEY RRset, which is then signed by all currently active KSKs. (So at this point, the DNSKEY RRset is signed by both key N and its predecessor KSK. If other KSKs were active, it is signed by these as well.) This is the publication time of key N (Tpub); after this, the key is said to be published.
イベント1：キーNがゾーンに導入されます。 DNSKEY RRsetに追加され、現在アクティブなすべてのKSKによって署名されます。 （したがって、この時点では、DNSKEY RRsetはキーNとその先行KSKの両方によって署名されています。他のKSKがアクティブだった場合は、これらも署名されます。）これはキーN（Tpub）の公開時間です。この後、キーが公開されると言われています。
Event 2: Before it can be used, the key must be published for long enough to guarantee that any validating resolver that has a copy of the DNSKEY RRset in its cache will have a copy of the RRset that includes this key: in other words, that any prior cached information about the DNSKEY RRset has expired.
イベント2：キーを使用する前に、DNSKEY RRsetのコピーがキャッシュにある検証リゾルバーがこのキーを含むRRsetのコピーを持つことを保証するのに十分な期間、キーを公開する必要があります。つまり、 DNSKEY RRsetに関する以前のキャッシュ情報の有効期限が切れていること。
The interval is the publication interval in the child zone (IpubC) and is given by:
間隔は、子ゾーン（IpubC）での発行間隔であり、次のように指定されます。
IpubC = DprpC + TTLkey
IpubC = DprpC + TTLkey
... where DprpC is the propagation delay for the child zone (the zone containing the KSK being rolled) and TTLkey the TTL for the DNSKEY RRset. The time at which this occurs is the key N's ready time, Trdy, given by:
...ここで、DprpCは子ゾーン（ロールされるKSKを含むゾーン）の伝搬遅延であり、TTLkeyはDNSKEY RRsetのTTLです。これが発生する時刻が、Nの準備時間であるTrdyです。
Trdy(N) = Tpub(N) + IpubC
Event 3: At some later time, the DS record corresponding to the new KSK is submitted to the parent zone for publication. This time is the submission time, Tsbm:
イベント3：後で、新しいKSKに対応するDSレコードが公開のために親ゾーンに送信されます。今回は提出時間です、Tsbm：
Tsbm(N) >= Trdy(N)
Event 4: The DS record is published in the parent zone. As this is the point at which all information for authentication -- both DNSKEY and DS record -- is available in the two zones, in analogy with other rollover methods, this is called the activation time of key N (Tact):
イベント4：DSレコードは親ゾーンで公開されます。これは、認証に関するすべての情報（DNSKEYとDSレコードの両方）が2つのゾーンで利用できるようになる時点であるため、他のロールオーバー方法と同様に、これはキーN（タクト）のアクティブ化時間と呼ばれます。
Tact(N) = Tsbm(N) + Dreg
... where Dreg is the registration delay, the time taken after the DS record has been submitted to the parent zone manager for it to be placed in the zone. (Parent zones are often managed by different entities, and this term accounts for the organizational overhead of transferring a record. In practice, Dreg will not be a fixed time: instead, the end of Dreg will be signaled by the appearance of the DS record in the parent zone.)
... Dregは登録遅延であり、DSレコードがゾーンに配置されるためにDSレコードが親ゾーンマネージャーに送信されてから経過した時間です。 （親ゾーンはさまざまなエンティティによって管理されることが多く、この用語はレコードを転送するための組織的なオーバーヘッドを説明します。実際には、Dregは決まった時間ではありません。代わりに、DSレコードの出現によってDregの終わりが通知されます親ゾーンで。）
Event 5: While key N is active, thought needs to be given to its successor (key N+1). At some time before the scheduled end of the KSK lifetime, the successor KSK is published in the zone. (As before, this means that the DNSKEY RRset is signed by all KSKs.) This time is the publication time of the successor key N+1, given by:
イベント5：キーNがアクティブである間、その後続（キーN + 1）を考慮する必要があります。 KSKライフタイムの予定された終了前のある時点で、後続のKSKがゾーンで公開されます。 （以前と同様に、これはDNSKEY RRsetがすべてのKSKによって署名されることを意味します。）これは、次のように与えられる後続キーN + 1の公開時間です。
Tpub(N+1) <= Tact(N) + Lksk - Dreg - IpubC
... where Lksk is the actual lifetime of the KSK, and Dreg the registration delay.
...ここで、LkskはKSKの実際の寿命であり、Dregは登録遅延です。
Event 6: After an interval IpubC, key N+1 becomes ready (in that all caches that have a copy of the DNSKEY RRset have a copy of this key). This time is the ready time of the successor key N+1 (Trdy).
イベント6：間隔IpubCの後、キーN + 1が準備されます（DNSKEY RRsetのコピーを持つすべてのキャッシュにこのキーのコピーがあるため）。この時間は、後続キーN + 1（Trdy）の準備時間です。
Event 7: At the submission time of the successor key N+1, Tsbm(N+1), the DS record corresponding to key N+1 is submitted to the parent zone.
イベント7：後続キーN + 1、Tsbm（N + 1）の送信時に、キーN + 1に対応するDSレコードが親ゾーンに送信されます。
Event 8: The successor DS record is published in the parent zone and the current DS record withdrawn. Key N is said to be retired and the time at which this occurs is Tret(N), given by:
イベント8：後続のDSレコードが親ゾーンで公開され、現在のDSレコードが撤回されました。キーNはリタイアしていると言われ、これが発生する時間はTret（N）で、次のように与えられます。
Tret(N) = Tsbm(N+1) + Dreg
Event 9: Key N must remain in the zone until any caches that contain a copy of the DS RRset have a copy containing the new DS record. This interval is the retire interval, given by:
イベント9：DS RRsetのコピーを含むすべてのキャッシュが新しいDSレコードを含むコピーを持つまで、キーNはゾーンにとどまる必要があります。この間隔は、次によって与えられるリタイア間隔です。
Iret = DprpP + TTLds
DprpP go = + ttldi
... where DprpP is the propagation delay in the parent zone and TTLds the TTL of a DS record in the parent zone.
...ここで、DprpPは親ゾーンでの伝播遅延であり、TTLdsは親ゾーンでのDSレコードのTTLです。
As the key is no longer used for anything, it is said to be dead. This point is the dead time (Tdea), given by:
キーは何にも使用されなくなったため、使用されていないと言われています。この点は、次のように与えられるむだ時間（Tdea）です。
Tdea(N) = Tret(N) + Iret
Event 10: At some later time, key N is removed from the zone's DNSKEY RRset (at the remove time Trem); the key is now said to be removed.
イベント10：しばらくして、キーNがゾーンのDNSKEY RRsetから削除されます（削除時刻Tremに）。キーは削除されたと言われています。
Trem(N) >= Tdea(N)
In this rollover, the new DS record is published in the parent zone. When any caches that contain the DS RRset contain a copy of the new record, the KSK in the zone is changed. After a further interval for the old DNSKEY RRset to expire from caches, the old DS record is removed from the parent.
このロールオーバーでは、新しいDSレコードが親ゾーンで公開されます。 DS RRsetを含むキャッシュに新しいレコードのコピーが含まれている場合、ゾーンのKSKが変更されます。さらに古いDNSKEY RRsetがキャッシュから期限切れになるまでの間隔が経過すると、古いDSレコードが親から削除されます。
The timeline for a Double-DS rollover is shown below. The diagram follows the convention described in Section 3.2.1.
Double-DSロールオーバーのタイムラインを以下に示します。図は、セクション3.2.1で説明されている規則に従います。
|1| |2| |3| |4| |5|
| | | | |
Key N |<-Dreg->|<-IpubP->|<-->|<-------Lksk---- - -
| | | | |
Key N+1 | | | | |<--Dreg-- - -
| | | | |
Key N Tsbm Tpub Trdy Tact
Key N+1 Tsbm
---- Time ---->
(continued ...)
（続き...）
|6| |7| |8| |9| |10|
| | | | |
Key N - ----------Lksk--------->|<-Iret->|<---->|
| | | | |
Key N+1 - --Dreg-->|<-IpubP->|<-->|<---Lksk------- - -
| | | | |
Key N Tret Tdea Trem
Key N+1 Tpub Trdy Tact
---- Time ---->
Figure 4: Timeline for a Double-DS KSK Rollover
図4：Double-DS KSKロールオーバーのタイムライン
Event 1: The DS RR is submitted to the parent zone for publication. This time is the submission time, Tsbm.
イベント1：DS RRは公開のために親ゾーンに送信されます。今回は提出時間です、Tsbm。
Event 2: After the registration delay, Dreg, the DS record is published in the parent zone. This is the publication time (Tpub) of key N, given by:
イベント2：登録の遅延後、Dreg、DSレコードは親ゾーンで公開されます。これは、キーNの公開時刻（Tpub）であり、次の式で与えられます。
Tpub(N) = Tsbm(N) + Dreg
As before, in practice, Dreg will not be a fixed time. Instead, the end of Dreg will be signaled by the appearance of the DS record in the parent zone.
以前と同様に、実際には、Dregは決まった時間ではありません。代わりに、Dregの終了は、親ゾーンのDSレコードの出現によって通知されます。
Event 3: At some later time, any cache that has a copy of the DS RRset will have a copy of the DS record for key N. At this point, key N, if introduced into the DNSKEY RRset, could be used to validate the zone. For this reason, this time is known as the ready time, Trdy, and is given by:
イベント3：しばらくして、DS RRsetのコピーを持つキャッシュには、キーNのDSレコードのコピーが作成されます。この時点で、DNSKEY RRsetに導入されたキーNを使用して、ゾーン。このため、この時間は準備完了時間Trdyと呼ばれ、次の式で与えられます。
Trdy(N) = Tpub(N) + IpubP
IpubP is the publication interval of the DS record (in the parent zone) and is given by the expression:
IpubPは（親ゾーン内の）DSレコードの公開間隔であり、次の式で指定されます。
IpubP = DprpP + TTLds
IpubP = DprpP + TTLds
... where DprpP is the propagation delay for the parent zone and TTLds the TTL assigned to DS records in that zone.
... DprpPは親ゾーンの伝搬遅延であり、TTLdsはそのゾーンのDSレコードに割り当てられたTTLです。
Event 4: At some later time, the key rollover takes place and the new key (key N) is introduced into the DNSKEY RRset and used to sign it. This time is key N's activation time (Tact) and at this point key N is said to be active:
イベント4：後で、キーのロールオーバーが行われ、新しいキー（キーN）がDNSKEY RRsetに導入され、それを署名するために使用されます。この時間がキーNのアクティブ化時間（タクト）であり、この時点でキーNはアクティブであると言われます。
Tact(N) >= Trdy(N)
Event 5: At some point, thought must be given to key replacement. The DS record for the successor key must be submitted to the parent zone at a time such that when the current key is withdrawn, any cache that contains the zone's DS records has data about the DS record of the successor key. The time at which this occurs is the submission time of the successor key N+1, given by:
イベント5：ある時点で、キーの交換を検討する必要があります。後続キーのDSレコードは、現在のキーが取り消されたときに、ゾーンのDSレコードを含むキャッシュに後続キーのDSレコードに関するデータが含まれるように、一度に親ゾーンに送信する必要があります。これが発生する時刻は、後続キーN + 1の送信時刻です。
Tsbm(N+1) <= Tact(N) + Lksk - IpubP - Dreg
... where Lksk is the actual lifetime of key N (which may differ slightly from the lifetime set in the key management policy) and Dreg is the registration delay.
...ここで、LkskはキーNの実際の有効期間（キー管理ポリシーで設定された有効期間とわずかに異なる場合があります）であり、Dregは登録遅延です。
Event 6. After an interval Dreg, the successor DS record is published in the zone.
イベント6.間隔Dregの後、後続のDSレコードがゾーンで公開されます。
Event 7: The successor key (key N+1) enters the ready state, i.e., its DS record is now in caches that contain the parent DS RRset.
イベント7：サクセサーキー（キーN + 1）が準備完了状態になります。つまり、そのDSレコードは、親DS RRsetを含むキャッシュにあります。
Event 8: When key N has been active for its lifetime (Lksk), it is replaced in the DNSKEY RRset by key N+1; the RRset is then signed with the new key. At this point, as both the old and new DS records have been in the parent zone long enough to ensure that they are in caches that contain the DS RRset, the zone can be authenticated throughout the rollover. A validating resolver can authenticate either the old or new KSK.
イベント8：キーNがその有効期間（Lksk）の間アクティブである場合、DNSKEY RRsetでキーN + 1に置き換えられます。次に、RRsetは新しい鍵で署名されます。この時点では、古いDSレコードと新しいDSレコードの両方が親ゾーンにあり、DS RRsetを含むキャッシュ内にあることを保証するのに十分な長さがあるため、ロールオーバー全体でゾーンを認証できます。検証リゾルバは、古いまたは新しいKSKを認証できます。
This time is the retire time (Tret) of key N, given by:
今回は、キーNのリタイア時間（Tret）であり、次の式で与えられます。
Tret(N) = Tact(N) + Lksk
This is also the activation time of the successor key N+1.
これは、後続キーN + 1のアクティブ化時間でもあります。
Event 9: At some later time, all copies of the old DNSKEY RRset have expired from caches and the old DS record is no longer needed. In analogy with other rollover methods, this is called the dead time, Tdea, and is given by:
イベント9：後で、古いDNSKEY RRsetのすべてのコピーがキャッシュから期限切れになり、古いDSレコードは不要になります。他のロールオーバー方法と同様に、これはむだ時間Tdeaと呼ばれ、次の式で与えられます。
Tdea(N) = Tret(N) + Iret
... where Iret is the retire interval of the key, given by:
...ここで、Iretは次の式で与えられるキーのリタイア間隔です。
Iret = DprpC + TTLkey
DprpC go = + TTLキー
As before, this term includes DprpC, the time taken to propagate the RRset change through the master-slave hierarchy of the child zone and TTLkey, the time taken for the DNSKEY RRset to expire from caches.
以前と同様に、この用語には、DprpC（子ゾーンのマスタースレーブ階層とRRkeyの変更をRRsetの変更に反映するのにかかる時間、DNSKEY RRsetがキャッシュから期限切れになるのにかかる時間）が含まれます。
Event 10: At some later time, the DS record is removed from the parent zone. In analogy with other rollover methods, this is the removal time (Trem), given by:
イベント10：しばらくして、DSレコードが親ゾーンから削除されます。他のロールオーバー方法と同様に、これは除去時間（Trem）であり、次の式で与えられます。
Trem(N) >= Tdea(N)
In the Double-RRset rollover, the new DNSKEY and DS records are published simultaneously in the appropriate zones. Once enough time has elapsed for the old DNSKEY and DS RRsets to expire from caches, the old DNSKEY and DS records are removed from their respective zones.
Double-RRsetロールオーバーでは、新しいDNSKEYおよびDSレコードが適切なゾーンで同時に公開されます。古いDNSKEYおよびDS RRsetがキャッシュから期限切れになるのに十分な時間が経過すると、古いDNSKEYおよびDSレコードはそれぞれのゾーンから削除されます。
The timeline for this rollover is shown below. The diagram follows the convention described in Section 3.2.1.
このロールオーバーのタイムラインを以下に示します。図は、セクション3.2.1で説明されている規則に従います。
|1| |2| |3| |4| |5|
| | | | |
Key N |<-----------Lksk---------->|<---->|
| | | | |
| |<------Ipub----->| |
| | | | |
| |<-Dreg->|<-Iret->| |
| | | | |
Key N+1 | | |<----Lksk-------- - -
| | | | |
Key N Tact Tret Tdea Trem
Key N+1 Tpub Tact
---- Time ---->
Figure 5: Timeline for a Double-RRset KSK Rollover
図5：ダブルRRset KSKロールオーバーのタイムライン
Event 1: The DS and DNSKEY records have appeared in their respective zones and the latter has been used to sign the DNSKEY RRset. The key is published and active: this is key N's activation time (Tact).
イベント1：DSおよびDNSKEYレコードがそれぞれのゾーンに表示され、後者はDNSKEY RRsetの署名に使用されました。キーは公開されてアクティブです。これはキーNのアクティブ化時間（タクト）です。
Event 2: As the current key (key N) approaches the end of its actual lifetime (Lksk), the successor key (key N+1) is introduced into the zone and is used to sign the DNSKEY RRset. At the same time, the successor DS record is submitted to the parent zone. This is the publication time of the successor key (Tpub):
イベント2：現在のキー（キーN）が実際の有効期間（Lksk）の終わりに近づくと、後続キー（キーN + 1）がゾーンに導入され、DNSKEY RRsetの署名に使用されます。同時に、後続DSレコードが親ゾーンに送信されます。これは、後続キー（Tpub）の公開時間です。
Tpub(N+1) <= Tact(N) + Lksk - Ipub
... where Ipub is defined below.
... Ipubは以下で定義されています。
Event 3: After the registration delay (Dreg), the DS record appears in the parent zone. The DNSKEY record is already in the child zone, so with both the new key and its associated data now visible, this is the key's activation time (Tact) and the key is now said to be active.
イベント3：登録遅延（Dreg）の後、DSレコードが親ゾーンに表示されます。 DNSKEYレコードは既に子ゾーンにあるため、新しいキーとそれに関連するデータの両方が表示されるようになり、これがキーのアクティブ化時間（Tact）であり、キーはアクティブであると言われます。
Tact(N+1) = Tpub(N+1) + Dreg
Event 4: Before key N and its associated data can be withdrawn, all RRsets in the caches of validating resolvers must contain the new DS and/or DNSKEY. The time at which this occurs is the dead time of key N (Tdea), given by:
イベント4：キーNとその関連データを撤回する前に、検証リゾルバーのキャッシュ内のすべてのRRsetに新しいDSまたはDNSKEY、あるいはその両方が含まれている必要があります。これが発生する時間は、キーN（Tdea）のデッドタイムです。
Tdea(N) = Tpub(N+1) + Ipub
Ipub is the time it takes to guarantee that any prior cached information about the DNSKEY and the DS RRsets have expired. For the DNSKEY, this is the publication interval of the child (IpubC). For the DS, the publication interval (IpubP) starts once the record appears in the parent zone, which is Dreg after it has been submitted. Hence:
Ipubは、DNSKEYおよびDS RRsetに関する以前のキャッシュ情報が期限切れであることを保証するのにかかる時間です。 DNSKEYの場合、これは子（IpubC）の公開間隔です。 DSの場合、発行間隔（IpubP）は、レコードが送信された後の親ゾーン（Dreg）に表示されると開始します。したがって：
Ipub = max(Dreg + IpubP, IpubC)
The parent zone's publication interval is given by:
親ゾーンの公開間隔は、次のように指定されます。
IpubP = DprpP + TTLds
IpubP = DprpP + TTLds
where DprpP is the parent zone's propagation delay and TTLds is the TTL of the DS record in that zone.
ここで、DprpPは親ゾーンの伝播遅延であり、TTLdsはそのゾーンのDSレコードのTTLです。
The child zone's publication interval is given by a similar equation:
子ゾーンの公開間隔は、同様の方程式で与えられます。
IpubC = DprpC + TTLkey
IpubC = DprpC + TTLkey
where DprpC is the propagation delay in the child zone and TTLkey the TTL of a DNSKEY record.
ここで、DprpCは子ゾーンの伝播遅延であり、TTLkeyはDNSKEYレコードのTTLです。
In analogy with other rollovers, we can also define a retire interval -- the interval between a key becoming active and the time at which its predecessor is considered dead. In this case, Iret is given by:
他のロールオーバーと同様に、リタイア間隔を定義することもできます。これは、キーがアクティブになってから、その前任者が死んだと見なされるまでの時間です。この場合、Iretは次のように与えられます。
Iret = Ipub - Dreg
In other words, the retire interval of the predecessor key is the greater of the publication interval of the parent, or the publication interval of the child minus the registration delay.
つまり、先行キーのリタイア間隔は、親の発行間隔、または子の発行間隔から登録遅延を引いたもののどちらか大きい方です。
Event 5: At some later time, the key N's DS and DNSKEY records are removed from their respective zones. In analogy with other rollover methods, this is the removal time (Trem), given by:
イベント5：後で、キーNのDSおよびDNSKEYレコードがそれぞれのゾーンから削除されます。他のロールオーバー方法と同様に、これは除去時間（Trem）であり、次の式で与えられます。
Trem(N) >= Tdea(N)
Although the preceding sections have been concerned with rolling KSKs, where the trust anchor is a DS record in the parent zone, zone managers may want to take account of the possibility that some validating resolvers may have configured trust anchors directly.
前のセクションでは、トラストアンカーが親ゾーンのDSレコードであるローリングKSKに関連していましたが、ゾーンマネージャーは、一部の検証リゾルバーがトラストアンカーを直接構成している可能性を考慮に入れたい場合があります。
Rolling a configured trust anchor is dealt with in [RFC5011]. It requires introducing the KSK to be used as the trust anchor into the zone for a period of time before use and retaining it (with the "revoke" bit set) for some time after use.
設定されたトラストアンカーのローリングは[RFC5011]で扱われます。使用する前の一定期間、ゾーンにトラストアンカーとして使用するKSKを導入し、使用後しばらく（「取り消し」ビットを設定して）保持する必要があります。
When the new key is introduced, the expression for the publication interval of the DNSKEY (IpubC) in the Double-KSK and Double-RRset methods is modified to:
新しいキーが導入されると、Double-KSKおよびDouble-RRsetメソッドのDNSKEY（IpubC）の公開間隔の式が次のように変更されます。
IpubC >= DprpC + max(Itrp, TTLkey)
... where the right-hand side of the expression now includes the "trust point" interval. This term is the interval required to guarantee that a resolver configured for the automatic update of keys according to [RFC5011] will accept the new key as a new trust point. That interval is given by:
...式の右側に「トラストポイント」間隔が含まれるようになりました。この用語は、[RFC5011]に従ってキーの自動更新用に構成されたリゾルバが新しいトラストポイントとして新しいキーを受け入れることを保証するために必要な間隔です。その間隔は次のように与えられます：
Itrp >= queryInterval + AddHoldDownTime + queryInterval
... where queryInterval is as defined in Section 2.3 of [RFC5011] and AddHoldDownTime is the Add Hold-Down Time defined in Section 2.4.1 of the same document.
... queryIntervalは[RFC5011]のセクション2.3で定義されているとおりで、AddHoldDownTimeは同じドキュメントのセクション2.4.1で定義されている追加ホールドダウン時間です。
The first term of the expression (queryInterval) represents the time after which all validating resolvers can be guaranteed to have obtained a copy of the DNSKEY RRset containing the new key. Once retrieved, a validating resolver needs to wait for AddHoldDownTime. Providing it does not see a validly signed DNSKEY RRset without the new key in that period, it will treat it as a trust anchor the next time it retrieves the RRset, a process that can take up to another queryInterval (the third term).
式の最初の項（queryInterval）は、すべての検証リゾルバーが新しいキーを含むDNSKEY RRsetのコピーを取得したことが保証されるまでの時間を表します。取得された後、検証リゾルバはAddHoldDownTimeを待つ必要があります。その期間に新しいキーがないと、有効に署名されたDNSKEY RRsetが表示されない場合、次回RRsetを取得するときに、それはトラストアンカーとして扱われます。これは、別のqueryInterval（3番目の用語）までかかる可能性のあるプロセスです。
However, the expression for queryInterval given in [RFC5011] contains the DNSKEY's RRSIG expiration interval, a parameter that only the validating resolver can really calculate. In practice, a modified query interval that depends only on TTLkey can be used:
ただし、[RFC5011]で指定されているqueryIntervalの式には、DNSKEYのRRSIG有効期限間隔が含まれています。これは、検証リゾルバーのみが実際に計算できるパラメーターです。実際には、TTLkeyのみに依存する変更されたクエリ間隔を使用できます。
modifiedQueryInterval = MAX(1hr, MIN(15 days, TTLkey / 2))
(This is obtained by taking the expression for queryInterval in [RFC5011] and assuming a worst case for RRsigExpirationInterval. It is greater than or equal to queryInterval for all values of the expiration time.) The expression above then becomes (after collecting terms):
（これは、[RFC5011]のqueryIntervalの式を取得し、RRsigExpirationIntervalの最悪のケースを想定することによって取得されます。これは、有効期限のすべての値のqueryInterval以上です。）上記の式は（項を収集した後）になります。
Itrp >= AddHoldDownTime + 2 * modifiedQueryInterval
In the Double-DS method, instead of swapping the KSK RRs in a single step, there must now be a period of overlap. In other words, the new KSK must be introduced into the zone at least:
Double-DS方式では、KSK RRを単一のステップで交換する代わりに、オーバーラップの期間が存在する必要があります。つまり、新しいKSKは少なくともゾーンに導入する必要があります。
DprpC + max(Itrp, TTLkey)
DprpC + max（Itrp、TTLkey）
... before the switch is made.
...切り替えが行われる前。
The timeline for the removal of the key in all methods is modified by introducing a new state, "revoked". When the key reaches its dead time, instead of being declared "dead", it is revoked; the "revoke" bit is set in the published DNSKEY RR, and the DNSKEY RRset re-signed with the current and revoked keys. The key is maintained in this state for the revoke interval, Irev, given by:
すべてのメソッドでのキーの削除のタイムラインは、「取り消し」という新しい状態を導入することによって変更されます。キーがデッドタイムに達すると、「デッド」と宣言されるのではなく、取り消されます。公開されたDNSKEY RRで「取り消し」ビットが設定され、DNSKEY RRsetが現在のおよび取り消された鍵で再署名されます。キーは、次のように与えられる取り消し間隔Irevの間、この状態で維持されます。
Irev >= DprpC + modifiedQueryInterval
As before, DprpC is the time taken for the revoked DNSKEY to propagate to all slave zones, and modifiedQueryInterval is the time after which it can be guaranteed that all validating resolvers that adhere to RFC 5011 have retrieved a copy of the DNSKEY RRset containing the revoked key.
以前と同様に、DprpCは、取り消されたDNSKEYがすべてのスレーブゾーンに伝播するのにかかる時間であり、modifiedQueryIntervalは、RFC 5011に準拠するすべての検証リゾルバーが取り消されたDNSKEY RRsetのコピーを取得したことが保証されるまでの時間ですキー。
After this time, the key is dead and can be removed from the zone.
この時間が経過すると、キーは無効になり、ゾーンから削除できます。
There are no timing considerations associated with the introduction of the first keys into a zone other that they must be introduced and the zone validly signed before a chain of trust to the zone is created.
ゾーンへの最初のキーの導入に関連するタイミングに関する考慮事項はありません。ゾーンへの信頼のチェーンが作成される前に、それらを導入し、ゾーンに有効に署名する必要があるということです。
In the case of a secure parent, it means ensuring that the DS record is not published in the parent zone until there is no possibility that a validating resolver can obtain the record yet is not able to obtain the corresponding DNSKEY. In the case of an insecure parent, i.e., the initial creation of a chain of trust or "security apex", it is not possible to guarantee this. It is up to the operator of the validating resolver to wait for the new KSK to appear at all servers for the zone before configuring the trust anchor.
安全な親の場合、それは、検証リゾルバーがレコードを取得できるが対応するDNSKEYを取得できない可能性がなくなるまで、DSレコードが親ゾーンで公開されないようにすることを意味します。安全でない親、つまり信頼の連鎖または「セキュリティ頂点」の最初の作成の場合、これを保証することはできません。トラストアンカーを構成する前に、ゾーンのすべてのサーバーに新しいKSKが表示されるのを待つのは、検証リゾルバーのオペレーターの責任です。
Although keys will usually be rolled according to some regular schedule, there may be occasions when an emergency rollover is required, e.g., if the active key is suspected of being compromised. The aim of the emergency rollover is to allow the zone to be re-signed with a new key as soon as possible. As a key must be in the ready state to sign the zone, having at least one additional key (a standby key) in this state at all times will minimize delay.
キーは通常、いくつかの定期的なスケジュールに従ってロールされますが、たとえばアクティブなキーが危険にさらされている疑いがある場合など、緊急のロールオーバーが必要な場合があります。緊急ロールオーバーの目的は、ゾーンに新しい鍵でできるだけ早く再署名できるようにすることです。キーはゾーンに署名する準備ができた状態でなければならないため、少なくとも1つの追加のキー（スタンバイキー）を常にこの状態にすることで、遅延を最小限に抑えることができます。
In the case of a ZSK, a standby key only really makes sense with the Pre-Publication method. A permanent standby DNSKEY RR should be included in the zone or successor keys could be introduced as soon as possible after a key becomes active. Either way results in one or more additional ZSKs in the DNSKEY RRset that can immediately be used to sign the zone if the current key is compromised.
ZSKの場合、スタンバイキーは、事前公開メソッドでのみ意味を持ちます。永続的なスタンバイDNSKEY RRをゾーンに含める必要があります。そうしないと、キーがアクティブになった後できるだけ早く後続キーを導入できます。どちらの方法でも、DNSKEY RRsetに1つ以上の追加のZSKが生成され、現在のキーが危険にさらされた場合に、ゾーンの署名にすぐに使用できます。
(Although, in theory, the mechanism could be used with both the Double-Signature and Double-RRSIG methods, it would require pre-publication of the signatures. Essentially, the standby key would be permanently active, as it would have to be periodically used to renew signatures. Zones would also permanently require two sets of signatures.)
（理論的には、このメカニズムはDouble-SignatureメソッドとDouble-RRSIGメソッドの両方で使用できますが、署名の事前公開が必要になります。基本的に、スタンバイキーは定期的に有効にする必要があるため、永続的にアクティブになります署名を更新するために使用されます。ゾーンも2セットの署名を永続的に必要とします。）
It is also possible to have a standby KSK. The Double-KSK method requires that the standby KSK be included in the DNSKEY RRset; rolling the key then requires just the introduction of the DS record in the parent. Note that the standby KSK should also be used to sign the DNSKEY RRset. As the RRset and its signatures travel together, merely adding the KSK without using it to sign the DNSKEY RRset does not provide the desired time saving: for a KSK to be used in a rollover, the DNSKEY RRset must be signed with it, and this would introduce a delay while the old RRset (not signed with the new key) expires from caches.
スタンバイKSKを使用することもできます。 Double-KSK方式では、スタンバイKSKがDNSKEY RRsetに含まれている必要があります。キーをローリングするには、親にDSレコードを導入するだけで済みます。スタンバイKSKもDNSKEY RRsetの署名に使用する必要があることに注意してください。 RRsetとその署名が一緒に移動するため、DNSKEY RRsetの署名にそれを使用せずにKSKを追加するだけでは、望ましい時間の節約にはなりません。KSKをロールオーバーで使用するには、DNSKEY RRsetに署名する必要があります。古いRRset（新しいキーで署名されていない）がキャッシュから期限切れになるまでに遅延が発生します。
The idea of a standby KSK in the Double-RRset rollover method effectively means having two active keys (as the standby KSK and associated DS record would both be published at the same time in their respective zones).
Double-RRsetロールオーバー方式でのスタンバイKSKの概念は、2つのアクティブなキーを持つことを効果的に意味します（スタンバイKSKおよび関連するDSレコードは、それぞれのゾーンで同時に公開されるため）。
Finally, in the Double-DS method of rolling a KSK, it is not a standby key that is present, it is a standby DS record in the parent zone.
最後に、KSKをローリングするDouble-DS方式では、存在するのはスタンバイキーではなく、親ゾーンのスタンバイDSレコードです。
Whatever algorithm is used, the standby item of data can be included in the zone on a permanent basis, or be a successor introduced as early as possible.
どのアルゴリズムを使用する場合でも、スタンバイデータは永続的にゾーンに含めることも、できるだけ早く後継者にすることもできます。
The preceding sections have implicitly assumed that all keys and signatures are created using a single algorithm. However, Section 2.2 of [RFC4035] requires that there be an RRSIG for each RRset using at least one DNSKEY of each algorithm in the zone apex DNSKEY RRset.
前のセクションでは、すべての鍵と署名が単一のアルゴリズムを使用して作成されることを暗黙的に想定していました。ただし、[RFC4035]のセクション2.2では、ゾーン頂点DNSKEY RRsetの各アルゴリズムの少なくとも1つのDNSKEYを使用して、各RRsetにRRSIGが存在する必要があります。
Except in the case of an algorithm rollover -- where the algorithms used to create the signatures are being changed -- there is no relationship between the keys of different algorithms. This means that they can be rolled independently of one another. In other words, the key-rollover logic described above should be run separately for each algorithm; the union of the results is included in the zone, which is signed using the active key for each algorithm.
アルゴリズムのロールオーバーの場合（署名の作成に使用されるアルゴリズムが変更される場合）を除いて、異なるアルゴリズムのキーの間に関係はありません。これは、互いに独立してローリングできることを意味します。つまり、上記のキーロールオーバーロジックは、アルゴリズムごとに個別に実行する必要があります。結果の結合はゾーンに含まれ、各アルゴリズムのアクティブなキーを使用して署名されます。
For ZSKs, the Pre-Publication method is generally considered to be the preferred way of rolling keys. As shown in this document, the time taken to roll is wholly dependent on parameters under the control of the zone manager.
ZSKの場合、事前公開方法は、一般的に鍵をローリングするための好ましい方法であると考えられています。このドキュメントに示されているように、ロールにかかる時間は、ゾーンマネージャの制御下にあるパラメータに完全に依存しています。
In contrast, the Double-RRset method is the most efficient for KSK rollover due to the ability to have new DS records and DNSKEY RRsets propagate in parallel. The time taken to roll KSKs may depend on factors related to the parent zone if the parent is signed. For zones that intend to comply with the recommendations of [RFC5011], in many cases, the rollover time will be determined by the times defined by RFC 5011. It should be emphasized that this delay is a policy choice and not a function of timing values and that it also requires changes to the rollover process due to the need to manage revocation of trust anchors.
対照的に、Double-RRset方式は、新しいDSレコードとDNSKEY RRsetを並行して伝搬できるため、KSKロールオーバーに最も効率的です。 KSKのロールにかかる時間は、親が署名されている場合、親ゾーンに関連する要因に依存する場合があります。 [RFC5011]の推奨事項に準拠することを目的とするゾーンの場合、多くの場合、ロールオーバー時間はRFC 5011で定義された時間によって決定されます。この遅延はポリシーの選択であり、タイミング値の関数ではないことを強調する必要がありますまた、トラストアンカーの失効を管理する必要があるため、ロールオーバープロセスへの変更も必要です。
Finally, the treatment of emergency key rollover is significantly simplified by the introduction of standby keys as standard practice during all types of rollovers.
最後に、緊急キーのロールオーバーの処理は、すべてのタイプのロールオーバー中に標準的な方法としてスタンバイキーを導入することで大幅に簡素化されます。
This document does not introduce any new security issues beyond those already discussed in [RFC4033], [RFC4034], [RFC4035], and [RFC5011].
このドキュメントでは、[RFC4033]、[RFC4034]、[RFC4035]、および[RFC5011]ですでに説明されている問題以外の新しいセキュリティ問題は紹介していません。
[RFC4033] Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose, "DNS Security Introduction and Requirements", RFC 4033, DOI 10.17487/RFC4033, March 2005, <http://www.rfc-editor.org/info/rfc4033>.
[RFC4033] Arends、R.、Austein、R.、Larson、M.、Massey、D。、およびS. Rose、「DNSセキュリティの概要と要件」、RFC 4033、DOI 10.17487 / RFC4033、2005年3月、<http： //www.rfc-editor.org/info/rfc4033>。
[RFC4034] Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose, "Resource Records for the DNS Security Extensions", RFC 4034, DOI 10.17487/RFC4034, March 2005, <http://www.rfc-editor.org/info/rfc4034>.
[RFC4034] Arends、R.、Austein、R.、Larson、M.、Massey、D。、およびS. Rose、「DNS Security Extensionsのリソースレコード」、RFC 4034、DOI 10.17487 / RFC4034、2005年3月、< http://www.rfc-editor.org/info/rfc4034>。
[RFC4035] Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose, "Protocol Modifications for the DNS Security Extensions", RFC 4035, DOI 10.17487/RFC4035, March 2005, <http://www.rfc-editor.org/info/rfc4035>.
[RFC4035] Arends、R.、Austein、R.、Larson、M.、Massey、D。、およびS. Rose、「DNSセキュリティ拡張機能のプロトコル変更」、RFC 4035、DOI 10.17487 / RFC4035、2005年3月、< http://www.rfc-editor.org/info/rfc4035>。
[RFC5011] StJohns, M., "Automated Updates of DNS Security (DNSSEC) Trust Anchors", STD 74, RFC 5011, DOI 10.17487/RFC5011, September 2007, <http://www.rfc-editor.org/info/rfc5011>.
[RFC5011] StJohns、M。、「DNSセキュリティ（DNSSEC）トラストアンカーの自動更新」、STD 74、RFC 5011、DOI 10.17487 / RFC5011、2007年9月、<http://www.rfc-editor.org/info/ rfc5011>。
[RFC6781] Kolkman, O., Mekking, W., and R. Gieben, "DNSSEC Operational Practices, Version 2", RFC 6781, DOI 10.17487/RFC6781, December 2012, <http://www.rfc-editor.org/info/rfc6781>.
[RFC6781] Kolkman、O.、Mekking、W.、and R. Gieben、 "DNSSEC Operational Practices、Version 2"、RFC 6781、DOI 10.17487 / RFC6781、December 2012、<http://www.rfc-editor.org / info / rfc6781>。
The document defines a number of symbols, all of which are listed here. All are of the form:
このドキュメントでは、いくつかのシンボルを定義しています。これらはすべてここにリストされています。すべての形式です：
<TYPE><id><ZONE>
where:
ただし：
<TYPE> is an uppercase character indicating what type the symbol is. Defined types are:
<TYPE>は、記号のタイプを示す大文字です。定義されているタイプは次のとおりです。
D delay: interval that is a feature of the process
D遅延：プロセスの機能である間隔
I interval between two events
2つのイベントの間隔
L lifetime: interval set by the zone manager
Lライフタイム：ゾーンマネージャーによって設定された間隔
T a point in time
ある時点
TTL TTL of a record
レコードのTTL TTL
I, T, and TTL are self-explanatory. Like I, both D and L are time periods, but whereas I values are intervals between two events, a "D" interval (delay) is a feature of the process, probably outside control of the zone manager, and an "L" interval (lifetime) is chosen by the zone manager and is a feature of policy.
I、T、TTLは自明です。私と同様に、DとLは両方とも期間ですが、Iの値は2つのイベント間の間隔ですが、「D」間隔（遅延）はプロセスの機能であり、おそらくゾーンマネージャーの制御外であり、「L」間隔は（ライフタイム）はゾーンマネージャによって選択され、ポリシーの機能です。
<id> is lowercase and defines what object or event the variable is related to, e.g.,
<id>は小文字で、変数が関連するオブジェクトまたはイベントを定義します。たとえば、
act activation
行為の活性化
pub publication
パブ出版
ret retire
引退する
<ZONE> is an optional uppercase letter that distinguishes between the same variable applied to different zones and is one of:
<ZONE>は、別のゾーンに適用される同じ変数を区別するオプションの大文字で、次のいずれかです。
C child
C子
P parent
P親
Within the rollover descriptions, times may have a number in parentheses affixed to their end indicating the instance of the key to which they apply, e.g., Tact(N) is the activation time of key N, Tpub(N+1) the publication time of key N+1 etc.
ロールオーバーの説明では、時間の末尾に括弧で囲まれた数字が付いている場合があります。たとえば、Tact（N）はキーNのアクティブ化時間、Tpub（N + 1）は発行時間です。キーN + 1など
The list of variables used in the text given below.
以下のテキストで使用されている変数のリスト。
Dprp Propagation delay. The amount of time for a change made at a master nameserver to propagate to all the slave nameservers.
Dprp伝播遅延。マスターネームサーバーで行われた変更がすべてのスレーブネームサーバーに伝播するまでの時間。
DprpC Propagation delay in the child zone.
DprpC子ゾーンでの伝播遅延。
DprpP Propagation delay in the parent zone.
DprpP親ゾーンでの伝播遅延。
Dreg Registration delay: the time taken for a DS record submitted to a parent zone to appear in it. As a parent zone is often managed by a different organization than that managing the child zone, the delays associated with passing data between organizations is captured by this term.
Dreg Registration delay：親ゾーンに送信されたDSレコードがそこに表示されるまでにかかる時間。親ゾーンは、子ゾーンを管理する組織とは別の組織によって管理されることが多いため、組織間のデータの受け渡しに関連する遅延は、この用語で捉えられます。
Dsgn Signing delay. After the introduction of a new ZSK, the amount of time taken for all the RRs in the zone to be signed with it.
Dsgn署名遅延。新しいZSKの導入後、ゾーン内のすべてのRRが署名するのにかかった時間。
Ipub Publication interval. The amount of time that must elapse after the publication of a DNSKEY and/or its associated data before it can be assumed that any resolvers that have the relevant RRset cached have a copy of the new information.
Ipub発行間隔。 DNSKEYおよび/またはその関連データの公開後、関連するRRsetがキャッシュされているリゾルバが新しい情報のコピーを持っていると見なすまでに経過する必要のある時間。
IpubC Publication interval in the child zone.
子ゾーンでのIpubC発行間隔。
IpubP Publication interval in the parent zone.
親ゾーンでのIpubP発行間隔。
Iret Retire interval. The amount of time that must elapse after a DNSKEY or associated data enters the retire state for any dependent information (e.g., RRSIG for a ZSK) to be purged from validating resolver caches.
Iret Retireインターバル。 DNSKEYまたは関連データがリゾルバキャッシュの検証からパージされる依存情報（たとえば、ZSKのRRSIG）がリタイア状態に入った後に経過する必要のある時間。
Irev Revoke interval. The amount of time that a KSK must remain published with the "revoke" bit set to satisfy considerations of [RFC5011].
Irev取り消し間隔。 [RFC5011]の考慮事項を満たすために、「取り消し」ビットが設定された状態でKSKが公開されたままでいる必要がある時間。
Itrp Trust-point interval. The amount of time that a trust anchor must be published for in order to guarantee that a resolver configured for an automatic update of keys will see the new key at least twice.
Itrpトラストポイントインターバル。キーの自動更新用に構成されたリゾルバーが新しいキーを少なくとも2回認識することを保証するために、トラストアンカーを公開する必要がある時間。
Lksk Lifetime of a KSK. This is the actual amount of time for which this particular KSK is regarded as the active KSK. Depending on when the key is rolled over, the actual lifetime may be longer or shorter than the intended key lifetime indicated by management policy.
KSKのLksk寿命。これは、この特定のKSKがアクティブKSKと見なされる実際の時間です。キーがいつロールオーバーされるかによって、実際のライフタイムは、管理ポリシーによって示される意図されたキーライフタイムよりも長い場合も短い場合もあります。
Lzsk Lifetime of a ZSK. This is the actual amount of time for which the ZSK is used to sign the zone. Depending on when the key is rolled over, the actual lifetime may be longer or shorter than the intended key lifetime indicated by management policy.
ZSKのLzskライフタイム。これは、ゾーンの署名にZSKが使用される実際の時間です。キーがいつロールオーバーされるかによって、実際のライフタイムは、管理ポリシーによって示される意図されたキーライフタイムよりも長い場合も短い場合もあります。
Tact Activation time. The time at which the key is regarded as the principal key for the zone.
タクトアクティベーション時間。キーがゾーンの主キーと見なされる時間。
Tdea Dead time. The time at which any information held in validating resolver caches is guaranteed to contain information related to the successor key. At this point, the current key and its associated information are not longed required for validation purposes.
Tdea Dead time。検証リゾルバーキャッシュに保持されている情報に、後続キーに関連する情報が含まれていることが保証される時間。この時点では、現在のキーとそれに関連する情報は、検証目的で必要とされていません。
Tpub Publication time. The time that the key or associated data appears in the zone for the first time.
Tpub発行時刻。キーまたは関連データがゾーンに初めて表示された時刻。
Trem Removal time. The time at which the key and its associated information starts being removed from their respective zones.
Trem除去時間。キーとその関連情報がそれぞれのゾーンから削除され始める時間。
Tret Retire time. The time at which successor information starts being used.
Tretリタイアタイム。後続情報の使用が開始される時刻。
Trdy Ready time. The time at which it can be guaranteed that validating resolvers that have information about the key and/or associated data cached have a copy of the new information.
Trdyレディ時間。キャッシュされたキーまたは関連データ、あるいはその両方に関する情報を持つ検証リゾルバが新しい情報のコピーを持っていることが保証できる時間。
Tsbm Submission time. The time at which the DS record of a KSK is submitted to the parent zone.
Tsbm提出時間。 KSKのDSレコードが親ゾーンに送信された時刻。
TTLds Time to live of a DS record.
TTLds DSレコードの存続時間。
TTLkey Time to live of a DNSKEY record. (By implication, this is also the time to live of the signatures on the DNSKEY RRset.)
TTLkey DNSKEYレコードの存続時間。 （暗黙のうちに、これはDNSKEY RRsetでの署名の存続時間でもあります。）
TTLsig The maximum time to live of all the RRSIG records in the zone that were created with the ZSK.
TTLsig ZSKで作成されたゾーン内のすべてのRRSIGレコードの最大存続時間。
Acknowledgements
謝辞
The authors gratefully acknowledge help and contributions from Roy Arends, Tim Wicinski, and Wouter Wijngaards.
著者は、Roy Arends、Tim Wicinski、およびWouter Wijngaardsからの助けと貢献に感謝します。
Authors' Addresses
著者のアドレス
Stephen Morris Internet Systems Consortium 950 Charter Street Redwood City, CA 94063 United States
Stephen Morris Internet Systems Consortium 950 Charter Street Redwood City、CA 94063アメリカ合衆国
Email: stephen@isc.org
URI: http://www.isc.org
Johan Ihren Netnod Franzengatan 5 Stockholm SE-112 51 Sweden
Johan your Netnod Franzengatan 5ストックホルムSE-112 51スウェーデン
Email: johani@netnod.se
URI: http://www.netnod.se
John Dickinson Sinodun Internet Technologies Ltd Magdalen Centre Oxford Science Park Robert Robertson Avenue Oxford, Oxfordshire OX4 4GA United Kingdom
John Dickinson Sinodun Internet Technologies LtdマグダレンセンターオックスフォードサイエンスパークRobert Robertson Avenueオックスフォード、オックスフォードシャーOX4 4GAイギリス
Email: jad@sinodun.com
URI: http://www.sinodun.com
W. (Matthijs) Mekking Dyn, Inc. 150 Dow St Manchester NH 03101 United States
W.（Matthijs）Mekking Dyn、Inc. 150 Dow StマンチェスターNH 03101アメリカ合衆国
Email: mmekking@dyn.com
URI: https://www.dyn.com