[要約] RFC 6781は、DNSSECの運用上の実践に関するガイドラインであり、バージョン2です。このRFCの目的は、DNSSECの適切な運用を促進し、セキュリティと信頼性を向上させることです。
Internet Engineering Task Force (IETF) O. Kolkman
Request for Comments: 6781 W. Mekking
Obsoletes: 4641 NLnet Labs
Category: Informational R. Gieben
ISSN: 2070-1721 SIDN Labs
December 2012
DNSSEC Operational Practices, Version 2
DNSSECの運用における注意点、バージョン2
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 4641, as it covers more operational ground and gives more up-to-date requirements with respect to key sizes and the DNSSEC operations.
このドキュメントはRFC 4641を廃止します。これは、より多くの運用上の根拠をカバーし、キーサイズと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/rfc6781.
このドキュメントの現在のステータス、正誤表、およびフィードバックの提供方法に関する情報は、http：//www.rfc-editor.org/info/rfc6781で入手できます。
Copyright Notice
著作権表示
Copyright (c) 2012 IETF Trust and the persons identified as the document authors. All rights reserved.
Copyright（c）2012 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に記載されているように保証なしで提供されます。
This document may contain material from IETF Documents or IETF Contributions published or made publicly available before November 10, 2008. The person(s) controlling the copyright in some of this material may not have granted the IETF Trust the right to allow modifications of such material outside the IETF Standards Process. Without obtaining an adequate license from the person(s) controlling the copyright in such materials, this document may not be modified outside the IETF Standards Process, and derivative works of it may not be created outside the IETF Standards Process, except to format it for publication as an RFC or to translate it into languages other than English.
このドキュメントには、2008年11月10日より前に公開または公開されたIETFドキュメントまたはIETFコントリビューションの素材が含まれている場合があります。この素材の一部で著作権を管理している人が、IETFトラストにそのような素材の変更を許可する権利を付与していない可能性がありますIETF標準プロセス外。このような資料の著作権を管理する人から適切なライセンスを取得せずに、このドキュメントをIETF標準プロセス外で変更したり、その派生物をIETF標準プロセス外で作成したりすることはできません。 RFCとして、またはそれを英語以外の言語に翻訳するための出版物。
Table of Contents
目次
1. Introduction ....................................................4
1.1. The Use of the Term 'key' ..................................5
1.2. Time Definitions ...........................................6
2. Keeping the Chain of Trust Intact ...............................6
3. Key Generation and Storage ......................................7
3.1. Operational Motivation for Zone Signing Keys and
Key Signing Keys ...........................................8
3.2. Practical Consequences of KSK and ZSK Separation ..........10
3.2.1. Rolling a KSK That Is Not a Trust Anchor ...........10
3.2.2. Rolling a KSK That Is a Trust Anchor ...............11
3.2.3. The Use of the SEP Flag ............................12
3.3. Key Effectivity Period ....................................12
3.4. Cryptographic Considerations ..............................14
3.4.1. Signature Algorithm ................................14
3.4.2. Key Sizes ..........................................14
3.4.3. Private Key Storage ................................16
3.4.4. Key Generation .....................................17
3.4.5. Differentiation for 'High-Level' Zones? ............17
4. Signature Generation, Key Rollover, and Related Policies .......18
4.1. Key Rollovers .............................................18
4.1.1. Zone Signing Key Rollovers .........................18
4.1.1.1. Pre-Publish Zone Signing Key Rollover .....19
4.1.1.2. Double-Signature Zone Signing Key Rollover 21
4.1.1.3. Pros and Cons of the Schemes ..............23
4.1.2. Key Signing Key Rollovers ..........................23
4.1.2.1. Special Considerations for RFC 5011
KSK Rollover ..............................26
4.1.3. Single-Type Signing Scheme Key Rollover ............26
4.1.4. Algorithm Rollovers ................................28
4.1.4.1. Single-Type Signing Scheme
Algorithm Rollover ........................32
4.1.4.2. Algorithm Rollover, RFC 5011 Style ........32
4.1.4.3. Single Signing Type Algorithm
Rollover, RFC 5011 Style ..................33
4.1.4.4. NSEC-to-NSEC3 Algorithm Rollover ..........34
4.1.5. Considerations for Automated Key Rollovers .........34
4.2. Planning for Emergency Key Rollover .......................35
4.2.1. KSK Compromise .....................................35
4.2.1.1. Emergency Key Rollover Keeping the
Chain of Trust Intact .....................36
4.2.1.2. Emergency Key Rollover Breaking
the Chain of Trust ........................37
4.2.2. ZSK Compromise .....................................37
4.2.3. Compromises of Keys Anchored in Resolvers ..........38
4.2.4. Stand-By Keys ......................................38
4.3. Parent Policies ...........................................39
4.3.1. Initial Key Exchanges and Parental Policies
Considerations .....................................39
4.3.2. Storing Keys or Hashes? ............................40
4.3.3. Security Lameness ..................................40
4.3.4. DS Signature Validity Period .......................41
4.3.5. Changing DNS Operators .............................42
4.3.5.1. Cooperating DNS Operators .................42
4.3.5.2. Non-Cooperating DNS Operators .............44
4.4. Time in DNSSEC ............................................46
4.4.1. Time Considerations ................................46
4.4.2. Signature Validity Periods .........................48
4.4.2.1. Maximum Value .............................48
4.4.2.2. Minimum Value .............................49
4.4.2.3. Differentiation between RRsets ............50
5. "Next Record" Types ............................................51
5.1. Differences between NSEC and NSEC3 ........................51
5.2. NSEC or NSEC3 .............................................52
5.3. NSEC3 Parameters ..........................................53
5.3.1. NSEC3 Algorithm ....................................53
5.3.2. NSEC3 Iterations ...................................53
5.3.3. NSEC3 Salt .........................................54
5.3.4. Opt-Out ............................................54
6. Security Considerations ........................................54
7. Acknowledgments ................................................55
8. Contributors ...................................................55
9. References .....................................................56
9.1. Normative References ......................................56
9.2. Informative References ....................................56
Appendix A. Terminology ...........................................59
Appendix B. Typographic Conventions ...............................61
Appendix C. Transition Figures for Special Cases of Algorithm
Rollovers .............................................64
Appendix D. Transition Figure for Changing DNS Operators ..........68
Appendix E. Summary of Changes from RFC 4641 ......................70
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 [RFC1034] and RFC 1035 [RFC1035]) and want to deploy DNSSEC (RFC 4033 [RFC4033], RFC 4034 [RFC4034], RFC 4035 [RFC4035], and RFC 5155 [RFC5155]). The focus of the document is on serving authoritative DNS information and is aimed at zone owners, name server operators, registries, registrars, and registrants. It assumes that there is no direct relationship between those entities and the operators of validating recursive name servers (validators).
このドキュメントでは、DNSセキュリティ（DNSSEC）対応の環境を実行する方法について説明します。これは、DNSの知識（RFC 1034 [RFC1034]およびRFC 1035 [RFC1035]を参照）を持ち、DNSSEC（RFC 4033 [RFC4033]、RFC 4034 [RFC4034]、RFC 4035 [RFC4035]、 RFC 5155 [RFC5155]）。このドキュメントの焦点は、信頼できるDNS情報の提供にあり、ゾーンの所有者、ネームサーバーオペレーター、レジストリ、レジストラ、および登録者を対象としています。これらのエンティティーと再帰ネームサーバーを検証するオペレーター（バリデーター）の間に直接の関係はないと想定しています。
During workshops and early operational deployment, 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. Although the DNS Root has been signed since July 15, 2010 and now more than 80 secure delegations are provisioned in the root, at the time of this writing there still exists relatively little experience with DNSSEC in production environments below the Top-Level Domain (TLD) level; this document should therefore explicitly not be seen as representing 'Best Current Practices'. Instead, it describes the decisions that should be made when deploying DNSSEC, gives the choices available for each one, and provides some operational guidelines. The document does not give strong recommendations. That may be the subject for a future version of this document.
ワークショップや初期の運用展開中に、オペレーターとシステム管理者は、セキュリティ拡張機能（DNSSEC）を使用したDNSの操作に関する経験を積んでいます。このドキュメントでは、これらの経験をゾーン管理者向けの一連のプラクティスに変換します。 DNSルートは2010年7月15日から署名されており、現在80を超える安全な委任がルートでプロビジョニングされていますが、この記事の執筆時点では、トップレベルドメイン（TLD ）レベル;したがって、このドキュメントは「現在のベストプラクティス」を表すものとして明示的に見なされるべきではありません。代わりに、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.
ここでの手順は、署名されたゾーン（つまり、権限のあるサーバー上のゾーンに署名して公開する）の保守に焦点を当てています。再署名やキーのロールオーバーなどのゾーンのメンテナンスは、検証するクライアントに対して透過的であることが意図されています。
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 keys are discussed in Section 3; the focus in this section is mainly on the security of the private part of the key(s). Section 4 describes considerations concerning the public part of the keys. Sections 4.1 and 4.2 deal with the rollover, or replacement, of keys. Section 4.3 discusses considerations on how parents deal with their children's public keys in order to maintain chains of trust. Section 4.4 covers all kinds of timing issues around key publication. Section 5 covers the considerations regarding selecting and using the NSEC or NSEC3 [RFC5155] Resource Record.
このドキュメントの構造は次のとおりです。セクション2では、「信頼の連鎖」を損なわないようにすることの重要性について説明します。鍵の生成と鍵の保管の側面については、セクション3で説明します。このセクションでは、主にキーの秘密部分のセキュリティに焦点を当てています。セクション4では、キーの公開部分に関する考慮事項について説明します。セクション4.1と4.2では、キーのロールオーバー、または置換について扱います。セクション4.3では、信頼の連鎖を維持するために、親が子供の公開鍵をどのように扱うかに関する考慮事項について説明します。セクション4.4は、主要な公開に関するあらゆる種類のタイミングの問題をカバーしています。セクション5では、NSECまたはNSEC3 [RFC5155]リソースレコードの選択と使用に関する考慮事項について説明します。
The typographic conventions used in this document are explained in Appendix B.
このドキュメントで使用されている表記規則については、付録Bで説明しています。
Since we describe operational suggestions and there are no protocol specifications, the RFC 2119 [RFC2119] language does not apply to this document, though we do use quotes from other documents that do include the RFC 2119 language.
運用上の提案について説明し、プロトコル仕様がないため、RFC 2119 [RFC2119]言語はこのドキュメントには適用されませんが、RFC 2119言語を含む他のドキュメントからの引用は使用します。
This document obsoletes RFC 4641 [RFC4641].
このドキュメントはRFC 4641 [RFC4641]を廃止します。
It is assumed that the reader is familiar with the concept of asymmetric cryptography, or public-key cryptography, on which DNSSEC is based (see the definition of 'asymmetric cryptography' in RFC 4949 [RFC4949]). 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 (DNSKEY RR) and that it is the public part that is used in signature verification.
読者は、DNSSECのベースとなっている非対称暗号化または公開鍵暗号化の概念に精通していることを前提としています（RFC 4949 [RFC4949]の「非対称暗号化」の定義を参照）。したがって、このドキュメントでは「キー」という用語を大まかに使用します。 「データに署名するために鍵が使用される」と書かれている場合、署名に使用されるのは鍵ペアの秘密部分であることを読者が理解していると想定されます。また、鍵ペアの公開部分がDNSKEYリソースレコード（DNSKEY RR）で公開されていること、および署名検証で使用されるのは公開部分であることを読者が理解していることも前提としています。
In this document, we will be using a number of time-related terms. The following definitions apply:
このドキュメントでは、時間に関連するいくつかの用語を使用します。次の定義が適用されます。
Signature validity period: The period that a signature is valid. It starts at the (absolute) time specified in the signature inception field of the RRSIG RR and ends at the (absolute) time specified in the expiration field of the RRSIG RR. The document sometimes also uses the term 'validity period', which means the same.
署名の有効期間：署名が有効な期間。これは、RRSIG RRの署名開始フィールドで指定された（絶対）時間で始まり、RRSIG RRの有効期限フィールドで指定された（絶対）時間で終了します。このドキュメントでは、「有効期間」という用語を使用する場合もありますが、これは同じことを意味します。
Signature publication period: The period that a signature is published. It starts at the time the signature is introduced in the zone for the first time and ends at the time when the signature is removed or replaced with a new signature. 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.
署名発行期間：署名が発行される期間。これは、署名がゾーンに初めて導入されたときに始まり、署名が削除されたとき、または新しい署名に置き換えられたときに終了します。ゾーンでのRRSIGの発行を停止した後、RRSIGがキャッシュから期限切れになり、実際にDNSから削除されるまでに時間がかかる場合があります。
Key effectivity period: The period during which a key pair is expected to be effective. It is defined as the time between the earliest 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.
キーの有効期間：キーペアが有効であると期待される期間。これは、キーの使用の不連続性に関係なく、このキーで作成された署名の最も早い開始タイムスタンプと最後の有効期限の間の時間として定義されます。重要な有効期間は、複数の署名有効期間にまたがることができます。
Maximum/Minimum Zone Time to Live (TTL): The maximum or minimum value of the TTLs from the complete set of RRs in a zone, that are used by validators or resolvers. Note that the minimum TTL is not the same as the MINIMUM field in the SOA RR. See RFC 2308 [RFC2308] for more information.
最大/最小ゾーン存続時間（TTL）：バリデーターまたはリゾルバーによって使用される、ゾーン内のRRの完全なセットからのTTLの最大値または最小値。最小TTLはSOA RRのMINIMUMフィールドと同じではないことに注意してください。詳細については、RFC 2308 [RFC2308]を参照してください。
Maintaining a valid chain of trust is important because broken chains of trust will result in data being marked as Bogus (as defined in RFC 4033 [RFC4033] Section 5), which may cause entire (sub)domains to become invisible to verifying clients. The administrators of secured zones need to realize that, to verifying clients, their zone is part of a chain of trust.
信頼の連鎖が壊れるとデータが偽としてマークされ（RFC 4033 [RFC4033]セクション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 need 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 name servers and clients may be fetching data from caching non-authoritative servers. In this light, note that the time until the data is available on the slave can be negligible when using NOTIFY [RFC1996] and Incremental Zone Transfer (IXFR) [RFC1995]. It increases when Authoritative (full) Zone Transfers (AXFRs) are used in combination with NOTIFY. It increases even more if you rely on the full zone transfers being based only on the SOA timing parameters for refresh.
保護されたゾーンの管理者は、信頼できるプライマリサーバーで公開されたデータは、クライアントの確認ではすぐには表示されないことに注意する必要があります。データが他の（セカンダリ）権限のあるネームサーバーに転送されるまでに時間がかかる場合があり、クライアントは権限のないサーバーのキャッシュからデータをフェッチしている可能性があります。この観点から、NOTIFY [RFC1996]およびインクリメンタルゾーン転送（IXFR）[RFC1995]を使用する場合、スレーブでデータが利用可能になるまでの時間は無視できる場合があることに注意してください。権限のある（完全な）ゾーン転送（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 name server, 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 tradeoff must be made between maintaining a valid chain of trust and replacing the compromised keys as soon as possible. Then zone administrators will have to decide 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.2).
信頼の連鎖を維持する責任は、信頼の連鎖の保護されたゾーンの管理者によって共有されます。これは、有効な信頼チェーンを維持することと、侵害されたキーをできるだけ早く交換することの間でトレードオフを行う必要がある「キーの侵害」の場合に最も明白です。次に、ゾーン管理者は、信頼の連鎖をそのまま維持することにより（つまり、侵害されたキーによる攻撃を許可するか）、信頼の連鎖を故意に破り、セキュリティで保護されたサブドメインをセキュリティ対応のリゾルバーから見えないようにするかを決定する必要があります（セクション4.2も参照）。
This section describes a number of considerations with respect to the use of keys. For the design of an operational procedure for key generation and storage, a number of decisions need to be made:
このセクションでは、キーの使用に関するいくつかの考慮事項について説明します。鍵の生成と保存の運用手順を設計するには、いくつかの決定を行う必要があります。
o Does one differentiate between Zone Signing Keys and Key Signing Keys or is the use of one type of key sufficient?
o ゾーン署名鍵と鍵署名鍵は区別されますか、それとも1種類の鍵の使用で十分ですか？
o Are Key Signing Keys (likely to be) in use as trust anchors [RFC4033]?
o キー署名キーは（おそらく）トラストアンカーとして使用されていますか[RFC4033]？
o What are the timing parameters that are allowed by the operational requirements?
o 運用要件で許可されているタイミングパラメータは何ですか？
o What are the cryptographic parameters that fit the operational need?
o 運用上のニーズに適合する暗号化パラメーターは何ですか？
The following section discusses the considerations that need to be taken into account when making those choices.
次のセクションでは、これらの選択を行うときに考慮する必要がある考慮事項について説明します。
The DNSSEC validation protocol does not distinguish between different types of DNSKEYs. The motivations to differentiate between keys are purely operational; validators will not make a distinction.
DNSSEC検証プロトコルは、異なるタイプのDNSKEYを区別しません。キーを区別する動機は純粋に機能しています。バリデーターは区別しません。
For operational reasons, described below, it is possible to designate one or more keys to have the role of 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 other RRsets in a zone that require signatures. They are referred to as Zone Signing Keys (ZSKs). In cases where the differentiation between the KSK and ZSK is not made, i.e., where keys have the role of both KSK and ZSK, we talk about a Single-Type Signing Scheme.
以下に説明する運用上の理由から、1つ以上の鍵を指定して、鍵署名鍵（KSK）の役割を持たせることができます。これらのキーは、ゾーンの頂点DNSKEY RRsetにのみ署名します。他の鍵を使用して、署名が必要なゾーン内の他のすべてのRRsetに署名できます。これらはゾーン署名鍵（ZSK）と呼ばれます。 KSKとZSKを区別しない場合、つまり、キーがKSKとZSKの両方の役割を持つ場合は、シングルタイプ署名方式について説明します。
If the two functions are separated, then for almost any method of key management and zone signing, the KSK is used less frequently than the ZSK. Once a DNSKEY RRset is signed with the KSK, all the keys in the RRset can be used as ZSKs. If there has been an event that increases the risk that a ZSK is compromised, it can be simply replaced with a ZSK rollover. The new RRset is then re-signed with the KSK.
2つの機能が分離されている場合、キー管理とゾーン署名のほぼすべての方法で、KSKはZSKよりも使用頻度が低くなります。 DNSKEY RRsetがKSKで署名されると、RRsetのすべてのキーをZSKとして使用できます。 ZSKが危険にさらされるリスクを高めるイベントが発生した場合は、ZSKロールオーバーに置き換えることができます。次に、新しいRRsetがKSKで再署名されます。
Changing a key that is a Secure Entry Point (SEP) [RFC4034] for a zone can be relatively expensive, as it involves interaction with third parties: When a key is only pointed to by a Delegation Signer (DS) [RFC4034] record in the parent zone, one needs to complete the interaction with the parent and wait for the updated DS record to appear in the DNS. In the case where a key is configured as a trust anchor, one has to wait until one has sufficient confidence that all trust anchors have been replaced. In fact, it may be that one is not able to reach the complete user-base with information about the key rollover.
ゾーンのSecure Entry Point（SEP）[RFC4034]であるキーを変更すると、サードパーティとのやり取りが含まれるため、比較的コストがかかる可能性があります。キーが委任署名者（DS）[RFC4034]レコードによってのみポイントされる親ゾーンでは、親との対話を完了し、更新されたDSレコードがDNSに表示されるのを待つ必要があります。キーがトラストアンカーとして構成されている場合、すべてのトラストアンカーが置き換えられたという十分な確信が得られるまで待つ必要があります。実際には、キーのロールオーバーに関する情報で完全なユーザーベースに到達できない場合があります。
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; otherwise, it is a ZSK.
KSKに対してSEPフラグが設定されているという前提で、DNSKEY RRのフラグフィールドを調べることにより、KSKをZSKと区別できます。フラグフィールドが奇数の場合、KSKです。それ以外の場合は、ZSKです。
There is also a risk that keys can be compromised through theft or loss. For keys that are installed on file-systems of name servers that are connected to the network (e.g., for dynamic updates), that risk is relatively high. Where keys are stored on Hardware Security Modules (HSMs) or stored off-line, such risk is relatively low. However, storing keys off-line or with more limitations on access control has a negative effect on the operational flexibility. By separating the KSK and ZSK functionality, these risks can be managed while making the tradeoff against the involved costs. For example, a KSK can be stored off-line or with more limitations on access control than ZSKs, which need to be readily available for operational purposes such as the addition or deletion of zone data. A KSK stored on a smartcard that is kept in a safe, combined with a ZSK stored on a file-system accessible by operators for daily routine use, may provide better protection against key compromise without losing much operational flexibility. It must be said that some HSMs give the option to have your keys online, giving more protection and hardly affecting the operational flexibility. In those cases, a KSK-ZSK split is not more beneficial than the Single-Type Signing Scheme.
また、盗難や紛失によってキーが危険にさらされるリスクもあります。ネットワークに接続されているネームサーバーのファイルシステムにインストールされているキー（動的更新など）の場合、そのリスクは比較的高くなります。キーがハードウェアセキュリティモジュール（HSM）に格納されるか、オフラインで格納される場合、そのようなリスクは比較的低くなります。ただし、キーをオフラインで保存したり、アクセス制御の制限を増やしたりすると、運用の柔軟性に悪影響が出ます。 KSK機能とZSK機能を分離することにより、関連するコストとのトレードオフを保ちながら、これらのリスクを管理できます。たとえば、ゾーンデータの追加や削除などの運用目的ですぐに利用できる必要があるZSKよりも、KSKをオフラインで、またはアクセス制御に多くの制限を付けて保存できます。安全に保管されているスマートカードに保存されているKSKと、日常の使用のためにオペレーターがアクセスできるファイルシステムに保存されているZSKを組み合わせると、操作の柔軟性をほとんど失うことなく、キーの侵害に対する保護を強化できます。一部のHSMはキーをオンラインにするオプションを提供し、より高い保護を提供し、運用の柔軟性にほとんど影響を与えないことを言わなければなりません。これらの場合、KSK-ZSK分割は、単一タイプの署名方式ほど有益ではありません。
It is worth mentioning that there's not much point in obsessively protecting the key if you don't protect the zone files, which also live on the file-systems.
ファイルシステム上にも存在するゾーンファイルを保護しない場合、強要してキーを保護する意味はあまりありません。
Finally, there is a risk of cryptanalysis of the key material. The costs of such analysis are correlated to the length of the key. However, cryptanalysis arguments provide no strong motivation for a KSK/ZSK split. Suppose one differentiates between a KSK and a ZSK, whereby the KSK effectivity period is X times the ZSK effectivity period. Then, in order for the resistance to cryptanalysis to be the same for the KSK and the ZSK, the KSK needs to be X times stronger than the ZSK. Since for all practical purposes X will be somewhere on the order of 10 to 100, the associated key sizes will vary only by about a byte in size for symmetric keys. When translated to asymmetric keys, the size difference is still too insignificant to warrant a key-split; it only marginally affects the packet size and signing speed.
最後に、キーマテリアルの解読のリスクがあります。このような分析のコストは、キーの長さに相関しています。ただし、暗号解析の引数は、KSK / ZSK分割に強い動機を提供しません。 KSKとZSKを区別し、KSK有効期間がZSK有効期間のX倍であると仮定します。次に、暗号解読に対する耐性をKSKとZSKで同じにするには、KSKをZSKのX倍にする必要があります。すべての実用的な目的で、Xは10から100のオーダーになるため、関連するキーのサイズは、対称キーの場合、サイズが約1バイトだけ変化します。非対称キーに変換された場合、サイズの違いは重要ではなく、キー分割を保証できません。パケットサイズと署名速度にわずかに影響するだけです。
The arguments for differentiation between the ZSK and KSK are weakest when:
ZSKとKSKを区別するための引数は、次の場合に最も弱くなります。
o the exposure to risk is low (e.g., when keys are stored on HSMs);
o リスクへのエクスポージャーが低い（たとえば、キーがHSMに保存されている場合）;
o one can be certain that a key is not used as a trust anchor;
o キーがトラストアンカーとして使用されていないことを確認できます。
o maintenance of the various keys cannot be performed through tools (is prone to human error); and
o さまざまなキーの保守はツールを介して実行できません（人為的ミスが発生しやすい）。そして
o the interaction through the child-parent provisioning chain -- in particular, the timely appearance of a new DS record in the parent zone in emergency situations -- is predictable.
o 子と親のプロビジョニングチェーンによる相互作用、特に緊急時に親ゾーンに新しいDSレコードがタイムリーに出現することは予測可能です。
If the above arguments hold, then the costs of the operational complexity of a KSK-ZSK split may outweigh the costs of operational flexibility, and choosing a Single-Type Signing Scheme is a reasonable option. In other cases, we advise that the separation between KSKs and ZSKs is made.
上記の議論が当てはまる場合、KSK-ZSK分割の操作の複雑さのコストは、操作の柔軟性のコストを上回る可能性があり、シングルタイプの署名スキームを選択することは合理的なオプションです。その他の場合、KSKとZSKを分離することをお勧めします。
A key that acts only as a Zone Signing Key is used to sign all the data except the DNSKEY RRset in a zone on a regular basis. When a ZSK is to be rolled, no interaction with the parent is needed. This allows for a relatively short key effectivity period.
ゾーン署名キーとしてのみ機能するキーを使用して、ゾーン内のDNSKEY RRsetを除くすべてのデータに定期的に署名します。 ZSKがロールされる場合、親との対話は必要ありません。これにより、キーの有効期間を比較的短くすることができます。
A key with only the Key Signing Key role is to be used to sign the DNSKEY RRs in a zone. If a KSK is to be rolled, there may be interactions with other parties. These can include the administrators of the parent zone or administrators of verifying resolvers that have the particular key configured as secure entry points. In the latter case, everyone relying on the trust anchor needs to roll over to the new key, a process that may be subject to stability costs if automated trust anchor rollover mechanisms (e.g., RFC 5011 [RFC5011]) are not in place. Hence, the key effectivity period of these keys can and should be made much longer.
鍵署名鍵の役割のみを持つ鍵は、ゾーン内のDNSKEY RRに署名するために使用されます。 KSKを展開する場合は、他の関係者とのやり取りがある可能性があります。これらには、親ゾーンの管理者や、特定のキーが安全なエントリポイントとして構成されているリゾルバーを確認する管理者を含めることができます。後者の場合、トラストアンカーに依存するすべての人が新しいキーにロールオーバーする必要があります。このプロセスは、自動化されたトラストアンカーのロールオーバーメカニズム（RFC 5011 [RFC5011]など）が導入されていない場合、安定性コストの影響を受ける可能性があります。したがって、これらのキーの有効期間は、はるかに長くすることができ、長くする必要があります。
There are three schools of thought on rolling a KSK that is not a trust anchor:
トラストアンカーではないKSKのローリングについては、次の3つの考え方があります。
1. It should be done frequently and regularly (possibly every few months), so that a key rollover remains an operational routine.
1. 頻繁かつ定期的に（おそらく数か月ごとに）実行する必要があります。これにより、キーのロールオーバーが引き続き運用できるようになります。
2. It should be done frequently but irregularly. "Frequently" means every few months, again based on the argument that a rollover is a practiced and common operational routine; "irregular" means with a large jitter, so that third parties do not start to rely on the key and will not be tempted to configure it as a trust anchor.
2. 頻繁に行うべきですが、不定期に行う必要があります。 「頻繁に」とは、ここでも、ロールオーバーは実践的で一般的な運用ルーチンであるという主張に基づいて、数か月ごとを意味します。 「不規則」とは、ジッターが大きいことを意味します。そのため、サードパーティはキーに依存し始めず、それをトラストアンカーとして設定しようとはしません。
3. It should only be done when it is known or strongly suspected that the key can be or has been compromised, or in conjunction with operator change policies and procedures, like when a new algorithm or key storage is required.
3. 新しいアルゴリズムやキーのストレージが必要な場合など、キーが危険にさらされている可能性があることがわかっているか強く疑われる場合、またはオペレーターの変更ポリシーと手順と組み合わせて実行する必要があります。
There is no widespread agreement on which of these three schools of thought is better for different deployments of DNSSEC. There is a stability cost every time a non-anchor KSK is rolled over, but it is possibly low if the communication between the child and the parent is good. On the other hand, the only completely effective way to tell if the communication is good is to test it periodically. Thus, rolling a KSK with a parent is only done for two reasons: to test and verify the rolling system to prepare for an emergency, and in the case of (preventing) an actual emergency.
DNSSECのさまざまな展開に対して、これら3つの考え方のどれが優れているかについての広範な合意はありません。アンカー以外のKSKがロールオーバーされるたびに安定性のコストが発生しますが、子と親の間の通信が良好であれば、コストは低くなる可能性があります。一方、通信が良好かどうかを確認する唯一の完全に効果的な方法は、定期的にテストすることです。したがって、親とのKSKのローリングは、非常事態に備えるためにローリングシステムをテストおよび検証することと、実際の非常事態（の防止）の場合の2つの理由でのみ行われます。
Finally, in most cases a zone administrator cannot be fully certain that the zone's KSK is not in use as a trust anchor somewhere. While the configuration of trust anchors is not the responsibility of the zone administrator, there may be stability costs for the validator administrator that (wrongfully) configured the trust anchor when the zone administrator rolls a KSK.
最後に、ほとんどの場合、ゾーン管理者は、ゾーンのKSKがどこかのトラストアンカーとして使用されていないことを完全に確信することはできません。トラストアンカーの構成はゾーン管理者の責任ではありませんが、ゾーン管理者がKSKをロールするときにトラストアンカーを（誤って）構成したバリデーター管理者には安定性のコストがかかる場合があります。
The same operational concerns apply to the rollover of KSKs that are used as trust anchors: If a trust anchor replacement is done incorrectly, the entire domain that the trust anchor covers will become Bogus until the trust anchor is corrected.
トラストアンカーとして使用されるKSKのロールオーバーにも同じ運用上の問題が適用されます。トラストアンカーの置き換えが誤って行われると、トラストアンカーが修正されるまで、トラストアンカーがカバーするドメイン全体が不正になります。
In a large number of cases, it will be safe to work from the assumption that one's keys are not in use as trust anchors. If a zone administrator publishes a DNSSEC signing policy and/or a DNSSEC practice statement [DNSSEC-DPS], that policy or statement should be explicit regarding whether or not the existence of trust anchors will be taken into account. There may be cases where local policies enforce the configuration of trust anchors on zones that are mission critical (e.g., in enterprises where the trust anchor for the enterprise domain is configured in the enterprise's validator). It is expected that the zone administrators are aware of such circumstances.
多くの場合、自分のキーがトラストアンカーとして使用されていないという想定から作業するのが安全です。ゾーン管理者がDNSSEC署名ポリシーやDNSSEC実践ステートメント[DNSSEC-DPS]を公開する場合、そのポリシーまたはステートメントは、トラストアンカーの存在が考慮されるかどうかに関して明示的である必要があります。ローカルポリシーによって、ミッションクリティカルなゾーンにトラストアンカーの構成が適用される場合があります（たとえば、エンタープライズドメインのトラストアンカーがエンタープライズの検証ツールで構成されているエンタープライズ）。ゾーン管理者はこのような状況を認識していることが期待されます。
One can argue that because of the difficulty of getting all users of a trust anchor to replace an old trust anchor with a new one, a KSK that is a trust anchor should never be rolled unless it is known or strongly suspected that the key has been compromised. In other words, the costs of a KSK rollover are prohibitively high because some users cannot be reached.
トラストアンカーのすべてのユーザーに古いトラストアンカーを新しいトラストアンカーに置き換えるのが難しいため、トラストアンカーであるKSKは、キーが既知であるか、またはその疑いがあると強く疑われない限り、ローリングしないでください。妥協。つまり、一部のユーザーに連絡できないため、KSKロールオーバーのコストは非常に高くなります。
However, the "operational habit" argument also applies to trust anchor reconfiguration at the clients' validators. 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 are smaller. In fact, the costs for those users can be minimized by automating the rollover with RFC 5011 [RFC5011] and by rolling the key regularly (and advertising such) so that the operators of validating resolvers will put the appropriate mechanism in place to deal with these stability costs: In other words, budget for these costs instead of incurring them unexpectedly.
ただし、「運用上の習慣」の議論は、クライアントのバリデーターでのトラストアンカーの再構成にも適用されます。短いキー有効期間が使用され、トラストアンカー構成を定期的に再検討する必要がある場合、構成が忘れられる傾向がある確率は小さくなります。実際、これらのユーザーのコストは、RFC 5011 [RFC5011]でロールオーバーを自動化し、定期的にキーをローリング（およびそのように通知）することで最小限に抑えることができるため、リゾルバーを検証するオペレーターがこれらに対処するための適切なメカニズムを配置します安定性コスト：言い換えれば、これらのコストを予想外に負担するのではなく、予算化します。
It is therefore preferable to roll KSKs that are expected to be used as trust anchors on a regular basis if and only if those rollovers can be tracked using standardized (e.g., RFC 5011 [RFC5011]) mechanisms.
したがって、標準化された（RFC 5011 [RFC5011]などの）メカニズムを使用してこれらのロールオーバーを追跡できる場合に限り、トラストアンカーとして定期的に使用されると予想されるKSKをロールすることが推奨されます。
The so-called SEP [RFC4035] flag can be used to distinguish between keys that are intended to be used as the secure entry point into the zone when building chains of trust, i.e., they are (to be) pointed to by parental DS RRs or configured as a trust anchor.
いわゆるSEP [RFC4035]フラグを使用して、信頼チェーンを構築するときにゾーンへの安全なエントリポイントとして使用することを目的としたキーを区別できます。つまり、ペアレントDS RRによってポイントされます（される）またはトラストアンカーとして構成されています。
While the SEP flag does not play any role in validation, it is used in practice for operational purposes such as for the rollover mechanism described in RFC 5011 [RFC5011]. The common convention is to set the SEP flag on any key that is used for key exchanges with the parent and/or potentially used for configuration as a trust anchor. Therefore, it is suggested that the SEP flag be set on keys that are used as KSKs and not on keys that are used as ZSKs, while in those cases where a distinction between a KSK and ZSK is not made (i.e., for a Single-Type Signing Scheme), it is suggested that the SEP flag be set on all keys.
SEPフラグは検証で何の役割も果たしませんが、実際にはRFC 5011 [RFC5011]で説明されているロールオーバーメカニズムなどの運用目的で使用されます。一般的な規則は、親との鍵交換に使用されたり、トラストアンカーとしての構成に使用されたりする可能性がある任意の鍵にSEPフラグを設定することです。したがって、SEKフラグは、KSKとして使用されるキーではなく、KSKとして使用されるキーに設定することをお勧めします。一方、KSKとZSKを区別しない場合（つまり、シングル- Type Signing Scheme）、すべてのキーにSEPフラグを設定することをお勧めします。
Note: Some signing tools may assume a KSK/ZSK split and use the (non-)presence of the SEP flag to determine which key is to be used for signing zone data; these tools may get confused when a Single-Type Signing Scheme is used.
注：一部の署名ツールは、KSK / ZSK分割を想定し、SEPフラグの（非）存在を使用して、ゾーンデータの署名に使用するキーを決定します。シングルタイプ署名スキームを使用すると、これらのツールが混乱する可能性があります。
In general, the available key length sets an upper limit on the key effectivity period. For all practical purposes, it is sufficient to define the key effectivity period based on purely operational requirements and match the key length to that value. Ignoring the operational perspective, a reasonable effectivity period for KSKs that have corresponding DS records in the parent zone is on the order of two decades or longer. That is, if one does not plan to test the rollover procedure, the key should be effective essentially forever and only rolled over in case of emergency.
一般に、使用可能なキーの長さは、キーの有効期間の上限を設定します。すべての実用的な目的のために、純粋な運用要件に基づいてキーの有効期間を定義し、キーの長さをその値に一致させるだけで十分です。運用の観点を無視すると、親ゾーンに対応するDSレコードを持つKSKの妥当な有効期間は、およそ20年以上です。つまり、ロールオーバー手順をテストする予定がない場合、キーは本質的に永久に有効であり、緊急の場合にのみロールオーバーする必要があります。
When one opts for a regular key rollover, a reasonable key effectivity period for KSKs that have a parent zone is one year, meaning you have the intent to replace them after 12 months. The key effectivity period is merely a policy parameter and should not be considered a constant value. For example, the real key effectivity period may be a little bit longer than 12 months, because not all actions needed to complete the rollover could be finished in time.
通常のキーロールオーバーを選択した場合、親ゾーンを持つKSKの合理的なキー有効期間は1年です。つまり、12か月後にそれらを交換する意図があります。重要な有効期間は単なるポリシーパラメーターであり、一定の値と見なすべきではありません。たとえば、ロールオーバーを完了するために必要なすべてのアクションが時間内に完了するとは限らないため、実際のキーの有効期間は12か月より少し長くなる場合があります。
As argued above, this annual rollover gives an operational practice of rollovers for both the zone and validator administrators. Besides, in most environments a year is a time span that is easily planned and communicated.
上で述べたように、この年次ロールオーバーは、ゾーン管理者と検証者管理者の両方にロールオーバーの運用慣行を提供します。さらに、ほとんどの環境では、1年は計画と伝達が容易な期間です。
Where keys are stored online and the exposure to various threats of compromise is fairly high, an intended key effectivity period of a month is reasonable for Zone Signing Keys.
キーがオンラインで保存され、さまざまな侵害の脅威にさらされる可能性がかなり高い場合、1か月の意図されたキーの有効期間は、ゾーン署名キーにとって妥当です。
Although very short key effectivity periods are theoretically possible, when replacing keys one has to take into account the rollover considerations discussed in Sections 4.1 and 4.4. Key replacement endures for a couple of Maximum Zone TTLs, depending on the rollover scenario. Therefore, a multiple of Maximum Zone TTL durations is a reasonable lower limit on the key effectivity period. Forcing a shorter key effectivity period will result in an unnecessary and inconveniently large DNSKEY RRset published in the zone.
理論的には非常に短いキー有効期間が可能ですが、キーを置き換えるときは、セクション4.1および4.4で説明したロールオーバーの考慮事項を考慮する必要があります。キーの交換は、ロールオーバーのシナリオに応じて、いくつかの最大ゾーンTTLに耐えます。したがって、最大ゾーンTTL期間の倍数は、キーの有効期間の妥当な下限です。キーの有効期間を短くすると、ゾーンで公開されるDNSKEY RRsetが不必要になり、不便になります。
The motivation for having the ZSK's effectivity period shorter than the KSK's effectivity period is rooted in the operational consideration that it is more likely that operators have more frequent read access to the ZSK than to the KSK. Thus, in cases where the ZSK cannot be afforded the same level of protection as the KSK (such as when zone keys are kept online), and where the risk of unauthorized disclosure of the ZSK's private key is not negligible (e.g., when HSMs are not in use), the ZSK's effectivity period should be kept shorter than the KSK's effectivity period.
KSKの有効期間よりもZSKの有効期間を短くする動機は、オペレーターがKSKよりもZSKへの読み取りアクセスを頻繁にする可能性が高いという運用上の考慮に基づいています。したがって、ZSKがKSKと同じレベルの保護を提供できない場合（ゾーンキーがオンラインに保たれている場合など）、およびZSKの秘密キーの不正な開示のリスクが無視できない場合（たとえば、HSMが使用されていない場合）、ZSKの有効期間はKSKの有効期間よりも短くする必要があります。
In fact, if the risk of loss, theft, or other compromise is the same for a ZSK and a KSK, there is little reason to choose different effectivity periods for ZSKs and KSKs. And when the split between ZSKs and KSKs is not made, the argument is redundant.
実際、紛失、盗難、またはその他の妥協のリスクがZSKとKSKで同じである場合、ZSKとKSKで異なる有効期間を選択する理由はほとんどありません。また、ZSKとKSKの分割が行われない場合、引数は冗長になります。
There are certainly cases in which the use of a Single-Type Signing Scheme with a long key effectivity period is a good choice, for example, where the costs and risks of compromise, and the costs and risks involved with having to perform an emergency roll, are low.
重要な有効期間が長いシングルタイプの署名スキームの使用が良い選択であるケースは確かにあります。たとえば、妥協のコストとリスク、緊急ロールの実行に伴うコストとリスク、低いです。
At the time of this writing, there are three types of signature algorithms that can be used in DNSSEC: RSA, Digital Signature Algorithm (DSA), and GOST. Proposals for other algorithms are in the making. All three are fully specified in many freely available documents and are widely considered to be patent-free. The creation of signatures with RSA and DSA takes roughly the same time, but DSA is about ten times slower for signature verification. Also note that, in the context of DNSSEC, DSA is limited to a maximum of 1024-bit keys.
この記事の執筆時点では、DNSSECで使用できる署名アルゴリズムには、RSA、デジタル署名アルゴリズム（DSA）、GOSTの3種類があります。他のアルゴリズムの提案が行われています。 3つすべては、無料で入手できる多くのドキュメントで完全に指定されており、特許がないと広く見なされています。 RSAとDSAを使用した署名の作成にはほぼ同じ時間がかかりますが、DSAは署名の検証に約10倍遅くなります。また、DNSSECのコンテキストでは、DSAは最大1024ビットのキーに制限されていることに注意してください。
We suggest the use of RSA/SHA-256 as the preferred signature algorithm and RSA/SHA-1 as an alternative. Both have advantages and disadvantages. RSA/SHA-1 has been deployed for many years, while RSA/SHA-256 has only begun to be deployed. On the other hand, it is expected that if effective attacks on either algorithm appear, they will appear for RSA/SHA-1 first. RSA/MD5 should not be considered for use because RSA/MD5 will very likely be the first common-use signature algorithm to be targeted for an effective attack.
推奨される署名アルゴリズムとしてRSA / SHA-256を使用し、代替としてRSA / SHA-1を使用することをお勧めします。どちらにも長所と短所があります。 RSA / SHA-1は長年にわたって導入されてきましたが、RSA / SHA-256は導入が始まったばかりです。一方、いずれかのアルゴリズムに対する効果的な攻撃が発生した場合は、RSA / SHA-1に対して最初に出現することが予想されます。 RSA / MD5は、効果的な攻撃の対象となる最初の一般的な署名アルゴリズムである可能性が非常に高いため、RSA / MD5の使用は検討しないでください。
At the time of publication, it is known that the SHA-1 hash has cryptanalysis issues, and work is in progress to address them. The use of public-key algorithms based on hashes stronger than SHA-1 (e.g., SHA-256) is recommended, if these algorithms are available in implementations (see RFC 5702 [RFC5702] and RFC 4509 [RFC4509]).
公開の時点では、SHA-1ハッシュに暗号解読の問題があることがわかっており、それらに対処する作業が進行中です。これらのアルゴリズムが実装で利用できる場合は、SHA-1（SHA-256など）よりも強力なハッシュに基づく公開鍵アルゴリズムの使用をお勧めします（RFC 5702 [RFC5702]およびRFC 4509 [RFC4509]を参照）。
Also, at the time of publication, digital signature algorithms based on Elliptic Curve (EC) Cryptography with DNSSEC (GOST [RFC5933], Elliptic Curve Digital Signature Algorithm (ECDSA) [RFC6605]) are being standardized and implemented. The use of EC has benefits in terms of size. On the other hand, one has to balance that against the amount of validating resolver implementations that will not recognize EC signatures and thus treat the zone as insecure. Beyond the observation of this tradeoff, we will not discuss this further.
また、公開時には、DNSSECを使用した楕円曲線（EC）暗号化に基づくデジタル署名アルゴリズム（GOST [RFC5933]、楕円曲線デジタル署名アルゴリズム（ECDSA）[RFC6605]）が標準化および実装されています。 ECを使用すると、サイズの点でメリットがあります。一方で、EC署名を認識せず、ゾーンを安全でないものとして扱う検証レゾルバ実装の量とバランスを取る必要があります。このトレードオフの観察以外に、これについてこれ以上説明しません。
This section assumes RSA keys, as suggested in the previous section.
このセクションでは、前のセクションで提案したように、RSAキーを想定しています。
DNSSEC signing keys should be large enough to avoid all known cryptographic attacks during the effectivity period of the key. To date, despite huge efforts, no one has broken a regular 1024-bit key; in fact, the best completed attack is estimated to be the equivalent of a 700-bit key. An attacker breaking a 1024-bit signing key would need to expend phenomenal amounts of networked computing power in a way that would not be detected in order to break a single key. Because of this, it is estimated that most zones can safely use 1024-bit keys for at least the next ten years. (A 1024-bit asymmetric key has an approximate equivalent strength of a symmetric 80-bit key.)
DNSSEC署名鍵は、鍵の有効期間中にすべての既知の暗号攻撃を回避するのに十分な大きさである必要があります。今日まで、多大な努力にもかかわらず、通常の1024ビットキーを破った人はいません。実際、最もよく完了した攻撃は、700ビットのキーに相当すると推定されています。 1024ビットの署名鍵を破る攻撃者は、単一の鍵を破るために、検出されない方法で驚異的な量のネットワーク化されたコンピューティング能力を消費する必要があります。このため、ほとんどのゾーンは少なくとも今後10年間は1024ビットキーを安全に使用できると推定されています。 （1024ビットの非対称鍵には、対称の80ビット鍵とほぼ同等の強度があります。）
Depending on local policy (e.g., owners of keys that are used as extremely high value trust anchors, or non-anchor keys that may be difficult to roll over), it may be advisable to use lengths longer than 1024 bits. Typically, the next larger key size used is 2048 bits, which has the approximate equivalent strength of a symmetric 112-bit key (RFC 3766 [RFC3766]). Signing and verifying with a 2048-bit key takes longer than with a 1024-bit key. The increase depends on software and hardware implementations, but public operations (such as verification) are about four times slower, while private operations (such as signing) are about eight times slower.
ローカルポリシー（非常に高い値のトラストアンカーとして使用されるキーの所有者、またはロールオーバーが困難な非アンカーキーなど）によっては、1024ビットより長い長さを使用することをお勧めします。通常、次に使用される鍵のサイズは2048ビットで、対称の112ビット鍵とほぼ同等の強度があります（RFC 3766 [RFC3766]）。 2048ビットキーを使用した署名と検証は、1024ビットキーを使用した場合よりも時間がかかります。増加はソフトウェアとハードウェアの実装によって異なりますが、パブリック操作（検証など）は約4倍遅く、プライベート操作（署名など）は約8倍遅くなります。
Another way to decide on the size of a key to use is to remember that the effort it takes for an attacker to break a 1024-bit key is the same, regardless of how the key is used. If an attacker has the capability of breaking a 1024-bit DNSSEC key, he also has the capability of breaking one of the many 1024-bit Transport Layer Security (TLS) [RFC5246] trust anchor keys that are currently installed in web browsers. If the value of a DNSSEC key is lower to the attacker than the value of a TLS trust anchor, the attacker will use the resources to attack the latter.
使用するキーのサイズを決定するもう1つの方法は、キーの使用方法に関係なく、攻撃者が1024ビットキーを解読するのに必要な労力は同じであることを覚えておくことです。攻撃者が1024ビットDNSSECキーを解読する機能を持っている場合、攻撃者は現在Webブラウザーにインストールされている多くの1024ビットトランスポート層セキュリティ（TLS）[RFC5246]トラストアンカーキーの1つを解読する機能も持っています。 DNSSECキーの値が攻撃者にとってTLSトラストアンカーの値よりも低い場合、攻撃者はリソースを使用して後者を攻撃します。
It is possible that there will be an unexpected improvement in the ability for attackers to break keys and that such an attack would make it feasible to break 1024-bit keys but not 2048-bit keys. If such an improvement happens, it is likely that there will be a huge amount of publicity, particularly because of the large number of 1024-bit TLS trust anchors built into popular web browsers. At that time, all 1024-bit keys (both ones with parent zones and ones that are trust anchors) can be rolled over and replaced with larger keys.
攻撃者がキーを解読する機能に予期しない改善があり、そのような攻撃により1024ビットのキーを解読することは可能ですが、2048ビットのキーを解読することは不可能です。このような改善が行われた場合、特に人気のあるWebブラウザーに組み込まれている1024ビットTLSトラストアンカーの数が多いため、非常に大きな宣伝が行われる可能性があります。その時点で、すべての1024ビットキー（親ゾーンを持つものとトラストアンカーであるものの両方）をロールオーバーして、より大きなキーに置き換えることができます。
Earlier documents (including the previous version of this document) urged the use of longer keys in situations where a particular key was "heavily used". That advice may have been true 15 years ago, but it is not true today when using RSA algorithms and keys of 1024 bits or higher.
以前のバージョンのドキュメント（このドキュメントの以前のバージョンを含む）では、特定のキーが "頻繁に使用される"状況では、より長いキーの使用を推奨していました。そのアドバイスは15年前には真実だったかもしれませんが、RSAアルゴリズムと1024ビット以上のキーを使用する場合、今日は真実ではありません。
It is preferred 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/NSEC3 RRs. Then the augmented file can be transferred to the master.
可能な場合は、署名されるゾーンの秘密鍵とゾーンファイルのマスターコピーを保持し、オフラインでネットワークに接続されていない、物理的に安全なマシンでのみ使用することが推奨されます。定期的にアプリケーションを実行して、RRSIGおよびNSEC / NSEC3 RRを追加することにより、認証をゾーンに追加できます。次に、拡張ファイルをマスターに転送できます。
When relying on dynamic update [RFC3007] or any other update mechanism that runs at a regular interval to manage a signed zone, be aware that at least one private key of the zone will have to reside on the master server or reside on an HSM to which the server has access. This key is only as secure as the amount of exposure the server receives to unknown clients and on the level of security of the host. Although not mandatory, one could administer a zone using a "hidden master" scheme to minimize the risk. In this arrangement, the master name server that processes the updates is unavailable to general hosts on the Internet; it is not listed in the NS RRset. The name servers in the NS RRset are able to receive zone updates through IXFR, AXFR, or an out-of-band distribution mechanism, possibly in combination with NOTIFY or another mechanism to trigger zone replication.
動的更新[RFC3007]または定期的な間隔で実行されるその他の更新メカニズムを使用して署名済みゾーンを管理する場合は、ゾーンの少なくとも1つの秘密鍵がマスターサーバーに存在するか、HSMに存在する必要があることに注意してください。サーバーがアクセスできるもの。このキーの安全性は、サーバーが未知のクライアントに公開する量とホストのセキュリティレベルと同じです。必須ではありませんが、「隠しマスター」スキームを使用してゾーンを管理し、リスクを最小限に抑えることができます。この配置では、更新を処理するマスターネームサーバーは、インターネット上の一般的なホストでは使用できません。 NS RRsetにはリストされていません。 NS RRset内のネームサーバーは、IXFR、AXFR、または帯域外配布メカニズムを介してゾーンの更新を受信でき、NOTIFYまたは別のメカニズムと組み合わせて、ゾーンのレプリケーションをトリガーできます。
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 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.
理想的な状況は、ネットワークからの改ざんの可能性を回避するために、ネットワークへの一方向の情報フローを持つことです。ネットワーク上でゾーンマスターをオンラインに維持し、オフラインの署名者を介して単に循環させるだけでは、これは行われません。オンラインバージョンは、常駐しているホストが侵害された場合でも改ざんされる可能性があります。最大限のセキュリティを確保するには、ゾーンファイルのマスターコピーをオフネットにし、セキュリティで保護されていないネットワークを介した通信に基づいて更新しないでください。
The ideal situation may not be achievable because of economic tradeoffs between risks and costs. For instance, keeping a zone file off-line is not practical and will increase the costs of operating a DNS zone. So, in practice, the machines on which zone files are maintained will be connected to a network. Operators are advised to take security measures to shield the master copy against unauthorized access in order to prevent modification of DNS data before it is signed.
リスクとコストの間の経済的トレードオフのため、理想的な状況は達成できない場合があります。たとえば、ゾーンファイルをオフラインに保つことは実用的ではなく、DNSゾーンの運用コストが増加します。したがって、実際には、ゾーンファイルが保持されているマシンはネットワークに接続されます。オペレーターは、署名前のDNSデータの変更を防ぐために、不正コピーからマスターコピーを保護するセキュリティ対策を講じることをお勧めします。
Similarly, the choice for storing a private key in an HSM will be influenced by a tradeoff between various concerns:
同様に、HSMに秘密鍵を格納するための選択は、さまざまな問題の間のトレードオフに影響されます。
o The risks that an unauthorized person has unnoticed read access to the private key.
o 権限のない人が秘密鍵への読み取りアクセスに気付かれないリスク。
o The remaining window of opportunity for the attacker.
o 攻撃者にとって残りの機会の機会。
o The economic impact of the possible attacks (for a TLD, that impact will typically be higher than for an individual user).
o 起こりうる攻撃の経済的影響（TLDの場合、その影響は通常、個々のユーザーの場合よりも大きくなります）。
o The costs of rolling the (compromised) keys. (The cost of rolling a ZSK is lowest, and the cost of rolling a KSK that is in wide use as a trust anchor is highest.)
o （侵害された）鍵をローリングするコスト。 （ZSKをローリングするコストは最も低く、トラストアンカーとして広く使用されているKSKをローリングするコストは最も高いです。）
o The costs of buying and maintaining an HSM.
o HSMの購入と保守のコスト。
For dynamically updated secured zones [RFC3007], both the master copy and the private key that is used to update signatures on updated RRs will need to be on-line.
動的に更新される保護ゾーン[RFC3007]の場合、マスターコピーと、更新されたRRの署名の更新に使用される秘密キーの両方がオンラインである必要があります。
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 [RFC4086] and NIST SP 800-90A [NIST-SP-800-90A]. In particular, one should carefully assess whether the random number generator used during key generation adheres to these suggestions. Typically, HSMs tend to provide a good facility for key generation.
すべてのキーを注意深く生成することは、見過ごされがちですが、暗号で保護されたシステムでは絶対に不可欠な要素です。最長のキーで使用される最も強力なアルゴリズムは、攻撃者が可能性のあるキースペースのサイズを小さくして、徹底的に検索できるように推測できる場合は、まだ役に立ちません。ランダムキーの生成に関する技術的な提案は、RFC 4086 [RFC4086]およびNIST SP 800-90A [NIST-SP-800-90A]に記載されています。特に、鍵の生成中に使用される乱数ジェネレータがこれらの提案に準拠しているかどうかを注意深く評価する必要があります。通常、HSMは鍵生成のための優れた機能を提供する傾向があります。
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 preferred 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.
有効期間が長いキーは、より価値の高いターゲットを表し、短期間のキーよりも長時間攻撃を受けるため、特に敏感です。長期間の鍵生成は、エアギャップを介して、または最低でも高レベルの安全なハードウェアを介してネットワークから分離された方法でオフラインで発生することが好ましい。
An earlier version of this document (RFC 4641 [RFC4641]) made a differentiation between key lengths for KSKs used for zones that are high in the DNS hierarchy and those for KSKs used lower down in the hierarchy.
このドキュメントの以前のバージョン（RFC 4641 [RFC4641]）では、DNS階層の上位にあるゾーンに使用されるKSKのキー長と、階層の下位に使用されるKSKのキー長が区別されていました。
This distinction is now considered irrelevant. Longer key lengths for keys higher in the hierarchy are not useful because the cryptographic guidance is that everyone should use keys that no one can break. Also, it is impossible to judge which zones are more or less valuable to an attacker. An attack can only take place if the key compromise goes unnoticed and the attacker can act as a man-in-the-middle (MITM). For example, if example.com is compromised, and the attacker forges answers for somebank.example.com. and sends them out during an MITM, when the attack is discovered it will be simple to prove that example.com has been compromised, and the KSK will be rolled.
この区別は現在、無関係と見なされています。暗号化のガイダンスでは、誰もが破ることのできないキーを使用する必要があるため、階層の上位にあるキーのキー長を長くしても役に立たない。また、攻撃者にとってどのゾーンが多かれ少なかれ価値があるかを判断することは不可能です。攻撃は、キーの侵害が気付かれず、攻撃者が中間者（MITM）として行動できる場合にのみ発生します。たとえば、example.comが侵害され、攻撃者がsomebank.example.comの回答を偽造した場合です。そしてMITM中にそれらを送信します。攻撃が発見された場合、example.comが侵害されたことを証明するのは簡単であり、KSKがロールされます。
Regardless of whether a zone uses periodic key rollovers or only rolls keys in case of an irregular event, key rollovers are a fact of life when using DNSSEC. Zone administrators who are in the process of rolling their keys have to take into account the fact 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を使用する場合、キーロールオーバーは実際の事実です。キーのローリングを行っているゾーン管理者は、以前のバージョンのゾーンで公開されたデータが依然としてキャッシュに存在するという事実を考慮する必要があります。 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.
この最も差し迫った例は、古いキーで署名されたゾーンマテリアルが、古いゾーンキーがキャッシュされていないリゾルバによって検証されているときに発生します。古いキーが現在のゾーンに存在しない場合、この検証は失敗し、データに偽のマークが付けられます。または、ローカルキャッシュにある古いキーに対して新しいキーで署名されたデータを検証する試みが行われ、データに偽のマークが付けられる可能性もあります。
The typographic conventions used in the diagrams below are explained in Appendix B.
以下の図で使用されている表記規則は、付録Bで説明されています。
If the choice for splitting ZSKs and KSKs has been made, then those two types of keys can be rolled separately, and ZSKs can be rolled without taking into account DS records from the parent or the configuration of such a key as the trust anchor.
ZSKとKSKを分割することを選択した場合、これら2つのタイプのキーは個別にロールでき、親からのDSレコードやトラストアンカーなどのキーの構成を考慮せずにZSKをロールできます。
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 scheme, described in Section 4.1.1.1, uses
「ゾーン署名鍵のロールオーバー」の場合、ロールオーバー中にキャッシュされたデータを新しい鍵セットで検証できること、または新しく生成された署名を鍵がキャッシュされたまま検証できることを確認するには、2つの方法があります。セクション4.1.1.1で説明されている1つのスキームは、
key pre-publication; the other uses double signatures, as described in Section 4.1.1.2. The pros and cons are described in Section 4.1.1.3.
重要な事前公開;セクション4.1.1.2で説明されているように、もう1つは二重署名を使用します。長所と短所はセクション4.1.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.
このセクションでは、ゾーン内のすべてのデータに2回署名する必要なくZSKロールオーバーを実行する方法、つまり「事前公開キーのロールオーバー」を示します。この方法には、鍵が危険にさらされた場合の利点があります。古いキーが危険にさらされている場合、新しいキーはすでにDNSで配布されています。その後、ゾーン管理者は新しいキーにすばやく切り替えて、侵害されたキーをゾーンから削除できます。もう1つの大きな利点は、Double-Signature ZSKロールオーバーの場合のように、ゾーンサイズが2倍にならないことです。
Pre-Publish key rollover from DNSKEY_Z_10 to DNSKEY_Z_11 involves four stages as follows:
DNSKEY_Z_10からDNSKEY_Z_11への事前公開キーのロールオーバーには、次の4つの段階があります。
------------------------------------------------------------
initial new DNSKEY new RRSIGs
------------------------------------------------------------
SOA_0 SOA_1 SOA_2
RRSIG_Z_10(SOA) RRSIG_Z_10(SOA) RRSIG_Z_11(SOA)
DNSKEY_K_1 DNSKEY_K_1 DNSKEY_K_1
DNSKEY_Z_10 DNSKEY_Z_10 DNSKEY_Z_10
DNSKEY_Z_11 DNSKEY_Z_11
RRSIG_K_1(DNSKEY) RRSIG_K_1(DNSKEY) RRSIG_K_1(DNSKEY)
------------------------------------------------------------
------------------------------------------------------------
DNSKEY removal
------------------------------------------------------------
SOA_3
RRSIG_Z_11(SOA)
DNSKEY_K_1 DNSKEY_Z_11
DNSKEY_K_1 DNSKEY_Z_11
RRSIG_K_1(DNSKEY)
------------------------------------------------------------
Figure 1: Pre-Publish Key Rollover
図1：事前公開キーのロールオーバー
initial: Initial version of the zone: DNSKEY_K_1 is the Key Signing Key. DNSKEY_Z_10 is used to sign all the data of the zone, i.e., it is the Zone Signing Key.
initial：ゾーンの初期バージョン：DNSKEY_K_1は鍵署名鍵です。 DNSKEY_Z_10は、ゾーンのすべてのデータに署名するために使用されます。つまり、ゾーン署名キーです。
new DNSKEY: DNSKEY_Z_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 its 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 the TTL value of the key set.
新しいDNSKEY：DNSKEY_Z_11がキーセットに導入されました（このキーで署名はまだ生成されていませんが、公開キーへのブルートフォース攻撃に対しては安全ではないことに注意してください）。このプレロールフェーズの最小期間は、データが権限のあるサーバーに伝達されるのにかかる時間と、キーセットのTTL値です。
new RRSIGs: At the "new RRSIGs" stage, DNSKEY_Z_11 is used to sign the data in the zone exclusively (i.e., all the signatures from DNSKEY_Z_10 are removed from the zone). DNSKEY_Z_10 remains published in the key set. This way, data that was loaded into caches from the zone in the "new DNSKEY" step can still be verified with key sets fetched from this version of the zone. The minimum time that the key set including DNSKEY_Z_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.
新しいRRSIG：「新しいRRSIG」の段階で、DNSKEY_Z_11を使用してゾーン内のデータに排他的に署名します（つまり、DNSKEY_Z_10からのすべての署名がゾーンから削除されます）。 DNSKEY_Z_10は、キーセットで公開されたままです。このようにして、「新しいDNSKEY」ステップでゾーンからキャッシュにロードされたデータは、このバージョンのゾーンからフェッチされたキーセットで引き続き検証できます。 DNSKEY_Z_10を含むキーセットが公開される最小時間は、以前のバージョンのゾーンのゾーンデータが古いキャッシュから期限切れになるまでの時間、つまり、このゾーンがすべての権限のあるサーバーに伝達されるまでの時間です。に加えて、以前のバージョンのゾーンのデータの最大ゾーンTTL値。
DNSKEY removal: DNSKEY_Z_10 is removed from the zone. The key set, now only containing DNSKEY_K_1 and DNSKEY_Z_11, is re-signed with DNSKEY_K_1.
DNSKEYの削除：DNSKEY_Z_10がゾーンから削除されます。鍵セットは、DNSKEY_K_1とDNSKEY_Z_11のみを含むようになり、DNSKEY_K_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_Z_12 and again a newer one, numbered 13, in "new DNSKEY (II)":
上記のスキームは、ロールオーバーの直後に常に「future」キーを公開することで簡略化できます。スキームは次のようになります（2つのロールオーバーを示します）。将来のキーは「新しいDNSKEY」でDNSKEY_Z_12として導入され、13と番号が付けられた新しいキーが「新しいDNSKEY（II）」で導入されます。
initial new RRSIGs new DNSKEY
-----------------------------------------------------------------
SOA_0 SOA_1 SOA_2
RRSIG_Z_10(SOA) RRSIG_Z_11(SOA) RRSIG_Z_11(SOA)
DNSKEY_K_1 DNSKEY_K_1 DNSKEY_K_1
DNSKEY_Z_10 DNSKEY_Z_10 DNSKEY_Z_11
DNSKEY_Z_11 DNSKEY_Z_11 DNSKEY_Z_12
RRSIG_K_1(DNSKEY) RRSIG_K_1(DNSKEY) RRSIG_K_1(DNSKEY)
----------------------------------------------------------------
----------------------------------------------------------------
new RRSIGs (II) new DNSKEY (II)
----------------------------------------------------------------
SOA_3 SOA_4
RRSIG_Z_12(SOA) RRSIG_Z_12(SOA)
DNSKEY_K_1 DNSKEY_K_1
DNSKEY_Z_11 DNSKEY_Z_12
DNSKEY_Z_12 DNSKEY_Z_13
RRSIG_K_1(DNSKEY) RRSIG_K_1(DNSKEY)
----------------------------------------------------------------
Figure 2: Pre-Publish Zone Signing Key Rollover, Showing Two Rollovers
図2：事前発行ゾーン署名キーロールオーバー、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 rollover using the double zone data signature scheme, aptly named "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 propagation delay plus the Maximum Zone TTL of previous versions of the zone.
「新しいDNSKEY」段階では、ゾーンファイルの新しいバージョンがすべての権限のあるサーバーに伝達される必要があり、（離れた）キャッシュに存在するデータは期限切れになる必要があり、少なくとも伝達遅延と最大ゾーンTTLが必要ですゾーンの以前のバージョン。
Double-Signature ZSK rollover involves three stages as follows:
二重署名ZSKロールオーバーには、次の3つの段階があります。
----------------------------------------------------------------
initial new DNSKEY DNSKEY removal
----------------------------------------------------------------
SOA_0 SOA_1 SOA_2
RRSIG_Z_10(SOA) RRSIG_Z_10(SOA)
RRSIG_Z_11(SOA) RRSIG_Z_11(SOA)
DNSKEY_K_1 DNSKEY_K_1 DNSKEY_K_1
DNSKEY_Z_10 DNSKEY_Z_10
DNSKEY_Z_11 DNSKEY_Z_11
RRSIG_K_1(DNSKEY) RRSIG_K_1(DNSKEY) RRSIG_K_1(DNSKEY)
----------------------------------------------------------------
Figure 3: Double-Signature Zone Signing Key Rollover
図3：二重署名ゾーン署名鍵のロールオーバー
initial: Initial version of the zone: DNSKEY_K_1 is the Key Signing Key. DNSKEY_Z_10 is used to sign all the data of the zone, i.e., it is the Zone Signing Key.
initial：ゾーンの初期バージョン：DNSKEY_K_1は鍵署名鍵です。 DNSKEY_Z_10は、ゾーンのすべてのデータに署名するために使用されます。つまり、ゾーン署名キーです。
new DNSKEY: At the "new DNSKEY" stage, DNSKEY_Z_11 is introduced into the key set and all the data in the zone is signed with DNSKEY_Z_10 and DNSKEY_Z_11. The rollover period will need to continue until all data from version 0 (i.e., the version of the zone data containing SOA_0) of the zone has been replaced in all secondary servers and then has expired from remote caches. This will take at least the propagation delay plus the Maximum Zone TTL of version 0 of the zone.
新しいDNSKEY：「新しいDNSKEY」の段階で、DNSKEY_Z_11がキーセットに導入され、ゾーン内のすべてのデータがDNSKEY_Z_10およびDNSKEY_Z_11で署名されます。ロールオーバー期間は、ゾーンのバージョン0（つまり、SOA_0を含むゾーンデータのバージョン）からのすべてのデータがすべてのセカンダリサーバーで置き換えられ、リモートキャッシュから期限切れになるまで継続する必要があります。これには、少なくとも伝搬遅延とゾーンのバージョン0の最大ゾーンTTLがかかります。
DNSKEY removal: DNSKEY_Z_10 is removed from the zone, as are all signatures created with it. The key set, now only containing DNSKEY_Z_11, is re-signed with DNSKEY_K_1 and DNSKEY_Z_11.
DNSKEYの削除：DNSKEY_Z_10はゾーンから削除され、すべての署名もゾーンから作成されます。鍵セットはDNSKEY_Z_11のみを含むようになり、DNSKEY_K_1とDNSKEY_Z_11で再署名されます。
At every instance, RRSIGs from the previous version of the zone can be verified with the DNSKEY RRset from the current version and vice versa. The duration of the "new DNSKEY" phase and the period between rollovers should be at least the propagation delay to secondary servers plus the Maximum Zone TTL of the previous version of the zone.
すべてのインスタンスで、前のバージョンのゾーンのRRSIGを現在のバージョンのDNSKEY RRsetで検証できます。逆も同様です。 「新しいDNSKEY」フェーズの期間とロールオーバー間の期間は、少なくともセカンダリサーバーへの伝播遅延に、以前のバージョンのゾーンの最大ゾーンTTLを加えたものでなければなりません。
Note that in this example we assumed for simplicity that the zone was not modified during the rollover. In fact, new data can be introduced at any time during this period, 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 stages. Also, the Pre-Publish scheme involves more parental work when used for KSK rollovers, as explained in Section 4.1.2.
事前公開キーのロールオーバー：このロールオーバーでは、ゾーンデータに2回署名する必要はありません。代わりに、実際のロールオーバーの前に、新しいキーがキーセットで公開されるため、暗号解析攻撃に利用できます。小さな欠点は、このプロセスには4つの段階が必要なことです。また、セクション4.1.2で説明するように、KSKロールオーバーに使用した場合、事前発行スキームにはより多くの親の作業が含まれます。
Double-Signature ZSK rollover: The drawback of this approach 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 stages.
二重署名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.
キー署名キーのロールオーバーについては、ゾーン署名キーのロールオーバーと同じ考慮事項が適用されます。ただし、Double-Signatureスキームを使用して、キャッシュ内の古いデータ（頂点キーセットのみ）を新しいキーセットで検証でき、その逆も可能です。鍵セットのみがKSKで署名されているため、ゾーンサイズの考慮事項は適用されません。
Note that KSK rollovers and ZSK rollovers are different in the sense that a KSK rollover requires interaction with the parent (and possibly replacing trust anchors) and the ensuing delay while waiting for it.
KSKロールオーバーとZSKロールオーバーは、KSKロールオーバーが親との相互作用（および場合によってはトラストアンカーの置き換え）を必要とし、それを待機している間に遅延が発生するという点で異なります。
---------------------------------------------------------------------
initial new DNSKEY DS change DNSKEY removal
---------------------------------------------------------------------
Parent:
SOA_0 -----------------------------> SOA_1 ------------------------>
RRSIG_par(SOA) --------------------> RRSIG_par(SOA) --------------->
DS_K_1 ----------------------------> DS_K_2 ----------------------->
RRSIG_par(DS) ---------------------> RRSIG_par(DS) ---------------->
Child:
SOA_0 SOA_1 -----------------------> SOA_2
RRSIG_Z_10(SOA) RRSIG_Z_10(SOA) -------------> RRSIG_Z_10(SOA)
DNSKEY_K_1 DNSKEY_K_1 ------------------>
DNSKEY_K_2 ------------------> DNSKEY_K_2
DNSKEY_Z_10 DNSKEY_Z_10 -----------------> DNSKEY_Z_10
RRSIG_K_1(DNSKEY) RRSIG_K_1 (DNSKEY) ---------->
RRSIG_K_2 (DNSKEY) ----------> RRSIG_K_2(DNSKEY)
---------------------------------------------------------------------
Figure 4: Stages of Deployment for a Double-Signature Key Signing Key Rollover
図4：二重署名キー署名キーロールオーバーの展開の段階
initial: Initial version of the zone. The parental DS points to DNSKEY_K_1. Before the rollover starts, the child will have to verify what the TTL is of the DS RR that points to DNSKEY_K_1 -- it is needed during the rollover, and we refer to the value as TTL_DS.
initial：ゾーンの初期バージョン。親DSはDNSKEY_K_1を指します。ロールオーバーが始まる前に、子はDNSKEY_K_1を指すDS RRのTTLが何であるかを確認する必要があります。これはロールオーバー中に必要であり、値をTTL_DSと呼びます。
new DNSKEY: During the "new DNSKEY" phase, the zone administrator generates a second KSK, DNSKEY_K_2. 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 DNSKEY_K_2. 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、DNSKEY_K_2を生成します。キーは親に提供され、子はDNSKEY_K_2を指す新しいDS RRが生成されるまで待機する必要があります。そのDS RRが親のゾーンに対して権限のあるすべてのサーバーで公開された後、ゾーン管理者は少なくともTTL_DSを待機して、古いDS RRがキャッシュから期限切れになったことを確認する必要があります。
DS change: The parent replaces DS_K_1 with DS_K_2.
DSの変更：親はDS_K_1をDS_K_2に置き換えます。
DNSKEY removal: DNSKEY_K_1 has been removed.
DNSKEYの削除：DNSKEY_K_1が削除されました。
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 relationship, 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. This is known as a KSK Double-DS rollover and is shown in Figure 5. This method has some drawbacks for KSKs. We first describe the rollover scheme and then indicate these drawbacks.
上記のシナリオでは、子供との信頼の有効な連鎖を維持する責任があります。また、親にはゾーンごとに（アルゴリズムごとに）DS RRが1つしかないという前提に基づいています。代替メカニズムが検討されています。確立された信頼関係を使用して、対話をインバンドで実行でき、子によるキーの削除を親から通知することができます。このメカニズムでは、親に2つのDS RRが存在する期間があります。これは、KSK Double-DSロールオーバーと呼ばれ、図5に示されています。この方法には、KSKにいくつかの欠点があります。最初にロールオーバースキームについて説明し、次にこれらの欠点を示します。
--------------------------------------------------------------------
initial new DS new DNSKEY DS removal
--------------------------------------------------------------------
Parent:
SOA_0 SOA_1 ------------------------> SOA_2
RRSIG_par(SOA) RRSIG_par(SOA) ---------------> RRSIG_par(SOA)
DS_K_1 DS_K_1 ----------------------->
DS_K_2 -----------------------> DS_K_2
RRSIG_par(DS) RRSIG_par(DS) ----------------> RRSIG_par(DS)
Child:
SOA_0 -----------------------> SOA_1 ---------------------------->
RRSIG_Z_10(SOA) -------------> RRSIG_Z_10(SOA) ------------------>
DNSKEY_K_1 ------------------> DNSKEY_K_2 ----------------------->
DNSKEY_Z_10 -----------------> DNSKEY_Z_10 ---------------------->
RRSIG_K_1 (DNSKEY) ----------> RRSIG_K_2 (DNSKEY) --------------->
--------------------------------------------------------------------
Figure 5: Stages of Deployment for a Double-DS Key Signing Key Rollover
図5：二重DSキー署名キーロールオーバーの展開の段階
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 DS_K_1 and DS_K_2, pointing to DNSKEY_K_1 and DNSKEY_K_2, 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 DNSKEY_K_1 with DNSKEY_K_2. If the old key has expired from caches, at the "DS removal" phase the parent can be notified that the old DS record can be deleted.
子ゾーンがロールする場合、「新しいDS」フェーズ中に親に通知し、新しいキー（または対応するDS）を親に送信します。親はDS_K_1およびDS_K_2を公開し、それぞれDNSKEY_K_1およびDNSKEY_K_2をポイントします。新しいDSセットがDNSを介して伝達されるとすぐに行われるロールオーバー（「新しいDNSKEY」フェーズ）の間に、子はDNSKEY_K_1をDNSKEY_K_2に置き換えます。古いキーがキャッシュから期限切れになった場合、「DS削除」フェーズで、古いDSレコードを削除できることを親に通知できます。
The drawbacks of this scheme are that during the "new DS" phase, the parent cannot verify the match between the DS_K_2 RR and DNSKEY_K_2 using the DNS, as DNSKEY_K_2 is not yet published. Besides, we introduce a "security lame" key (see Section 4.3.3). Finally, the child-parent interaction consists of two steps. The "Double Signature" method only needs one interaction.
このスキームの欠点は、「新しいDS」フェーズ中に、DNSKEY_K_2がまだ公開されていないため、親がDNSを使用してDS_K_2 RRとDNSKEY_K_2の一致を確認できないことです。さらに、「セキュリティラメ」キーを導入します（セクション4.3.3を参照）。最後に、子と親の相互作用は2つのステップで構成されます。 「ダブルシグネチャ」メソッドでは、1回の対話のみが必要です。
The scenario sketched above assumes that the KSK is not in use as a trust anchor but that validating name servers exclusively depend on the parental DS record to establish the zone's security. If it is known that validating name servers have configured trust anchors, then that needs to be taken into account. Here, we assume that zone administrators will deploy RFC 5011 [RFC5011] style rollovers.
上記のシナリオでは、KSKがトラストアンカーとして使用されていないことを前提としていますが、ネームサーバーの検証は、ゾーンのセキュリティを確立するために親のDSレコードに排他的に依存しています。検証するネームサーバーでトラストアンカーが構成されていることがわかっている場合は、それを考慮する必要があります。ここでは、ゾーン管理者がRFC 5011 [RFC5011]スタイルのロールオーバーを展開すると想定しています。
RFC 5011 style rollovers increase the duration of key rollovers: The key to be removed must first be revoked. Thus, before the DNSKEY_K_1 removal phase, DNSKEY_K_1 must be published for one more Maximum Zone TTL with the REVOKE bit set. The revoked key must be self-signed, so in this phase the DNSKEY RRset must also be signed with DNSKEY_K_1.
RFC 5011スタイルのロールオーバーにより、キーのロールオーバーの期間が長くなります。削除するキーを最初に取り消す必要があります。したがって、DNSKEY_K_1削除フェーズの前に、REVOKEビットが設定された1つ以上の最大ゾーンTTLに対してDNSKEY_K_1を公開する必要があります。取り消されたキーは自己署名する必要があるため、このフェーズでは、DNSKEY RRsetもDNSKEY_K_1で署名する必要があります。
The rollover of a key when a Single-Type Signing Scheme is used is subject to the same requirement as the rollover of a KSK or ZSK: During any stage of the rollover, the chain of trust needs to continue to validate for any combination of data in the zone as well as data that may still live in distant caches.
シングルタイプ署名方式を使用する場合の鍵のロールオーバーには、KSKまたはZSKのロールオーバーと同じ要件が適用されます。ロールオーバーのどの段階でも、信頼のチェーンはデータの任意の組み合わせを検証し続ける必要があります。ゾーン内のデータと、まだ離れたキャッシュに残っているデータ。
There are two variants for this rollover. Since the choice for a Single-Type Signing Scheme is motivated by operational simplicity, we describe the most straightforward rollover scheme first.
このロールオーバーには2つのバリアントがあります。シングルタイプ署名方式の選択は操作の単純さによって動機付けられるため、最初に最も簡単なロールオーバー方式について説明します。
-------------------------------------------------------------------
initial new DNSKEY DS change DNSKEY removal
-------------------------------------------------------------------
Parent:
SOA_0 --------------------------> SOA_1 ---------------------->
RRSIG_par(SOA) -----------------> RRSIG_par(SOA) ------------->
DS_S_1 -------------------------> DS_S_2 --------------------->
RRSIG_par(DS_S_1) --------------> RRSIG_par(DS_S_2) ---------->
Child:
SOA_0 SOA_1 ----------------------> SOA_2
RRSIG_S_1(SOA) RRSIG_S_1(SOA) ------------->
RRSIG_S_2(SOA) -------------> RRSIG_S_2(SOA)
DNSKEY_S_1 DNSKEY_S_1 ----------------->
DNSKEY_S_2 -----------------> DNSKEY_S_2
RRSIG_S_1(DNSKEY) RRSIG_S_1(DNSKEY) ---------->
RRSIG_S_2(DNSKEY) ----------> RRSIG_S_2(DNSKEY)
-------------------------------------------------------------------
Figure 6: Stages of the Straightforward Rollover in a Single-Type Signing Scheme
図6：単一タイプの署名スキームにおける単純なロールオーバーの段階
initial: Parental DS points to DNSKEY_S_1. All RRsets in the zone are signed with DNSKEY_S_1.
initial：ペアレンタルDSはDNSKEY_S_1を指します。ゾーン内のすべてのRRsetはDNSKEY_S_1で署名されています。
new DNSKEY: A new key (DNSKEY_S_2) is introduced, and all the RRsets are signed with both DNSKEY_S_1 and DNSKEY_S_2.
新しいDNSKEY：新しいキー（DNSKEY_S_2）が導入され、すべてのRRsetがDNSKEY_S_1とDNSKEY_S_2の両方で署名されます。
DS change: After the DNSKEY RRset with the two keys had time to propagate into distant caches (that is, the key set exclusively containing DNSKEY_S_1 has been expired), the parental DS record can be changed.
DSの変更：2つのキーを持つDNSKEY RRsetが離れたキャッシュに伝播する時間があった後（つまり、DNSKEY_S_1のみを含むキーセットが期限切れになった後）、親のDSレコードを変更できます。
DNSKEY removal: After the DS RRset containing DS_S_1 has expired from distant caches, DNSKEY_S_1 can be removed from the DNSKEY RRset.
DNSKEYの削除：DS_S_1を含むDS RRsetが遠方のキャッシュから期限切れになった後、DNSKEY_S_1をDNSKEY RRsetから削除できます。
In this first variant, the new signatures and new public key are added to the zone. Once they are propagated, the DS at the parent is switched. If the old DS has expired from the caches, the old signatures and old public key can be removed from the zone.
この最初のバリアントでは、新しい署名と新しい公開鍵がゾーンに追加されます。伝達されると、親のDSが切り替えられます。古いDSがキャッシュから期限切れになった場合、古い署名と古い公開鍵をゾーンから削除できます。
This rollover has the drawback that it introduces double signatures over all data of the zone. Taking these zone size considerations into account, it is possible to not introduce the signatures made with DNSKEY_S_2 at the "new DNSKEY" step. Instead, signatures of DNSKEY_S_1 are replaced with signatures of DNSKEY_S_2 in an additional stage between the "DS change" and "DNSKEY removal" step: After the DS RRset containing DS_S_1 has expired from distant caches, the signatures can be swapped. Only after the new signatures made with DNSKEY_S_2 have been propagated can the old public key DNSKEY_S_1 be removed from the DNSKEY RRset.
このロールオーバーには、ゾーンのすべてのデータに二重の署名が導入されるという欠点があります。これらのゾーンサイズの考慮事項を考慮すると、「新しいDNSKEY」ステップでDNSKEY_S_2で作成された署名を導入しないことが可能です。代わりに、 "DSの変更"と "DNSKEYの削除"の間の追加の段階で、DNSKEY_S_1の署名がDNSKEY_S_2の署名に置き換えられます。DS_S_1を含むDS RRsetが離れたキャッシュから期限切れになった後、署名を交換できます。 DNSKEY_S_2で作成された新しい署名が伝達された後にのみ、古い公開鍵DNSKEY_S_1をDNSKEY RRsetから削除できます。
The second variant of the Single-Type Signing Scheme Key rollover is the Double-DS rollover. In this variant, one introduces a new DNSKEY into the key set and submits the new DS to the parent. The new key is not yet used to sign RRsets. The signatures made with DNSKEY_S_1 are replaced with signatures made with DNSKEY_S_2 at the moment that DNSKEY_S_2 and DS_S_2 have been propagated.
シングルタイプ署名方式キーロールオーバーの2番目のバリアントは、ダブルDSロールオーバーです。このバリアントでは、新しいDNSKEYをキーセットに導入し、新しいDSを親に送信します。新しいキーは、RRsetの署名にはまだ使用されていません。 DNSKEY_S_1で作成された署名は、DNSKEY_S_2およびDS_S_2が伝達された時点で、DNSKEY_S_2で作成された署名に置き換えられます。
-----------------------------------------------------------------------
initial new DS new RRSIG DS removal
-----------------------------------------------------------------------
Parent:
SOA_0 SOA_1 -------------------------> SOA_2
RRSIG_par(SOA) RRSIG_par(SOA) ----------------> RRSIG_par(SOA)
DS_S_1 DS_S_1 ------------------------>
DS_S_2 ------------------------> DS_S_2
RRSIG_par(DS) RRSIG_par(DS) -----------------> RRSIG_par(DS)
Child:
SOA_0 SOA_1 SOA_2 SOA_3
RRSIG_S_1(SOA) RRSIG_S_1(SOA) RRSIG_S_2(SOA) RRSIG_S_2(SOA)
DNSKEY_S_1 DNSKEY_S_1 DNSKEY_S_1
DNSKEY_S_2 DNSKEY_S_2 DNSKEY_S_2
RRSIG_S_1 (DNSKEY) RRSIG_S_2(DNSKEY) RRSIG_S_2(DNSKEY)
-----------------------------------------------------------------------
Figure 7: Stages of Deployment for a Double-DS Rollover in a Single-Type Signing Scheme
図7：シングルタイプ署名スキームでのダブルDSロールオーバーの展開段階
A special class of key rollovers is the one needed for a change of signature algorithms (either adding a new algorithm, removing an old algorithm, or both). Additional steps are needed to retain integrity during this rollover. We first describe the generic case; special considerations for rollovers that involve trust anchors and single-type keys are discussed later.
鍵ロールオーバーの特別なクラスは、署名アルゴリズムの変更（新しいアルゴリズムの追加、古いアルゴリズムの削除、またはその両方）に必要なクラスです。このロールオーバー中に整合性を維持するには、追加の手順が必要です。最初に一般的なケースについて説明します。トラストアンカーと単一タイプのキーを含むロールオーバーの特別な考慮事項については、後で説明します。
There exist both a conservative and a liberal approach for algorithm rollover. This has to do with Section 2.2 of RFC 4035 [RFC4035]:
アルゴリズムのロールオーバーには、保守的なアプローチとリベラルなアプローチの両方が存在します。これは、RFC 4035 [RFC4035]のセクション2.2に関係しています。
There MUST be an RRSIG for each RRset using at least one DNSKEY of each algorithm in the zone apex DNSKEY RRset. The apex DNSKEY RRset itself MUST be signed by each algorithm appearing in the DS RRset located at the delegating parent (if any).
ゾーン頂点DNSKEY RRsetの各アルゴリズムの少なくとも1つのDNSKEYを使用して、各RRsetにRRSIGが存在する必要があります。 apex DNSKEY RRset自体は、委任する親（存在する場合）にあるDS RRsetに現れる各アルゴリズムによって署名されなければなりません（MUST）。
The conservative approach interprets this section very strictly, meaning that it expects that every RRset has a valid signature for every algorithm signaled by the zone apex DNSKEY RRset, including RRsets in caches. The liberal approach uses a more loose interpretation of the section and limits the rule to RRsets in the zone at the authoritative name servers. There is a reasonable argument for saying that this is valid, because the specific section is a subsection of Section 2 ("Zone Signing") of RFC 4035.
保守的なアプローチでは、このセクションが非常に厳密に解釈されます。つまり、すべてのRRsetには、キャッシュ内のRRsetを含め、ゾーンの頂点DNSKEY RRsetによって通知されるすべてのアルゴリズムに対して有効な署名があることが期待されます。リベラルなアプローチでは、セクションのより緩やかな解釈を使用し、権限のあるネームサーバーのゾーン内のRRsetにルールを制限します。特定のセクションはRFC 4035のセクション2（「ゾーン署名」）のサブセクションであるため、これが有効であると言うのに妥当な議論があります。
When following the more liberal approach, algorithm rollover is just as easy as a regular Double-Signature KSK rollover (Section 4.1.2). Note that the Double-DS KSK rollover method cannot be used, since that would introduce a parental DS of which the apex DNSKEY RRset has not been signed with the introduced algorithm.
よりリベラルなアプローチに従う場合、アルゴリズムのロールオーバーは通常のDouble-Signature KSKロールオーバーと同じくらい簡単です（セクション4.1.2）。 Double-DS KSKロールオーバー方式を使用できないことに注意してください。これは、導入されたアルゴリズムで頂点DNSKEY RRsetが署名されていない親DSを導入するためです。
However, there are implementations of validators known to follow the more conservative approach. Performing a Double-Signature KSK algorithm rollover will temporarily make your zone appear as Bogus by such validators during the rollover. Therefore, the rollover described in this section will explain the stages of deployment and will assume that the conservative approach is used.
ただし、より保守的なアプローチに従うことが知られているバリデーターの実装があります。 Double-Signature KSKアルゴリズムのロールオーバーを実行すると、ロールオーバー中に、このようなバリデーターによってゾーンが一時的に偽として表示されます。したがって、このセクションで説明するロールオーバーでは、展開の段階について説明し、保守的なアプローチが使用されていることを前提としています。
When adding a new algorithm, the signatures should be added first. After the TTL of RRSIGs has expired and caches have dropped the old data covered by those signatures, the DNSKEY with the new algorithm can be added.
新しいアルゴリズムを追加するときは、最初に署名を追加する必要があります。 RRSIGのTTLが期限切れになり、キャッシュがそれらのシグネチャでカバーされた古いデータをドロップした後、新しいアルゴリズムを備えたDNSKEYを追加できます。
After the new algorithm has been added, the DS record can be exchanged using Double-Signature KSK rollover.
新しいアルゴリズムが追加された後、DSレコードはDouble-Signature KSKロールオーバーを使用して交換できます。
When removing an old algorithm, the DS for the algorithm should be removed from the parent zone first, followed by the DNSKEY and the signatures (in the child zone).
古いアルゴリズムを削除する場合、まずアルゴリズムのDSを親ゾーンから削除し、次にDNSKEYと署名（子ゾーン内）を削除する必要があります。
Figure 8 describes the steps.
図8に手順を示します。
----------------------------------------------------------------
initial new RRSIGs new DNSKEY
----------------------------------------------------------------
Parent:
SOA_0 -------------------------------------------------------->
RRSIG_par(SOA) ----------------------------------------------->
DS_K_1 ------------------------------------------------------->
RRSIG_par(DS_K_1) -------------------------------------------->
Child:
SOA_0 SOA_1 SOA_2
RRSIG_Z_10(SOA) RRSIG_Z_10(SOA) RRSIG_Z_10(SOA)
RRSIG_Z_11(SOA) RRSIG_Z_11(SOA)
DNSKEY_K_1 DNSKEY_K_1 DNSKEY_K_1 DNSKEY_K_2 DNSKEY_Z_10 DNSKEY_Z_10 DNSKEY_Z_10 DNSKEY_Z_11 RRSIG_K_1(DNSKEY) RRSIG_K_1(DNSKEY) RRSIG_K_1(DNSKEY) RRSIG_K_2(DNSKEY)
DNSKEY_K_1 DNSKEY_K_1 DNSKEY_K_1 DNSKEY_K_2 DNSKEY_Z_10 DNSKEY_Z_10 DNSKEY_Z_10 DNSKEY_Z_11 RRSIG_K_1（DNSKEY）RRSIG_K_1（DNSKEY）RRSIG_K_1（DNSKEY）RRSIG_K_2（DNSKEY）
----------------------------------------------------------------
new DS DNSKEY removal RRSIGs removal
----------------------------------------------------------------
Parent:
SOA_1 ------------------------------------------------------->
RRSIG_par(SOA) ---------------------------------------------->
DS_K_2 ------------------------------------------------------>
RRSIG_par(DS_K_2) ------------------------------------------->
Child:
-------------------> SOA_3 SOA_4
-------------------> RRSIG_Z_10(SOA)
-------------------> RRSIG_Z_11(SOA) RRSIG_Z_11(SOA)
------------------->
-------------------> DNSKEY_K_2 DNSKEY_K_2
------------------->
-------------------> DNSKEY_Z_11 DNSKEY_Z_11
------------------->
-------------------> RRSIG_K_2(DNSKEY) RRSIG_K_2(DNSKEY)
----------------------------------------------------------------
Figure 8: Stages of Deployment during an Algorithm Rollover
図8：アルゴリズムロールオーバー中の展開の段階
initial: Describes the state of the zone before any transition is done. The number of the keys may vary, but all keys (in DNSKEY records) for the zone use the same algorithm.
initial：移行が行われる前のゾーンの状態を示します。キーの数は異なる場合がありますが、ゾーンのすべてのキー（DNSKEYレコード内）は同じアルゴリズムを使用します。
new RRSIGs: The signatures made with the new key over all records in the zone are added, but the key itself is not. This step is needed to propagate the signatures created with the new algorithm to the caches. If this is not done, it is possible for a resolver to retrieve the new DNSKEY RRset (containing the new algorithm) but to have RRsets in its cache with signatures created by the old DNSKEY RRset (i.e., without the new algorithm).
新しいRRSIG：ゾーン内のすべてのレコードに対して新しいキーで作成された署名が追加されますが、キー自体は追加されません。この手順は、新しいアルゴリズムで作成された署名をキャッシュに伝播するために必要です。これが行われない場合、リゾルバーは新しいDNSKEY RRset（新しいアルゴリズムを含む）を取得できますが、古いDNSKEY RRsetによって作成されたシグニチャー（つまり、新しいアルゴリズムなし）を含むRRsetをキャッシュに持つことができます。
The RRSIG for the DNSKEY RRset does not need to be pre-published (since these records will travel together) and does not need special processing in order to keep them synchronized.
DNSKEY RRsetのRRSIGは事前に公開する必要はなく（これらのレコードは一緒に移動するため）、それらを同期状態に保つために特別な処理を行う必要はありません。
new DNSKEY: After the old data has expired from caches, the new key can be added to the zone.
新しいDNSKEY：古いデータがキャッシュから期限切れになった後、新しいキーをゾーンに追加できます。
new DS: After the cache data for the old DNSKEY RRset has expired, the DS record for the new key can be added to the parent zone and the DS record for the old key can be removed in the same step.
新しいDS：古いDNSKEY RRsetのキャッシュデータが期限切れになった後、新しいキーのDSレコードを親ゾーンに追加し、古いキーのDSレコードを同じ手順で削除できます。
DNSKEY removal: After the cache data for the old DS RRset has expired, the old algorithm can be removed. This time, the old key needs to be removed first, before removing the old signatures.
DNSKEYの削除：古いDS RRsetのキャッシュデータが期限切れになった後、古いアルゴリズムを削除できます。今回は、古い署名を削除する前に、まず古い鍵を削除する必要があります。
RRSIGs removal: After the cache data for the old DNSKEY RRset has expired, the old signatures can also be removed during this step.
RRSIGの削除：古いDNSKEY RRsetのキャッシュデータの有効期限が切れた後、この手順で古い署名を削除することもできます。
Below, we deal with a few special cases of algorithm rollovers:
以下では、アルゴリズムロールオーバーのいくつかの特殊なケースを扱います。
1: Single-Type Signing Scheme Algorithm rollover: when there is no differentiation between ZSKs and KSKs (Section 4.1.4.1).
1：シングルタイプ署名方式アルゴリズムのロールオーバー：ZSKとKSKの間に違いがない場合（セクション4.1.4.1）。
2: RFC 5011 Algorithm rollover: when trust anchors can track the roll via RFC 5011 style rollover (Section 4.1.4.2).
2：RFC 5011アルゴリズムのロールオーバー：トラストアンカーがRFC 5011スタイルのロールオーバーを介してロールを追跡できる場合（セクション4.1.4.2）。
3: 1 and 2 combined: when a Single-Type Signing Scheme Algorithm rollover is performed RFC 5011 style (Section 4.1.4.3).
3：1と2の組み合わせ：シングルタイプ署名スキームアルゴリズムのロールオーバーがRFC 5011スタイルで実行される場合（セクション4.1.4.3）。
In addition to the narrative below, these special cases are represented in Figures 12, 13, and 14 in Appendix C.
以下の説明に加えて、これらの特殊なケースは、付録Cの図12、13、および14に示されています。
If one key is used that acts as both ZSK and KSK, the same scheme and figure as above (Figure 8 in Section 4.1.4) applies, whereby all DNSKEY_Z_* records from the table are removed and all RRSIG_Z_* are replaced with RRSIG_S_*. All DNSKEY_K_* records are replaced with DNSKEY_S_*, and all RRSIG_K_* records are replaced with RRSIG_S_*. The requirement to sign with both algorithms and make sure that old RRSIGs have the opportunity to expire from distant caches before introducing the new algorithm in the DNSKEY RRset is still valid.
ZSKとKSKの両方として機能する1つのキーが使用される場合、上記と同じスキームと図（セクション4.1.4の図8）が適用され、テーブルからすべてのDNSKEY_Z_ *レコードが削除され、すべてのRRSIG_Z_ *がRRSIG_S_ *に置き換えられます。 。すべてのDNSKEY_K_ *レコードはDNSKEY_S_ *に置き換えられ、すべてのRRSIG_K_ *レコードはRRSIG_S_ *に置き換えられます。両方のアルゴリズムで署名し、DNSKEY RRsetに新しいアルゴリズムを導入する前に、古いRRSIGが離れたキャッシュから期限切れになる機会があることを確認する要件は、まだ有効です。
This is shown in Figure 12 in Appendix C.
これを付録Cの図12に示します。
Trust anchor algorithm rollover is almost as simple as a regular RFC 5011-based rollover. However, the old trust anchor must be revoked before it is removed from the zone.
トラストアンカーアルゴリズムのロールオーバーは、通常のRFC 5011ベースのロールオーバーとほぼ同じくらい簡単です。ただし、古いトラストアンカーは、ゾーンから削除する前に取り消す必要があります。
The timeline (see Figure 13 in Appendix C) is similar to that of Figure 8 above, but after the "new DS" step, an additional step is required where the DNSKEY is revoked. The details of this step ("revoke DNSKEY") are shown in Figure 9 below.
タイムライン（付録Cの図13を参照）は上記の図8のタイムラインに似ていますが、「新しいDS」ステップの後に、DNSKEYが取り消される追加のステップが必要です。このステップの詳細（「DNSKEYを取り消す」）を以下の図9に示します。
---------------------------------
revoke DNSKEY
---------------------------------
Parent:
----------------------------->
----------------------------->
----------------------------->
----------------------------->
Child: SOA_3 RRSIG_Z_10(SOA) RRSIG_Z_11(SOA)
子：SOA_3 RRSIG_Z_10（SOA）RRSIG_Z_11（SOA）
DNSKEY_K_1_REVOKED DNSKEY_K_2
DNSKEY_K_1_REVOKED DNSKEY_K_2
DNSKEY_Z_11
RRSIG_K_1(DNSKEY)
RRSIG_K_2(DNSKEY)
---------------------------------
Figure 9: The Revoke DNSKEY State That Is Added to an Algorithm Rollover when RFC 5011 Is in Use
図9：RFC 5011が使用されている場合にアルゴリズムのロールオーバーに追加されるDNSKEY状態の取り消し
There is one exception to the requirement from RFC 4035 quoted in Section 4.1.4 above: While all zone data must be signed with an unrevoked key, it is permissible to sign the key set with a revoked key. The somewhat esoteric argument is as follows:
上記のセクション4.1.4で引用されているRFC 4035の要件には1つの例外があります。すべてのゾーンデータは取り消しされていない鍵で署名する必要がありますが、取り消した鍵で鍵セットに署名することは許可されます。やや難解な引数は次のとおりです。
Resolvers that do not understand the RFC 5011 REVOKE flag will handle DNSKEY_K_1_REVOKED the same as if it were DNSKEY_K_1. In other words, they will handle the revoked key as a normal key, and thus RRsets signed with this key will validate. As a result, the signature matches the algorithm listed in the DNSKEY RRset.
RFC 5011のREVOKEフラグを理解しないリゾルバは、DNSKEY_K_1と同じようにDNSKEY_K_1_REVOKEDを処理します。つまり、取り消されたキーを通常のキーとして処理するため、このキーで署名されたRRsetは検証されます。その結果、署名はDNSKEY RRsetにリストされているアルゴリズムと一致します。
Resolvers that do implement RFC 5011 will remove DNSKEY_K_1 from the set of trust anchors. That is okay, since they have already added DNSKEY_K_2 as the new trust anchor. Thus, algorithm 2 is the only signaled algorithm by now. That is, we only need RRSIG_K_2(DNSKEY) to authenticate the DNSKEY RRset, and we are still compliant with Section 2.2 of RFC 4035: There must be an RRSIG for each RRset using at least one DNSKEY of each algorithm in the zone apex DNSKEY RRset.
RFC 5011を実装するリゾルバは、トラストアンカーのセットからDNSKEY_K_1を削除します。彼らはすでにDNSKEY_K_2を新しいトラストアンカーとして追加しているため、問題ありません。したがって、現時点では、アルゴリズム2が唯一の通知アルゴリズムです。つまり、DNSKEY RRsetを認証するために必要なのはRRSIG_K_2（DNSKEY）だけであり、RFC 4035のセクション2.2に引き続き準拠しています。ゾーン頂点DNSKEY RRsetの各アルゴリズムの少なくとも1つのDNSKEYを使用して、各RRsetにRRSIGが必要です。 。
If a decision is made to perform an RFC 5011 style rollover with a Single Signing Scheme key, it should be noted that Section 2.1 of RFC 5011 states:
シングル署名スキームキーを使用してRFC 5011スタイルのロールオーバーを実行することが決定された場合、RFC 5011のセクション2.1に次のように記載されていることに注意してください。
Once the resolver sees the REVOKE bit, it MUST NOT use this key as a trust anchor or for any other purpose except to validate the RRSIG it signed over the DNSKEY RRset specifically for the purpose of validating the revocation.
リゾルバーがREVOKEビットを確認すると、このキーをトラストアンカーとして、または特に取り消しを検証する目的でDNSKEY RRsetを介して署名したRRSIGを検証する以外の目的で使用してはなりません（MUST NOT）。
This means that once DNSKEY_S_1 is revoked, it cannot be used to validate its signatures over non-DNSKEY RRsets. Thus, those RRsets should be signed with a shadow key, DNSKEY_Z_10, during the algorithm rollover. The shadow key can be removed at the same time the revoked DNSKEY_S_1 is removed from the zone. In other words, the zone must temporarily fall back to a KSK/ZSK split model during the rollover.
つまり、DNSKEY_S_1が取り消されると、DNSKEY以外のRRsetを介してその署名を検証するために使用できなくなります。したがって、これらのRRsetは、アルゴリズムのロールオーバー中にシャドウキーDNSKEY_Z_10で署名する必要があります。シャドウキーは、取り消されたDNSKEY_S_1がゾーンから削除されると同時に削除できます。つまり、ロールオーバー中、ゾーンは一時的にKSK / ZSK分割モデルにフォールバックする必要があります。
In other words, the rule that at every RRset there must be at least one signature for each algorithm used in the DNSKEY RRset still applies. This means that a different key with the same algorithm, other than the revoked key, must sign the entire zone. Thus, more operations are needed if the Single-Type Signing Scheme is used. Before rolling the algorithm, a new key must be introduced with the same algorithm as the key that is a candidate for revocation. That key can than temporarily act as a ZSK during the algorithm rollover.
つまり、すべてのRRsetで、DNSKEY RRsetで使用される各アルゴリズムに対して少なくとも1つの署名が必要であるというルールが引き続き適用されます。これは、取り消された鍵以外の、同じアルゴリズムを持つ別の鍵がゾーン全体に署名する必要があることを意味します。したがって、Single-Type Signing Schemeが使用されている場合、より多くの操作が必要です。アルゴリズムをローリングする前に、失効の候補となるキーと同じアルゴリズムで新しいキーを導入する必要があります。そのキーは、アルゴリズムのロールオーバー中に一時的にZSKとして機能できます。
As with algorithm rollover RFC 5011 style, while all zone data must be signed with an unrevoked key, it is permissible to sign the key set with a revoked key using the same esoteric argument given in Section 4.1.4.2.
アルゴリズムロールオーバーRFC 5011スタイルと同様に、すべてのゾーンデータは取り消しされていない鍵で署名する必要がありますが、セクション4.1.4.2で指定された同じ難解な引数を使用して、取り消した鍵で鍵セットに署名することは許可されます。
The lesson of all of this is that a Single-Type Signing Scheme algorithm rollover using RFC 5011 is as complicated as the name of the rollover implies: Reverting to a split-key scheme for the duration of the rollover may be preferable.
このすべての教訓は、RFC 5011を使用したシングルタイプ署名スキームアルゴリズムのロールオーバーは、ロールオーバーの名前が示すように複雑であることです。ロールオーバーの期間は分割キースキームに戻すことをお勧めします。
A special case is the rollover from an NSEC signed zone to an NSEC3 signed zone. In this case, algorithm numbers are used to signal support for NSEC3 but they do not mandate the use of NSEC3. Therefore, NSEC records should remain in the zone until the rollover to a new algorithm has completed and the new DNSKEY RRset has populated distant caches, at the end of the "new DNSKEY" stage. At that point, the validators that have not implemented NSEC3 will treat the zone as unsecured as soon as they follow the chain of trust to the DS that points to a DNSKEY of the new algorithm, while validators that support NSEC3 will happily validate using NSEC. Turning on NSEC3 can then be done during the "new DS" step: increasing the serial number, introducing the NSEC3PARAM record to signal that NSEC3-authenticated data related to denial of existence should be served, and re-signing the zone.
特殊なケースは、NSEC署名済みゾーンからNSEC3署名済みゾーンへのロールオーバーです。この場合、アルゴリズム番号はNSEC3のサポートを示すために使用されますが、NSEC3の使用を義務付けていません。したがって、NSECレコードは、新しいアルゴリズムへのロールオーバーが完了し、新しいDNSKEY RRsetが "新しいDNSKEY"ステージの最後で遠方のキャッシュに読み込まれるまで、ゾーンに留まる必要があります。その時点で、NSEC3を実装していないバリデーターは、新しいアルゴリズムのDNSKEYを指すDSへの信頼チェーンに従うとすぐにゾーンを非セキュアとして扱いますが、NSEC3をサポートするバリデーターはNSECを使用して喜んで検証します。次に、「新しいDS」の手順でNSEC3をオンにすることができます。シリアル番号を増やし、NSEC3PARAMレコードを導入して、存在の拒否に関連するNSEC3認証データを提供する必要があることを通知し、ゾーンに再署名します。
In summary, an NSEC-to-NSEC3 rollover is an ordinary algorithm rollover whereby NSEC is used all the time and only after that rollover finished NSEC3 needs to be deployed. The procedures are also listed in Sections 10.4 and 10.5 of RFC 5155 [RFC5155].
要約すると、NSECからNSEC3へのロールオーバーは通常のアルゴリズムのロールオーバーであり、NSECは常に使用され、そのロールオーバーが終了した後でのみNSEC3を展開する必要があります。手順は、RFC 5155 [RFC5155]のセクション10.4および10.5にもリストされています。
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 the 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. It is advisable to have a documented procedure ready for those times when a key compromise is suspected or confirmed.
このセクションでは、起こりうる鍵の侵害の準備について扱います。鍵の侵害が疑われるか確認されるときのために、文書化された手順を用意しておくことをお勧めします。
When the private material of one of a zone's keys is compromised, it can be used by an attacker for as long as a valid trust chain exists. A trust chain remains intact for
ゾーンのキーの1つの秘密情報が危険にさらされた場合、有効な信頼チェーンが存在する限り、攻撃者はそれを使用できます。信頼チェーンはそのまま残ります
o as long as a signature over the compromised key in the trust chain is valid, and
o 信頼チェーンの侵害されたキーに対する署名が有効である限り、かつ
o as long as the DS RR in the parent zone points to the (compromised) key signing the DNSKEY RRset, and
o 親ゾーンのDS RRがDNSKEY RRsetに署名する（危険にさらされた）キーを指している限り、かつ
o as long as the (compromised) 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 a zone's compromised key exists, your namespace is vulnerable to abuse by anyone who has obtained illegitimate possession of the key. Zone administrators have to make a decision as to whether the abuse of the compromised key is worse than having data in caches that cannot be validated. If the zone administrator 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, during the rollover the malicious key holder can continue to spoof data so that it appears to be valid.
ゾーンの危険にさらされたキーへの信頼チェーンが存在する一方で、ネームスペースは、キーの不正な所持を取得した者による悪用に対して脆弱です。ゾーン管理者は、侵害されたキーの悪用が、検証できないキャッシュ内のデータを持つよりも悪いかどうかについて決定を下す必要があります。ゾーン管理者が信頼チェーンを侵害されたキーに分割することを選択した場合、このキーで署名されたキャッシュ内のデータは検証できません。ただし、ゾーン管理者が通常のロールオーバーのパスを選択した場合、ロールオーバー中に悪意のあるキーホルダーがデータを偽装し続け、データが有効であるように見せることができます。
A compromised KSK can be used to sign the key set of an attacker's version of the zone. That zone could be used to poison the DNS.
侵害されたKSKを使用して、攻撃者のバージョンのゾーンのキーセットに署名できます。そのゾーンはDNSを汚染するために使用できます。
A zone containing a DNSKEY RRset with a compromised KSK is vulnerable as long as the compromised KSK is configured as the trust anchor or a DS record in the parent zone points to it.
侵害されたKSKが含まれるDNSKEY RRsetを含むゾーンは、侵害されたKSKがトラストアンカーとして構成されているか、親ゾーンのDSレコードがそれを指している場合に脆弱です。
Therefore, when the KSK has been compromised, the trust anchor or the parent DS record 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 record pointing to the compromised KSK. The assumption is that there is only one DS record at the parent. If there are multiple DS records, this does not apply, although the chain of trust of this particular key is broken.
したがって、KSKが侵害された場合は、トラストアンカーまたは親DSレコードをできるだけ早く交換する必要があります。緊急ロールオーバー中に信頼チェーンを解除するかどうかは、ローカルポリシーです。信頼されたチェーンは、侵害されたKSKが子のゾーンから削除されたときに、親が侵害されたKSKを指すDSレコードをまだ持っている場合に壊れます。前提条件は、親にDSレコードが1つしかないことです。複数のDSレコードがある場合、これは当てはまりませんが、この特定のキーの信頼チェーンは壊れています。
Note that an attacker's version of the zone still uses the compromised KSK, and the presence of the corresponding DS record in the parent would cause the data in this zone to appear as valid. Removing the compromised key would cause the attacker's version of the zone to appear as valid and the original zone as Bogus. Therefore, we advise administrators not to remove the KSK before the parent has a DS record for the new KSK in place.
攻撃者のバージョンのゾーンは引き続き侵害されたKSKを使用し、親に対応するDSレコードが存在すると、このゾーンのデータが有効であるように見えることに注意してください。侵害されたキーを削除すると、攻撃者のゾーンのバージョンは有効で、元のゾーンは偽として表示されます。したがって、管理者は、親が新しいKSKのDSレコードを設定する前にKSKを削除しないことをお勧めします。
If it is desired to perform an emergency key rollover in a manner that keeps the chain of trust intact, 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. This means ensuring that the signature made with a new KSK over the key set that contains the compromised KSK expires just after the new DS appears at the parent. Expiration of that signature will cause expiration of that key set from the caches.
信頼の連鎖を維持する方法で緊急鍵のロールオーバーを実行することが望まれる場合、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. Lower the TTL for DNSKEYs so that the DNSKEY RRset will expire from caches sooner.
1. 新しいKSKをキーセットに導入します。侵害されたKSKをキーセットに保持します。 DNSKEYのTTLを下げて、DNSKEY RRsetがキャッシュからより早く期限切れになるようにします。
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 DSs have expired from caches. This provides an upper limit on how long the compromised KSK can be used in a replay attack.
2. 有効期間が短い鍵セットに署名します。有効期間は、DSが親に表示され、古いDSがキャッシュから期限切れになった直後に期限切れになるはずです。これにより、侵害されたKSKをリプレイ攻撃で使用できる期間の上限が決まります。
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 at 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 RRのTTLが出るまで待ちます。必要に応じて、DNSKEY RRsetに再署名し、有効期限を変更または延長します。
5. Remove the compromised DNSKEY RR from the zone, and re-sign the key set using your "normal" TTL and signature validity period.
5. 侵害されたDNSKEY RRをゾーンから削除し、「通常の」TTLと署名の有効期間を使用してキーセットに再署名します。
An additional danger of a key compromise is that the compromised key could be used to facilitate a legitimate-looking DNSKEY/DS rollover and/or name server 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 to authenticate communication with the parent.
これは、DNSKEYまたはDSレコード、あるいはその両方が親との通信の認証に使用されている場合にのみ問題になることに注意してください。
There are two methods to perform an emergency key rollover in a manner that breaks 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つ目の方法では、子ゾーンが偽のリゾルバを認識しているように見えます。もう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. Note that until that time, the child zone is still vulnerable to spoofing: The attacker is still in possession of the compromised key that the DS points to.
子ゾーンがリゾルバーを検証するために偽に見えるようにする方法では、子ゾーンは現在のKSKを新しいものに置き換え、キーセットに再署名します。次に、新しいキーのDSを親に送信します。親がゾーンに新しい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. After the DS has expired from distant caches, the keys and signatures are removed from the child zone, new keys and signatures are introduced, and finally, a new DS is submitted to the parent.
信頼の連鎖を断ち切る別の方法は、親ゾーンからDS RRを完全に削除することです。その結果、子ゾーンは安全ではなくなります。 DSが離れたキャッシュから期限切れになると、キーと署名が子ゾーンから削除され、新しいキーと署名が導入され、最後に新しいDSが親に送信されます。
Primarily because there is no interaction with the parent 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 until the RRSIG over the compromised ZSK has expired, the zone may still be at risk.
主に、ZSKが侵害された場合に必要な親との対話がないため、状況はKSKの侵害よりも深刻ではありません。それでも、ゾーンはできるだけ早く新しいZSKで再署名する必要があります。これはローカル操作であり、親子間の通信を必要としないため、これはかなり迅速に達成できます。ただし、通常のロールオーバーの場合と同様に、古い侵害されたキーがすぐに消失すると、検証の問題が発生する可能性があることを考慮する必要があります。また、侵害されたZSKに対するRRSIGが期限切れになるまで、ゾーンは依然として危険にさらされている可能性があることに注意してください。
A key can also be pre-configured in resolvers as a trust anchor. If trust anchor keys are compromised, the administrators of 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 by some means, e.g., by using digital signatures.
キーは、リゾルバーでトラストアンカーとして事前に構成することもできます。トラストアンカーキーが侵害された場合、これらのキーを使用するリゾルバーの管理者にこの事実を通知する必要があります。ゾーン管理者は、SEPキーがロールオーバーされようとしているという事実を伝えるためにメーリングリストを設定することを検討できます。もちろん、この通信は、デジタル署名を使用するなど、何らかの方法で認証する必要があります。
End-users faced with the task of updating an anchored key should always verify the new key. New keys should be authenticated out-of-band, for example, through the use of an announcement website that is secured using Transport Layer Security (TLS) [RFC5246].
アンカーキーを更新するタスクに直面しているエンドユーザーは、常に新しいキーを確認する必要があります。たとえば、トランスポート層セキュリティ（TLS）[RFC5246]を使用して保護されたアナウンスWebサイトを使用して、新しいキーを帯域外で認証する必要があります。
Stand-by keys are keys that are published in your zone but are not used to sign RRsets. There are two reasons why someone would want to use stand-by keys. One is to speed up the emergency key rollover. The other is to recover from a disaster that leaves your production private keys inaccessible.
スタンバイキーは、ゾーンで公開されているが、RRsetの署名には使用されないキーです。誰かがスタンバイキーを使用する理由は2つあります。 1つは、緊急キーのロールオーバーを高速化することです。もう1つは、プロダクション秘密キーにアクセスできなくなった災害から回復することです。
The way to deal with stand-by keys differs for ZSKs and KSKs. To make a stand-by ZSK, you need to publish its DNSKEY RR. To make a stand-by KSK, you need to get its DS RR published at the parent.
スタンバイキーの処理方法は、ZSKとKSKで異なります。スタンバイZSKを作成するには、そのDNSKEY RRを公開する必要があります。スタンバイKSKを作成するには、そのDS RRを親で公開する必要があります。
Assuming you have your normal DNS operation, to prepare stand-by keys you need to:
通常のDNS操作があると想定して、スタンバイキーを準備するには、次のことを行う必要があります。
o Generate a stand-by ZSK and KSK. Store them safely in a location different than the place where the currently used ZSK and KSK are held.
o スタンバイZSKおよびKSKを生成します。現在使用しているZSK、KSKとは別の場所に安全に保管してください。
o Pre-publish the DNSKEY RR of the stand-by ZSK in the zone.
o ゾーン内のスタンバイZSKのDNSKEY RRを事前公開します。
o Pre-publish the DS of the stand-by KSK in the parent zone.
o 親ゾーンでスタンバイKSKのDSを事前公開します。
Now suppose a disaster occurs and disables access to the currently used keys. To recover from that situation, follow these procedures:
次に、災害が発生し、現在使用されているキーへのアクセスが無効になったとします。この状況から回復するには、次の手順に従います。
o Set up your DNS operations and introduce the stand-by KSK into the zone.
o DNSオペレーションをセットアップし、スタンバイKSKをゾーンに導入します。
o Post-publish the disabled ZSK and sign the zone with the stand-by keys.
o 無効化されたZSKをポストパブリッシュし、スタンバイキーを使用してゾーンに署名します。
o After some time, when the new signatures have been propagated, the old keys, old signatures, and the old DS can be removed.
o しばらくして、新しい署名が伝達されたら、古いキー、古い署名、古いDSを削除できます。
o Generate a new stand-by key set at a different location and continue "normal" operation.
o 別の場所に新しいスタンバイキーセットを生成し、「通常の」操作を続行します。
The initial key exchange is always subject to the policies set by the parent. It is specifically important in a registry-registrar-registrant model where a registry maintains the parent zone, and the registrant (the user of the child-domain name) deals with the registry through an intermediary called a registrar (see [RFC3375] for a comprehensive definition). The key material is to be passed from the DNS operator to the parent via a registrar, where both the DNS operator and registrar are selected by the registrant and might be different organizations. 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 the parent and child. That is, there is no implicit need in DNSSEC to make the authentication process stronger than it is for regular DNS.
最初の鍵交換は、常に親によって設定されたポリシーに従います。レジストリが親ゾーンを維持し、登録者（子ドメイン名のユーザー）がレジストラと呼ばれる仲介者（[RFC3375]を参照）を介してレジストリを処理するRegistry-registrar-registrantモデルでは特に重要です。包括的な定義）。キーマテリアルは、DNSオペレーターからレジストラーを介して親に渡されます。DNSオペレーターとレジストラーの両方が登録者によって選択され、組織が異なる場合があります。鍵交換ポリシーを設計するときは、鍵交換中に使用される認証および承認メカニズムが、親子間の委任情報の交換に使用される認証および承認メカニズムと同じくらい強力でなければならないことを考慮する必要があります。つまり、認証プロセスを通常のDNSの場合よりも強力にするためにDNSSECに暗黙の必要はありません。
Using the DNS itself as the source for the actual DNSKEY material has the benefit that it reduces the chances of user error. A DNSKEY query tool can make use of the SEP bit [RFC4035] to select the proper key(s) 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 that the child is secure.
実際のDNSKEYマテリアルのソースとしてDNS自体を使用すると、ユーザーエラーの可能性を減らすという利点があります。 DNSKEYクエリツールは、SEPビット[RFC4035]を使用してDNSSECキーセットから適切なキーを選択できるため、間違ったDNSKEYが送信される可能性が低くなります。鍵を介して自己署名を検証し、秘密鍵素材の所有権を検証できます。 DNSからDNSKEYをフェッチすると、親がDS RRを公開して子が安全であることを示すと、信頼の連鎖がそのまま維持されます。
Note: Out-of-band verification is still needed when the key material is fetched for the first time, even via DNS. The parent can never be sure whether or not the DNSKEY RRs have been spoofed.
注：DNSを介した場合でも、キーマテリアルが初めてフェッチされるときには、帯域外検証が引き続き必要です。親は、DNSKEY RRが偽装されているかどうかを確認することはできません。
With some types of key rollovers, the DNSKEY is not pre-published, and a DNSKEY query tool is not able to retrieve the successor key. In this case, the out-of-band method is required. This also allows the child to determine the digest algorithm of the DS record.
一部の種類のキーロールオーバーでは、DNSKEYは事前に公開されておらず、DNSKEYクエリツールは後続キーを取得できません。この場合、アウトオブバンド方式が必要です。これにより、子はDSレコードのダイジェストアルゴリズムを決定することもできます。
When designing a registry system, one should consider whether to store the DNSKEYs and/or the corresponding DSs. 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 suggest that registry systems should be able to store DS RRs, even if they also store DNSKEYs (see also "DNSSEC Trust Anchor Configuration and Maintenance" [DNSSEC-TRUST-ANCHOR]).
レジストリシステムを設計するときは、DNSKEYや対応するDSを保存するかどうかを検討する必要があります。子ゾーンは、レジストリでまだ理解されていないメッセージダイジェストアルゴリズムを使用してDSを公開したい場合があるため、レジストリは、生のDNSKEYからDSレコードを生成できるとは限りません。したがって、レジストリキーがDNSKEYも格納している場合でも、レジストリシステムはDS RRを格納できる必要があることをお勧めします（「DNSSECトラストアンカーの構成とメンテナンス」[DNSSEC-TRUST-ANCHOR]も参照）。
The storage considerations also relate to the design of the customer interface and the method by which data is transferred between the 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? When registries support the Extensible Provisioning Protocol (EPP) [RFC5910], that can be used for registrar-registry interactions, since that protocol allows the transfer of both DS and, optionally, DNSKEY RRs. There is no standardized way to move the data between the customer and the registrar. Different registrars have different mechanisms, ranging from simple web interfaces to various APIs. In some cases, the use of the DNSSEC extensions to EPP may be applicable.
記憶域に関する考慮事項は、顧客インターフェイスの設計と、登録者とレジストリの間でデータを転送する方法にも関係します。子ゾーン管理者は、不明なハッシュアルゴリズムでDS RRをアップロードできますか、またはインターフェイスでDNSKEYのみが許可されますか？レジストリがExtensible Provisioning Protocol（EPP）[RFC5910]をサポートしている場合、そのプロトコルはDSとオプションでDNSKEY RRの両方の転送を許可するため、レジストラとレジストリの相互作用に使用できます。顧客とレジストラの間でデータを移動する標準化された方法はありません。レジストラごとに、シンプルなWebインターフェースからさまざまなAPIまで、さまざまなメカニズムがあります。場合によっては、EPPへのDNSSEC拡張の使用が適用される場合があります。
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.
レジストリディレクトリ（Whoisなど）などの帯域外メカニズムを使用して、特定の所有者やゾーンのDSリソースレコードを生成するために使用されているキーを見つけることも、トラブルシューティングに役立つ場合があります。
Security lameness is defined as the state whereby the parent has a DS RR pointing to a nonexistent DNSKEY RR. Security lameness may occur temporarily during a Double-DS rollover scheme. However, care should be taken that not all DS RRs are pointing to a nonexistent DNSKEY RR, which will cause the child's zone to be marked Bogus by verifying DNS clients.
セキュリティの不満は、親が存在しないDNSKEY RRを指すDS RRを持つ状態として定義されます。 Double-DSロールオーバースキームの実行中に、セキュリティの問題が一時的に発生する場合があります。ただし、すべてのDS RRが存在しないDNSKEY 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 the 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.
子ゾーンは、DS RRが存在するDNSKEYマテリアル（具体的には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 for the DS RRSIG minimizes the time that 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 the case of a configuration error in the signer. There may not be enough time to fix the problems before signatures expire (this is a generic argument; also see Section 4.4.2). Something as mundane as zone administrator unavailability during weekends shows the need for DS signature validity periods longer than two days. Just like any signature validity period, we suggest an absolute minimum for the DS signature validity period of a few days.
DSは有効な署名がある限り再生できるため、DS RRSIGの署名の有効期間を短くすると、子のKSKが侵害された場合に子が脆弱になる時間を最小限に抑えることができます。署名の有効期間が短すぎると、署名者の構成エラーが発生した場合にゾーンに偽のマークが付けられる可能性があります。シグネチャが期限切れになる前に問題を修正するのに十分な時間がない場合があります（これは一般的な引数です。セクション4.4.2も参照してください）。週末にゾーン管理者が利用できないのと同じくらい平凡なものは、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 period increases the operational risk for the parent. Therefore, the parent may have a policy to use a signature validity period that is considerably longer than the child would hope for.
DSレコードの最大署名有効期間は、キーの侵害後、子ゾーンが脆弱であることが許容される期間に依存します。一方、DS署名の有効期間を短くすると、親の運用リスクが増加します。したがって、親が署名の有効期間を使用するポリシーを持っている可能性があり、それは子供が期待するよりもかなり長いです。
A compromise between the policy/operational constraints of the parent and minimizing damage for the child may result in a DS signature validity period somewhere between a week and several months.
親のポリシー/運用上の制約と子供への被害を最小限に抑えることの妥協により、DS署名の有効期間が1週間から数か月になる場合があります。
In addition to the signature validity period, which sets a lower bound on the number of times the zone administrator will need to sign the zone data and an upper bound on the time that a child is vulnerable after key compromise, there is the TTL value on the DS RRs. Shortening the TTL reduces the damage of a successful replay attack. It does mean 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 RR。 TTLを短くすると、リプレイ攻撃が成功した場合のダメージが軽減されます。これは、権限のあるサーバーがより多くのクエリを参照することを意味します。しかしその一方で、短いTTLはキャッシュ内のDS RRsetの永続性を低下させ、それによって更新されたDS RRsetがDNSを介して伝播する速度を向上させます。
The parent-child relationship is often described in terms of a registry-registrar-registrant model, where a registry maintains the parent zone and the registrant (the user of the child-domain name) deals with the registry through an intermediary called a registrar [RFC3375]. Registrants may outsource the maintenance of their DNS system, including the maintenance of DNSSEC key material, to the registrar or to another third party, referred to here as the DNS operator.
多くの場合、親子関係はレジストリ-レジストラ-登録者モデルの観点から説明されます。この場合、レジストリは親ゾーンを維持し、登録者（子ドメイン名のユーザー）はレジストラと呼ばれる仲介者を通じてレジストリを処理します[ RFC3375]。登録者は、DNSSECキーマテリアルのメンテナンスを含む、DNSシステムのメンテナンスを、レジストラまたはここではDNSオペレーターと呼ばれる別の第三者に外部委託することができます。
For various reasons, a registrant may want to move between DNS operators. How easy this move will be depends principally on the DNS operator from which the registrant is moving (the losing operator), as the losing operator has control over the DNS zone and its keys. The following sections describe the two cases: where the losing operator cooperates with the new operator (the gaining operator), and where the two do not cooperate.
さまざまな理由により、登録者はDNSオペレーター間を移動したい場合があります。この移動がどれほど簡単になるかは、主に、登録者の移動元のDNSオペレーター（紛失したオペレーター）に依存します。これは、紛失したオペレーターがDNSゾーンとそのキーを制御できるためです。次のセクションでは、2つのケースについて説明します。敗者のオペレーターが新しいオペレーター（獲得オペレーター）と協力する場合と、2つが協力しない場合です。
In this scenario, it is assumed that the losing operator will not pass any private key material to the gaining operator (that would constitute a trivial case) but is otherwise fully cooperative.
このシナリオでは、負けた事業者は秘密の鍵素材を取得した事業者に渡さない（それは些細な場合を構成します）が、それ以外は完全に協力的であると想定されます。
In this environment, the change could be made with a Pre-Publish ZSK rollover, whereby the losing operator pre-publishes the ZSK of the gaining operator, combined with a Double-Signature KSK rollover where the two registrars exchange public keys and independently generate a signature over those key sets that they combine and both publish in their copy of the zone. Once that is done, they can use their own private keys to sign any of their zone content during the transfer.
この環境では、事前発行ZSKロールオーバーを使用して変更を行うことができます。これにより、敗者は獲得オペレーターのZSKを事前発行し、2つのレジストラが公開鍵を交換して個別に生成する二重署名KSKロールオーバーと組み合わせます。それらが結合し、両方がゾーンのコピーで公開する鍵セットに対する署名。これが完了すると、転送中に独自の秘密鍵を使用して、ゾーンのコンテンツに署名できます。
------------------------------------------------------------
initial | pre-publish |
------------------------------------------------------------
Parent:
NS_A NS_A
DS_A DS_A
------------------------------------------------------------
Child at A: Child at A: Child at B:
SOA_A0 SOA_A1 SOA_B0
RRSIG_Z_A(SOA) RRSIG_Z_A(SOA) RRSIG_Z_B(SOA)
NS_A NS_A NS_B RRSIG_Z_A(NS) NS_B RRSIG_Z_B(NS) RRSIG_Z_A(NS)
NS_A NS_A NS_B RRSIG_Z_A（NS）NS_B RRSIG_Z_B（NS）RRSIG_Z_A（NS）
DNSKEY_Z_A DNSKEY_Z_A DNSKEY_Z_A
DNSKEY_Z_B DNSKEY_Z_B
DNSKEY_K_A DNSKEY_K_A DNSKEY_K_A
DNSKEY_K_B DNSKEY_K_B
RRSIG_K_A(DNSKEY) RRSIG_K_A(DNSKEY) RRSIG_K_A(DNSKEY)
RRSIG_K_B(DNSKEY) RRSIG_K_B(DNSKEY)
------------------------------------------------------------
------------------------------------------------------------
re-delegation | post-migration |
------------------------------------------------------------
Parent:
NS_B NS_B
DS_B DS_B
------------------------------------------------------------
Child at A: Child at B: Child at B:
SOA_A1 SOA_B0 SOA_B1 RRSIG_Z_A(SOA) RRSIG_Z_B(SOA) RRSIG_Z_B(SOA)
SOA_A1 SOA_B0 SOA_B1 RRSIG_Z_A（SOA）RRSIG_Z_B（SOA）RRSIG_Z_B（SOA）
NS_A NS_B NS_B NS_B RRSIG_Z_B(NS) RRSIG_Z_B(NS) RRSIG_Z_A(NS)
NS_A NS_B NS_B NS_B RRSIG_Z_B（NS）RRSIG_Z_B（NS）RRSIG_Z_A（NS）
DNSKEY_Z_A DNSKEY_Z_A
DNSKEY_Z_B DNSKEY_Z_B DNSKEY_Z_B
DNSKEY_K_A DNSKEY_K_A
DNSKEY_K_B DNSKEY_K_B DNSKEY_K_B
RRSIG_K_A(DNSKEY) RRSIG_K_A(DNSKEY)
RRSIG_K_B(DNSKEY) RRSIG_K_B(DNSKEY) RRSIG_K_B(DNSKEY)
------------------------------------------------------------
Figure 10: Rollover for Cooperating Operators
図10：協力するオペレーターのロールオーバー
In this figure, A denotes the losing operator and B the gaining operator. RRSIG_Z is the RRSIG produced by a ZSK, RRSIG_K is produced with a KSK, and the appended A or B indicates the producers of the key pair. "Child at A" is how the zone content is represented by the losing DNS operator, and "Child at B" is how the zone content is represented by the gaining DNS operator.
この図では、Aは負け演算子、Bは負け演算子を示します。 RRSIG_ZはZSKによって生成されたRRSIGであり、RRSIG_KはKSKを使用して生成され、追加されたAまたはBは鍵ペアのプロデューサーを示します。 「Aの子」は、負けたDNSオペレーターがゾーンのコンテンツを表す方法であり、「Bの子」は、負けたDNSオペレーターがゾーンのコンテンツを表す方法です。
The zone is initially delegated from the parent to the name servers of operator A. Operator A uses his own ZSK and KSK to sign the zone. The cooperating operator A will pre-publish the new NS record and the ZSK and KSK of operator B, including the RRSIG over the DNSKEY RRset generated by the KSK of operator B. Operator B needs to publish the same DNSKEY RRset. When that DNSKEY RRset has populated the caches, the re-delegation can be made, which involves adjusting the NS and DS records in the parent zone to point to operator B. And after all DNSSEC records related to operator A have expired from the caches, operator B can stop publishing the keys and signatures belonging to operator A, and vice versa.
ゾーンは、最初は親からオペレーターAのネームサーバーに委任されています。オペレーターAは自分のZSKおよびKSKを使用してゾーンに署名します。協力するオペレーターAは、オペレーターBのKSKによって生成されたDNSKEY RRset上のRRSIGを含む、オペレーターBの新しいNSレコードとZSKおよびKSKを事前公開します。オペレーターBは、同じDNSKEY RRsetを公開する必要があります。そのDNSKEY RRsetがキャッシュにデータを入力したら、再委任を行うことができます。これには、親ゾーンのNSおよびDSレコードを調整してオペレーターBを指すようにします。そして、オペレーターAに関連するすべてのDNSSECレコードがキャッシュから期限切れになった後、オペレーターBは、オペレーターAに属する鍵と署名の公開を停止でき、その逆も可能です。
The requirement to exchange signatures has a couple of drawbacks. It requires more operational overhead, because not only do the operators have to exchange public keys but they also have to exchange the signatures of the new DNSKEY RRset. This drawback does not exist if the Double-Signature KSK rollover is replaced with a Double-DS KSK rollover. See Figure 15 in Appendix D for the diagram.
署名を交換する要件には、いくつかの欠点があります。オペレーターは公開鍵を交換する必要があるだけでなく、新しいDNSKEY RRsetの署名も交換する必要があるため、より多くの運用オーバーヘッドが必要になります。 Double-Signature KSKロールオーバーがDouble-DS KSKロールオーバーに置き換えられた場合、この欠点は存在しません。図については、付録Dの図15を参照してください。
Thus, if the registry and registrars allow DS records to be published that do not point to a published DNSKEY in the child zone, the Double-DS KSK rollover is preferred (see Figure 5), in combination with the Pre-Publish ZSK rollover. This does not require sharing the KSK signatures between the operators, but both operators still have to publish each other's ZSKs.
したがって、レジストリとレジストラが、子ゾーンで公開されたDNSKEYを指さないDSレコードの公開を許可する場合、事前公開ZSKロールオーバーと組み合わせて、Double-DS KSKロールオーバーが推奨されます（図5を参照）。これには、オペレーター間でKSK署名を共有する必要はありませんが、両方のオペレーターは、互いのZSKを公開する必要があります。
In the non-cooperating case, matters are more complicated. The losing operator may not cooperate and leave the data in the DNS as is. In extreme cases, the losing operator may become obstructive and publish a DNSKEY RR with a high TTL and corresponding signature validity period so that registrar A's DNSKEY could end up in caches for (in theory at least) decades.
協力しない場合、問題はより複雑になります。敗者は協力せず、データをそのままDNSに残します。極端なケースでは、負けたオペレーターが邪魔になり、TTLが高く、署名の有効期間が対応するDNSKEY RRを公開して、レジストラAのDNSKEYが（理論的には）数十年間キャッシュに残る可能性があります。
The problem arises when a validator tries to validate with the losing operator's key and there is no signature material produced with the losing operator available in the delegation path after re-delegation from the losing operator to the gaining operator has taken place. One could imagine a rollover scenario where the gaining operator takes a copy of all RRSIGs created by the losing operator and publishes those in conjunction with its own signatures, but that would not allow any changes in the zone content. Since a re-delegation took place, the NS RRset has by definition changed, so such a rollover scenario will not work. Besides, if zone transfers are not allowed by the losing operator and NSEC3 is deployed in the losing operator's zone, then the gaining operator's zone will not have certainty that all of the losing operator's RRSIGs have been copied.
この問題は、バリデーターが敗者のオペレーターの鍵で検証を試み、敗者から取得者への再委任が行われた後、委任パスで利用可能な失ったオペレーターで生成された署名マテリアルがない場合に発生します。獲得側のオペレーターが、敗北側のオペレーターが作成したすべてのRRSIGのコピーを取り、それを独自の署名と組み合わせて公開するロールオーバーシナリオを想像できますが、ゾーンの内容を変更することはできません。再委任が行われたため、NS RRsetは定義により変更されているため、このようなロールオーバーシナリオは機能しません。さらに、負けたオペレーターによってゾーン転送が許可されておらず、NSEC3が負けたオペレーターのゾーンに配置されている場合、負けたオペレーターのゾーンは、負けたオペレーターのすべてのRRSIGがコピーされていることを確信できません。
The only viable operation for the registrant is to have his zone go Insecure for the duration of the change. The registry should be asked to remove the DS RR pointing to the losing operator's DNSKEY and to change the NS RRset to point to the gaining operator. Once this has propagated through the DNS, the registry should be asked to insert the DS record pointing to the (newly signed) zone at operator B.
登録者にとって実行可能な唯一の操作は、変更の期間中、ゾーンを安全でない状態にすることです。レジストリは、負けたオペレーターのDNSKEYを指しているDS RRを削除し、NS RRsetを取り戻しているオペレーターを指すように変更するように要求される必要があります。これがDNSを介して伝播したら、オペレーターBの（新しく署名された）ゾーンを指すDSレコードを挿入するようにレジストリに要求する必要があります。
Note that some behaviors of resolver implementations may aid in the process of changing DNS operators:
リゾルバー実装の一部の動作は、DNSオペレーターの変更プロセスに役立つ場合があることに注意してください。
o TTL sanity checking, as described in RFC 2308 [RFC2308], will limit the impact of the actions of an obstructive losing operator. Resolvers that implement TTL sanity checking will use an upper limit for TTLs on RRsets in responses.
o RFC 2308 [RFC2308]で説明されているように、TTLの健全性チェックは、邪魔な敗者の行動の影響を制限します。 TTL健全性チェックを実装するリゾルバーは、応答でRRsetのTTLに上限を使用します。
o If RRsets at the zone cut (are about to) expire, the resolver restarts its search above the zone cut. Otherwise, the resolver risks continuing to use a name server that might be un-delegated by the parent.
o ゾーンカットのRRsetが期限切れになる（間もなく）場合、リゾルバーはゾーンカットの上で検索を再開します。それ以外の場合、リゾルバは、親によって委任されていない可能性があるネームサーバーを引き続き使用するリスクがあります。
o Limiting the time that DNSKEYs that seem to be unable to validate signatures are cached and/or trying to recover from cases where DNSKEYs do not seem to be able to validate data also reduce the effects of the problem of non-cooperating registrars.
o 署名を検証できないと思われるDNSKEYがキャッシュされる時間を制限したり、DNSKEYがデータを検証できないように見える場合から回復したりすることで、非協力的なレジストラの問題の影響も軽減されます。
However, there is no operational methodology to work around this business issue, and proper contractual relationships between all involved parties seem to be the only solution to cope with these problems. It should be noted that in many cases, the problem with temporary broken delegations already exists when a zone changes from one DNS operator to another. Besides, it is often the case that when operators are changed, the services that are referenced by that zone also change operators, possibly involving some downtime.
ただし、このビジネス上の問題を回避する運用方法論はなく、関係するすべての関係者間の適切な契約関係が、これらの問題に対処するための唯一の解決策のようです。多くの場合、ゾーンがあるDNSオペレーターから別のDNSオペレーターに変更されたときに、一時的に壊れた委任に関する問題が既に存在していることに注意してください。さらに、オペレーターが変更されると、そのゾーンによって参照されるサービスもオペレーターを変更することがよくあり、ダウンタイムが発生する可能性があります。
In any case, to minimize such problems, the classic configuration is to have relatively short TTLs on all involved Resource Records. That will solve many of the problems regarding changes to a zone, regardless of whether DNSSEC is used.
いずれの場合も、このような問題を最小限に抑えるために、従来の構成では、関連するすべてのリソースレコードに比較的短いTTLを設定しています。これにより、DNSSECが使用されているかどうかに関係なく、ゾーンの変更に関する問題の多くが解決されます。
Without DNSSEC, all times in the DNS are relative. The SOA fields REFRESH, RETRY, and EXPIRATION are timers used to determine the time that has elapsed after a slave server synchronized with a master server. The TTL value and the SOA RR minimum TTL parameter [RFC2308] are used to determine how long a forwarder should cache data (or negative responses) 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フィールドのREFRESH、RETRY、およびEXPIRATIONは、スレーブサーバーがマスターサーバーと同期してから経過した時間を決定するために使用されるタイマーです。 TTL値とSOA RR最小TTLパラメータ[RFC2308]を使用して、権限のあるサーバーからデータがフェッチされた後、フォワーダーがデータ（または否定応答）をキャッシュする期間を決定します。署名の有効期間を使用することにより、DNSSECはDNSに絶対時間の概念を導入します。 DNSSECの署名には有効期限があり、有効期限が切れると署名は無効としてマークされ、署名されたデータは偽物と見なされます。
The considerations in this section are all qualitative and focused on the operational and managerial issues. A more thorough quantitative analysis of rollover timing parameters can be found in "DNSSEC Key Timing Considerations" [DNSSEC-KEY-TIMING].
このセクションの考慮事項はすべて定性的であり、運用および管理上の問題に焦点を当てています。ロールオーバータイミングパラメータのより完全な定量分析は、「DNSSECキータイミングの考慮事項」[DNSSEC-KEY-TIMING]にあります。
Because of the expiration of signatures, one should consider the following:
署名の有効期限のため、次のことを考慮する必要があります。
o We suggest that the Maximum Zone TTL value of your zone data be smaller than your signature validity period.
o ゾーンデータの最大ゾーンTTL値は、署名の有効期間よりも小さいことをお勧めします。
If the TTL duration was similar to that of the signature validity period, then all RRsets fetched during the validity period would be cached until the signature expiration time. Section 8.1 of RFC 4033 [RFC4033] 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, the query load on authoritative servers would peak at the signature expiration time, as this is also the time at which records simultaneously expire from caches.
TTL期間が署名の有効期間と同じである場合、有効期間中にフェッチされたすべてのRRsetは、署名の有効期限までキャッシュされます。 RFC 4033 [RFC4033]のセクション8.1は、「リゾルバーは、署名されたRRsetの署名有効期間の期限が切れるまでの残り時間をTTLの上限として使用する可能性がある」ことを示唆しています。その結果、権限のあるサーバーでのクエリの負荷は、署名の有効期限でピークになります。これは、レコードがキャッシュから同時に期限切れになる時刻でもあるためです。
Having a TTL that is at least a few times smaller than your signature validity period avoids query load peaks.
TTLが署名の有効期間の少なくとも数分の1であると、クエリ負荷のピークを回避できます。
o We suggest that the signature publication period end at least one Maximum Zone TTL duration (but preferably a minimum of a few days) 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 the simultaneous expiration of data from caches. This in turn may lead to peaks in the load on authoritative servers. To avoid this, schemes are deployed whereby the zone is periodically visited for a re-signing operation, and those signatures that are within a so-called Refresh Period from signature expiration are recreated. Also see Section 4.4.2 below.
署名の有効期間が終了する少し前にゾーンに再署名すると、キャッシュからのデータが同時に期限切れになる場合があります。これにより、権限のあるサーバーの負荷がピークに達する可能性があります。これを回避するために、再署名操作のためにゾーンに定期的にアクセスするスキームが展開され、署名の有効期限からいわゆる更新期間内にある署名が再作成されます。以下のセクション4.4.2も参照してください。
In the case of an operational error, you would have one Maximum Zone TTL duration to resolve the problem. Re-signing a zone a few days before the end of the signature validity period ensures that the signatures will survive at least a (long) weekend in case of such operational havoc. This is called the Refresh Period (see Section 4.4.2).
運用エラーの場合、問題を解決するための最大ゾーンTTL期間は1つです。署名の有効期間が終了する数日前にゾーンに再署名すると、そのような運用上の混乱が発生した場合に、署名が少なくとも（長い）週末に生き残ることが保証されます。これはリフレッシュ期間と呼ばれます（4.4.2項を参照）。
o We suggest that the Minimum Zone TTL be long enough to both fetch and verify all the RRs in the trust chain. In workshop environments, it has been demonstrated [NIST-Workshop] that a low TTL (under 5 to 10 minutes) caused disruptions because of the following two problems:
o 最小ゾーンTTLは、信頼チェーン内のすべてのRRをフェッチして検証するのに十分な長さであることをお勧めします。ワークショップ環境では、次の2つの問題が原因で、TTLが低い（5〜10分未満）ために障害が発生することが実証されています[NIST-Workshop]。
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: DS, DNSKEY, RRSIG, and the final answers, i.e., the RRset that is returned for the initial query.
1. 検証中に、検証が完了する前に一部のデータが期限切れになる場合があります。バリデーターは、完了するまですべてのデータを保持できる必要があります。これは、信頼の連鎖を完了するために必要なすべてのRRに適用されます：DS、DNSKEY、RRSIG、および最終的な回答、つまり最初のクエリに対して返されるRRset。
2. Frequent verification causes load on recursive name servers. Data at delegation points, DS, DNSKEY, and RRSIG RRs benefits from caching. The TTL on those should be relatively long. Data at the leaves in the DNS tree has less impact on recursive name servers.
2. 頻繁な検証により、再帰的なネームサーバーに負荷がかかります。委任ポイント、DS、DNSKEY、およびRRSIG RRのデータは、キャッシングの恩恵を受けます。それらのTTLは比較的長くなければなりません。 DNSツリーのリーフにあるデータは、再帰的なネームサーバーへの影響が少なくなります。
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 synchronization 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-secured zone, then it may happen that the signatures expire well before the SOA expiration timer counts down to zero. It is not possible to completely prevent this by modifying the SOA parameters.
サーバーがDNSSECで保護されたゾーンにサービスを提供している場合、SOA有効期限タイマーがゼロにカウントダウンする前にシグネチャが期限切れになることがあります。 SOAパラメータを変更してこれを完全に防ぐことはできません。
However, the effects can be minimized where the SOA expiration time is equal to or shorter than the Refresh Period (see Section 4.4.2).
ただし、SOAの有効期限が更新期間と同じかそれよりも短い場合は、影響を最小限に抑えることができます（セクション4.4.2を参照）。
The consequence of an authoritative server not being able to update a zone for an extended period of time is that signatures may expire. In this case, 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.
権限のあるサーバーが長期間ゾーンを更新できないと、署名が期限切れになる可能性があります。この場合、非セキュアリゾルバーは引き続き特定のスレーブサーバーによって提供されるデータを解決できますが、セキュリティ対応リゾルバーは回答が偽としてマークされているために問題が発生します。
We suggest that the SOA expiration timer be approximately one third or a quarter of the signature validity period. It will allow problems with transfers from the master server to be noticed before signatures time out.
SOA有効期限タイマーは、署名の有効期間の約3分の1または4分の1にすることをお勧めします。これにより、マスターサーバーからの転送に関する問題が、署名がタイムアウトする前に通知されます。
We also suggest that operators of name servers that supply secondary services develop systems to identify upcoming signature expirations in zones they slave and take appropriate action where such an event is detected.
また、セカンダリサービスを提供するネームサーバーのオペレーターは、スレーブになるゾーンで次の署名の有効期限を識別し、そのようなイベントが検出された場合に適切なアクションを実行するシステムを開発することをお勧めします。
When determining the value for the expiration parameter, one has to take the following into account: What are the chances that all secondaries expire the zone? How quickly can the administrators of the secondary servers be reached to load a valid zone? These questions are not DNSSEC-specific but may influence the choice of your signature validity periods.
有効期限パラメーターの値を決定するときは、次のことを考慮に入れる必要があります。すべてのセカンダリがゾーンを期限切れにする可能性はどれくらいですか？有効なゾーンをロードするために、セカンダリサーバーの管理者にどれくらい早く到達できますか？これらの質問はDNSSEC固有ではありませんが、署名の有効期間の選択に影響を与える可能性があります。
The first consideration for choosing a maximum signature validity period is the risk of a replay attack. For low-value, long-term stable resources, the risks may be minimal, and the signature validity period may be several months. Although signature validity periods of many years are allowed, the same "operational habit" arguments as those given in Section 3.2.2 play a role: When a zone is re-signed with some regularity, then zone administrators remain conscious of the operational necessity of re-signing.
署名の最大有効期間を選択する際の最初の考慮事項は、リプレイ攻撃のリスクです。価値が低く、長期的に安定したリソースの場合、リスクは最小限であり、署名の有効期間は数か月になる場合があります。長年の署名の有効期間が許可されていますが、セクション3.2.2で指定されたものと同じ「運用上の習慣」の引数が役割を果たします。ゾーンが一定の規則で再署名された場合、ゾーン管理者は、再署名。
The minimum value of the signature validity period is set for the time by which one would like to survive operational failure in provisioning: At what time will a failure be noticed, and at what time is action expected to be taken? By answering these questions, availability of zone administrators during (long) weekends or time taken to access backup media can be taken into account. The result could easily suggest a minimum signature validity period of a few days.
署名の有効期間の最小値は、プロビジョニングの運用上の失敗を乗り越えたい時間に設定されます。失敗はいつ通知され、いつアクションが実行されると予想されますか？これらの質問に回答することで、週末の（長い）週末やバックアップメディアへのアクセスにかかる時間にゾーン管理者が利用できるかどうかを考慮することができます。結果は、数日という署名の最小有効期間を簡単に示唆する可能性があります。
Note, however, that the argument above is assuming that zone data has just been signed and published when the problem occurred. In practice, it may be that a zone is signed according to a frequency set by the Re-Sign Period, whereby the signer visits the zone content and only refreshes signatures that are within a given amount of time (the Refresh Period) of expiration. The Re-Sign Period must be smaller than the Refresh Period in order for zone data to be signed in a timely fashion.
ただし、上記の引数は、問題が発生したときにゾーンデータが署名されて公開されたばかりであることを前提としていることに注意してください。実際には、再署名期間によって設定された頻度に従ってゾーンが署名され、署名者がゾーンのコンテンツにアクセスして、有効期限の所定の時間（更新期間）内の署名のみを更新する場合があります。ゾーンデータにタイムリーに署名するには、再署名期間を更新期間よりも短くする必要があります。
If an operational problem occurs during re-signing, then the signatures in the zone to expire first are the ones that have been generated longest ago. In the worst case, these signatures are the Refresh Period minus the Re-Sign Period away from signature expiration.
再署名中に運用上の問題が発生した場合、最初に期限切れになるゾーン内の署名は、最も前に生成されたものです。最悪の場合、これらの署名は、更新期間から署名の有効期限が切れる再署名期間を引いたものです。
To make matters slightly more complicated, some signers vary the signature validity period over a small range (the jitter interval) so that not all signatures expire at the same time.
問題を少し複雑にするために、一部の署名者は署名の有効期間を小さな範囲（ジッター間隔）で変化させ、すべての署名が同時に期限切れになるわけではないようにします。
In other words, the minimum signature validity period is set by first choosing the Refresh Period (usually a few days), then defining the Re-Sign Period in such a way that the Refresh Period minus the Re-Sign Period, minus the maximum jitter sets the time in which operational havoc can be resolved.
つまり、最小署名有効期間は、最初に更新期間（通常は数日）を選択し、次に更新期間から再署名期間を差し引いて最大ジッターを差し引いた方法で再署名期間を定義することによって設定されます。運用上の混乱を解決できる時間を設定します。
The relationship between signature times is illustrated in Figure 11.
署名時間の関係を図11に示します。
Inception Signing Expiration
time time time
| | | | |
|------------------|---------------------------------|.....|.....|
| | | | |
+/-jitter
| Inception offset | |
|<---------------->| Validity Period |
| |<---------------------------------------->|
Inception Signing Reuse Reuse Reuse New Expiration
time time RRSIG time
| | | | | | |
|------------------|-------------------------------|-------|
| | | | | | |
<-----> <-----> <-----> <----->
Re-Sign Period
| Refresh |
|<----------->|
| Period |
Figure 11: Signature Timing Parameters
図11：シグネチャタイミングパラメーター
Note that in the figure the validity of the signature starts shortly before the signing time. That is done to deal with validators that might have some clock skew. This is called the inception offset, and it should be chosen so that false negatives are minimized to a reasonable level.
この図では、署名の有効性が署名時刻の直前に始まることに注意してください。これは、クロックスキューがある可能性のあるバリデーターを処理するために行われます。これは開始オフセットと呼ばれ、偽陰性が合理的なレベルに最小化されるように選択する必要があります。
It is possible to vary signature validity periods between signatures over different RRsets in the zone. In practice, this could be done when zones contain highly volatile data (which may be the case in dynamic-update environments). Note, however, that the risk of replay (e.g., by stale secondary servers) should be the leading factor in determining the signature validity period, since the TTLs on the data itself are still the primary parameter for cache expiry.
ゾーン内の異なるRRset上のシグニチャ間でシグニチャの有効期間を変えることができます。実際には、これは、ゾーンに非常に揮発性の高いデータが含まれている場合に実行できます（動的更新環境の場合など）。ただし、データ自体のTTLはキャッシュの有効期限の主要なパラメータであるため、再生のリスク（古くなったセカンダリサーバーなど）が署名の有効期間を決定する主な要因になることに注意してください。
In some cases, the risk of replaying existing data might be different from the risk of replaying the denial of data. In those cases, the signature validity period on NSEC or NSEC3 records may be tweaked accordingly.
場合によっては、既存のデータを再生するリスクは、データの拒否を再生するリスクとは異なる場合があります。そのような場合、NSECまたはNSEC3レコードの署名の有効期間は、それに応じて微調整される場合があります。
When a zone contains secure delegations, then a relatively short signature validity period protects the child against replay attacks in the case where the child's key is compromised (see Section 4.3.4). Since there is a higher operational risk for the parent registry when choosing a short validity period and a higher operational risk for the child when choosing a long validity period, some (price) differentiation may occur for validity periods between individual DS RRs in a single zone.
ゾーンに安全な委任が含まれている場合、署名の有効期間が比較的短いため、子のキーが危険にさらされた場合のリプレイ攻撃から子が保護されます（セクション4.3.4を参照）。短い有効期間を選択すると親レジストリの運用リスクが高くなり、長い有効期間を選択すると子の運用リスクが高くなるため、単一ゾーン内の個々のDS RR間の有効期間にいくつかの（価格）差異が発生する可能性があります。
There seem to be no other arguments for differentiation in validity periods.
有効期間の区別については、他の議論はないようです。
One of the design tradeoffs made during the development of DNSSEC was to separate the signing and serving operations instead of performing cryptographic operations as DNS requests are being serviced. It is therefore necessary to create records that cover the very large number of nonexistent names that lie between the names that do exist.
DNSSECの開発中に行われた設計上のトレードオフの1つは、DNS要求が処理されるときに暗号操作を実行する代わりに、署名操作と提供操作を分離することでした。したがって、存在する名前の間にある非常に多数の存在しない名前をカバーするレコードを作成する必要があります。
There are two mechanisms to provide authenticated proof of nonexistence of domain names in DNSSEC: a clear-text one and an obfuscated-data one. Each mechanism:
DNSSECにドメイン名が存在しないことの認証済み証明を提供するメカニズムは2つあります。クリアテキストのメカニズムと難読化されたデータのメカニズムです。各メカニズム：
o includes a list of all the RRTYPEs present, which can be used to prove the nonexistence of RRTYPEs at a certain name;
o 存在するすべてのRRTYPEのリストを含みます。これは、特定の名前でRRTYPEが存在しないことを証明するために使用できます。
o stores only the name for which the zone is authoritative (that is, glue in the zone is omitted); and
o ゾーンが信頼できる名前のみを格納します（つまり、ゾーン内の接着剤は省略されます）。そして
o uses a specific RRTYPE to store information about the RRTYPEs present at the name: The clear-text mechanism uses NSEC, and the obfuscated-data mechanism uses NSEC3.
o 特定のRRTYPEを使用して、名前に存在するRRTYPEに関する情報を格納します。クリアテキストメカニズムはNSECを使用し、難読化データメカニズムはNSEC3を使用します。
The clear-text mechanism (NSEC) is implemented using a sorted linked list of names in the zone. The obfuscated-data mechanism (NSEC3) is similar but first hashes the names using a one-way hash function, before creating a sorted linked list of the resulting (hashed) strings.
クリアテキストメカニズム（NSEC）は、ゾーン内の名前のソートされたリンクリストを使用して実装されます。難読化されたデータのメカニズム（NSEC3）は似ていますが、結果の（ハッシュされた）文字列のソートされたリンクリストを作成する前に、まず一方向のハッシュ関数を使用して名前をハッシュします。
The NSEC record requires no cryptographic operations aside from the validation of its associated signature record. It is human readable and can be used in manual queries to determine correct operation. The disadvantage is that it allows for "zone walking", where one can request all the entries of a zone by following the linked list of NSEC RRs via the "Next Domain Name" field. Though all agree that DNS data is accessible through query mechanisms, for some zone administrators this behavior is undesirable for policy, regulatory, or other reasons.
NSECレコードは、関連する署名レコードの検証を除いて、暗号化操作を必要としません。人間が読める形式であり、手動クエリで使用して正しい操作を判断できます。欠点は、「ゾーンウォーキング」が可能で、「次のドメイン名」フィールドを介してNSEC RRのリンクリストをたどることにより、ゾーンのすべてのエントリを要求できることです。クエリメカニズムを介してDNSデータにアクセスできることに全員が同意していますが、一部のゾーン管理者にとって、この動作はポリシー、規制、またはその他の理由で望ましくない場合があります。
Furthermore, NSEC requires a signature over every RR in the zone file, thereby ensuring that any denial of existence is cryptographically signed. However, in a large zone file containing many delegations, very few of which are to signed zones, this may produce unacceptable additional overhead, especially where insecure delegations are subject to frequent updates (a typical example might be a TLD operator with few registrants using secure delegations). NSEC3 allows intervals between two secure delegations to "opt out", in which case they may contain one or more insecure delegations, thus reducing the size and cryptographic complexity of the zone at the expense of the ability to cryptographically deny the existence of names in a specific span.
さらに、NSECはゾーンファイル内のすべてのRRに対する署名を必要とするため、存在の拒否が暗号で署名されることが保証されます。ただし、署名ゾーンへのデリゲートが非常に少ない多くの委任を含む大きなゾーンファイルでは、これにより、特に、安全でない委任が頻繁に更新される場合に、許容できない追加のオーバーヘッドが発生する可能性があります（一般的な例は、安全な代表団）。 NSEC3は、2つの安全な委任の間の間隔を「オプトアウト」することを許可します。その場合、それらには1つ以上の安全でない委任が含まれる可能性があるため、ゾーン内の名前の存在を暗号で拒否する機能を犠牲にして、ゾーンのサイズと暗号の複雑さを減らします。特定のスパン。
The NSEC3 record uses a hashing method of the requested name. To increase the workload required to guess entries in the zone, the number of hashing iterations can be specified in the NSEC3 record. Additionally, a salt can be specified that also modifies the hashes. Note that NSEC3 does not give full protection against information leakage from the zone (you can still derive the size of the zone, which RRTYPEs are in there, etc.).
NSEC3レコードは、要求された名前のハッシュ方式を使用します。ゾーン内のエントリを推測するために必要なワークロードを増やすには、ハッシュの反復回数をNSEC3レコードで指定できます。さらに、ハッシュも変更するソルトを指定できます。 NSEC3はゾーンからの情報漏えいに対する完全な保護を提供しないことに注意してください（ゾーンのサイズ、RRTYPEがそこにあるなどを引き続き導出できます）。
The first motivation to deploy NSEC3 -- prevention of zone enumeration -- only makes sense when zone content is not highly structured or trivially guessable. Highly structured zones, such as in-addr.arpa., ip6.arpa., and e164.arpa., can be trivially enumerated using ordinary DNS properties, while for small zones that only contain records in the apex of the zone and a few common names such as "www" or "mail", guessing zone content and proving completeness is also trivial when using NSEC3. In these cases, the use of NSEC is preferred to ease the work required by signers and validating resolvers.
NSEC3を導入する最初の動機-ゾーン列挙の防止-は、ゾーンのコンテンツが高度に構造化されていないか、簡単に推測できない場合にのみ意味があります。 in-addr.arpa。、ip6.arpa。、e164.arpa。などの高度に構造化されたゾーンは、通常のDNSプロパティを使用して簡単に列挙できますが、ゾーンの頂点のレコードのみを含む小さなゾーンと「www」や「メール」などの一般的な名前、ゾーンコンテンツの推測、完全性の証明も、NSEC3を使用する場合は簡単です。これらの場合、NSECを使用すると、署名者と検証者による検証に必要な作業が容易になります。
For large zones where there is an implication of "not readily available" names, such as those where one has to sign a non-disclosure agreement before obtaining it, NSEC3 is preferred. The second reason to consider NSEC3 is "Opt-Out", which can reduce the number of NSEC3 records required. This is discussed further below (Section 5.3.4).
取得前に機密保持契約に署名する必要がある場合など、「すぐに利用できない」名前の影響がある大きなゾーンの場合、NSEC3が推奨されます。 NSEC3を検討する2番目の理由は、「オプトアウト」です。これにより、必要なNSEC3レコードの数を減らすことができます。これについては、以下でさらに説明します（セクション5.3.4）。
NSEC3 is controlled by a number of parameters, some of which can be varied: This section discusses the choice of those parameters.
NSEC3は、いくつかのパラメーターによって制御されます。そのいくつかは変更できます。このセクションでは、これらのパラメーターの選択について説明します。
The NSEC3 hashing algorithm is performed on the Fully Qualified Domain Name (FQDN) in its uncompressed form. This ensures that brute force work done by an attacker for one FQDN cannot be reused for another FQDN attack, as these entries are by definition unique.
NSEC3ハッシュアルゴリズムは、完全修飾ドメイン名（FQDN）に対して非圧縮形式で実行されます。これにより、これらのエントリは定義上一意であるため、攻撃者が1つのFQDNに対して行ったブルートフォース作業を別のFQDN攻撃に再利用することはできません。
At the time of this writing, there is only one NSEC3 hash algorithm defined. [RFC5155] specifically states: "When specifying a new hash algorithm for use with NSEC3, a transition mechanism MUST also be defined". Therefore, this document does not consider NSEC3 hash algorithm transition.
この記事の執筆時点では、NSEC3ハッシュアルゴリズムは1つしか定義されていません。 [RFC5155]は特に次のように述べています：「NSEC3で使用する新しいハッシュアルゴリズムを指定する場合、遷移メカニズムも定義する必要があります」。したがって、このドキュメントでは、NSEC3ハッシュアルゴリズムの移行については考慮していません。
One of the concerns with NSEC3 is that a pre-calculated dictionary attack could be performed in order to assess whether or not certain domain names exist within a zone. Two mechanisms are introduced in the NSEC3 specification to increase the costs of such dictionary attacks: iterations and salt.
NSEC3に関する懸念の1つは、特定のドメイン名がゾーン内に存在するかどうかを評価するために、事前に計算された辞書攻撃が実行される可能性があることです。このような辞書攻撃のコストを増加させるために、NSEC3仕様では2つのメカニズムが導入されています。それは反復とソルトです。
The iterations parameter defines the number of additional times the hash function has been performed. A higher value results in greater resiliency against dictionary attacks, at a higher computational cost for both the server and resolver.
反復パラメータは、ハッシュ関数が実行された追加の回数を定義します。値が大きいほど、辞書攻撃に対する回復力が高くなり、サーバーとリゾルバーの両方の計算コストが高くなります。
RFC 5155 Section 10.3 [RFC5155] considers the tradeoffs between incurring cost during the signing process and imposing costs to the validating name server, while still providing a reasonable barrier against dictionary attacks. It provides useful limits of iterations for a given RSA key size. These are 150 iterations for 1024-bit keys, 500 iterations for 2048-bit keys, and 2,500 iterations for 4096-bit keys. Choosing a value of 100 iterations is deemed to be a sufficiently costly, yet not excessive, value: In the worst-case scenario, the performance of name servers would be halved, regardless of key size [NSEC3-HASH-PERF].
RFC 5155セクション10.3 [RFC5155]は、署名プロセス中に発生するコストと検証ネームサーバーにコストを課すことの間のトレードオフを考慮しながら、辞書攻撃に対する妥当な障壁を提供しています。これは、指定されたRSA鍵サイズの反復の有用な制限を提供します。これらは、1024ビットキーの150回の反復、2048ビットキーの500回の反復、4096ビットキーの2,500回の反復です。 100反復の値を選択すると、十分にコストがかかりますが、過度ではありません。最悪の場合、ネームサーバーのパフォーマンスは、キーサイズに関係なく半分になります[NSEC3-HASH-PERF]。
While the NSEC3 iterations parameter increases the cost of hashing a dictionary word, the NSEC3 salt reduces the lifetime for which that calculated hash can be used. A change of the salt value by the zone administrator would cause an attacker to lose all pre-calculated work for that zone.
NSEC3反復パラメータは辞書の単語をハッシュするコストを増加させますが、NSEC3ソルトはその計算されたハッシュを使用できる寿命を短縮します。ゾーン管理者がソルト値を変更すると、攻撃者はそのゾーンの事前に計算されたすべての作業を失う可能性があります。
There must be a complete NSEC3 chain using the same salt value, that matches the salt value in the NSEC3PARAM record. NSEC3 salt changes do not need special rollover procedures. Since changing the salt requires that all the NSEC3 records be regenerated and thus requires generating new RRSIGs over these NSEC3 records, it makes sense to align the change of the salt with a change of the Zone Signing Key, as that process in itself already usually requires that all RRSIGs be regenerated. If there is no critical dependency on incremental signing and the zone can be signed with little effort, there is no need for such alignment.
同じソルト値を使用する完全なNSEC3チェーンが必要です。これは、NSEC3PARAMレコードのソルト値と一致します。 NSEC3ソルトの変更には、特別なロールオーバー手順は必要ありません。ソルトを変更するには、すべてのNSEC3レコードを再生成する必要があるため、これらのNSEC3レコードに対して新しいRRSIGを生成する必要があるため、ソルトの変更をゾーン署名キーの変更に合わせることが理にかなっています。すべてのRRSIGが再生成されること。インクリメンタル署名に重要な依存関係がなく、少しの労力でゾーンに署名できる場合、そのような調整は必要ありません。
The Opt-Out mechanism was introduced to allow for a gradual introduction of signed records in zones that contain mostly delegation records. The use of the Opt-Out flag changes the meaning of the NSEC3 span from authoritative denial of the existence of names within the span to proof that DNSSEC is not available for the delegations within the span. This allows for the addition or removal of the delegations covered by the span without recalculating or re-signing RRs in the NSEC3 RR chain.
オプトアウトメカニズムは、主に委任レコードを含むゾーンに署名付きレコードを段階的に導入できるようにするために導入されました。オプトアウトフラグを使用すると、NSEC3スパンの意味が、スパン内の名前の存在の正式な拒否から、DNSSECがスパン内の委任で使用できないことの証明に変わります。これにより、NSEC3 RRチェーンのRRを再計算したり再署名したりすることなく、スパンの対象となる委任を追加または削除できます。
Opt-Out is specified to be used only over delegation points and will therefore only bring relief to zones with a large number of insecure delegations. This consideration typically holds for large TLDs and similar zones; in most other circumstances, Opt-Out should not be deployed. Further considerations can be found in Section 12.2 of RFC 5155 [RFC5155].
オプトアウトは、委任ポイントでのみ使用するように指定されているため、安全でない委任が多数あるゾーンにのみ軽減をもたらします。この考慮事項は、通常、大規模なTLDおよび同様のゾーンに当てはまります。他のほとんどの状況では、オプトアウトを展開しないでください。 RFC 5155 [RFC5155]のセクション12.2にさらに考慮事項があります。
DNSSEC adds data origin authentication and data integrity to the DNS, using digital signatures over Resource Record sets. DNSSEC does not protect against denial-of-service attacks, nor does it provide confidentiality. For more general security considerations related to DNSSEC, please see RFC 4033 [RFC4033], RFC 4034 [RFC4034], and RFC 4035 [RFC4035].
DNSSECは、リソースレコードセットのデジタル署名を使用して、データオリジン認証とデータ整合性をDNSに追加します。 DNSSECは、サービス拒否攻撃から保護することも、機密性を提供することもありません。 DNSSECに関連するより一般的なセキュリティの考慮事項については、RFC 4033 [RFC4033]、RFC 4034 [RFC4034]、およびRFC 4035 [RFC4035]を参照してください。
This document tries to assess the operational considerations to maintain a stable and secure DNSSEC service. When performing key rollovers, it is important to keep in mind that it takes time for the data to be propagated to the verifying clients. It is also important to note that this data may be cached. Not taking into account the 'data propagation' properties in the DNS may cause validation failures, because cached data may mismatch data fetched from the authoritative servers; this will make secured zones unavailable to security-aware resolvers.
このドキュメントでは、安定した安全なDNSSECサービスを維持するための運用上の考慮事項を評価します。キーのロールオーバーを実行するときは、データが検証中のクライアントに伝達されるまでに時間がかかることに注意してください。このデータはキャッシュされる可能性があることに注意することも重要です。キャッシュされたデータが権限のあるサーバーからフェッチされたデータと一致しない場合があるため、DNSの「データ伝播」プロパティを考慮しないと、検証エラーが発生する可能性があります。これにより、セキュリティ対応のリゾルバーが保護されたゾーンを使用できなくなります。
Significant parts of the text of this document are copied from RFC 4641 [RFC4641]. That document was edited by Olaf Kolkman and Miek Gieben. Other people that contributed or were otherwise involved in that work were, 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, Peter Koch, Mike StJohns, Emma Bretherick, Adrian Bedford, Lindy Foster, and O. Courtay.
このドキュメントのテキストの重要な部分は、RFC 4641 [RFC4641]からコピーされています。そのドキュメントは、Olaf KolkmanとMiek Giebenによって編集されました。その作業に貢献したか、または他の方法でその作業に関与した人々は、ランダムな順序でありました：リップルーミス、オラファーグドマンソン、ウェスリーグリフィン、マイケルリチャードソン、スコットローズ、リックヴァンレイン、ティムマクギニス、ジルゲット、オリヴィエコートイ、サムワイラー、ジェルトジャンセン、ニール・オライリー、ホルガー・ズレガー、エド・ルイス、ヒラリー・オーマン、マルコス・サンズ、ピーター・コッホ、マイク・セントジョンズ、エマ・ブレセリック、エイドリアン・ベッドフォード、リンディ・フォスター、O。コートイ。
For this version of the document, we would like to acknowledge people who were actively involved in the compilation of the document. In random order: Mark Andrews, Patrik Faltstrom, Tony Finch, Alfred Hoenes, Bill Manning, Scott Rose, Wouter Wijngaards, Antoin Verschuren, Marc Lampo, George Barwood, Sebastian Castro, Suresh Krishnaswamy, Eric Rescorla, Stephen Morris, Olafur Gudmundsson, Ondrej Sury, and Rickard Bellgrim.
このバージョンのドキュメントでは、ドキュメントの編集に積極的に関与した人々に感謝します。順不同：マークアンドリュース、パトリックファルストストロム、トニーフィンチ、アルフレッドホーネス、ビルマニング、スコットローズ、ウーターウィンガード、アントインヴェルシュレン、マークランポ、ジョージバーウッド、セバスチャンカストロ、スレーシュクリシュナスワミー、エリックレスコーラ、スティーブンモリス、オラファーグドマンズソン、オンドレスーリー、そしてリッカード・ベルグリム。
Significant contributions to this document were from:
このドキュメントへの重要な貢献は次のとおりです。
Paul Hoffman, who contributed on the choice of cryptographic parameters and addressing some of the trust anchor issues;
暗号化パラメーターの選択に貢献し、トラストアンカーの問題のいくつかに対処したPaul Hoffman。
Jelte Jansen, who provided the initial text in Section 4.1.4;
セクション4.1.4の最初のテキストを提供したJelte Jansen。
Paul Wouters, who provided the initial text for Section 5, and Alex Bligh, who improved it.
セクション5の最初のテキストを提供したPaul Wouters、およびそれを改善したAlex Bligh。
The figure in Section 4.4.2 was adapted from the OpenDNSSEC user documentation.
セクション4.4.2の図は、OpenDNSSECのユーザーマニュアルに基づいています。
[RFC1034] Mockapetris, P., "Domain names - concepts and facilities", STD 13, RFC 1034, November 1987.
[RFC1034] Mockapetris、P。、「ドメイン名-概念と機能」、STD 13、RFC 1034、1987年11月。
[RFC1035] Mockapetris, P., "Domain names - implementation and specification", STD 13, RFC 1035, November 1987.
[RFC1035] Mockapetris、P。、「ドメイン名-実装と仕様」、STD 13、RFC 1035、1987年11月。
[RFC4033] Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose, "DNS Security Introduction and Requirements", RFC 4033, March 2005.
[RFC4033] Arends、R.、Austein、R.、Larson、M.、Massey、D。、およびS. Rose、「DNSセキュリティの概要と要件」、RFC 4033、2005年3月。
[RFC4034] Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose, "Resource Records for the DNS Security Extensions", RFC 4034, March 2005.
[RFC4034] Arends、R.、Austein、R.、Larson、M.、Massey、D。、およびS. Rose、「DNS Security Extensionsのリソースレコード」、RFC 4034、2005年3月。
[RFC4035] Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose, "Protocol Modifications for the DNS Security Extensions", RFC 4035, March 2005.
[RFC4035] Arends、R.、Austein、R.、Larson、M.、Massey、D。、およびS. Rose、「DNS Security Extensionsのプロトコル変更」、RFC 4035、2005年3月。
[RFC4509] Hardaker, W., "Use of SHA-256 in DNSSEC Delegation Signer (DS) Resource Records (RRs)", RFC 4509, May 2006.
[RFC4509] Hardaker、W。、「DNSSEC委任署名者（DS）リソースレコード（RR）でのSHA-256の使用」、RFC 4509、2006年5月。
[RFC5155] Laurie, B., Sisson, G., Arends, R., and D. Blacka, "DNS Security (DNSSEC) Hashed Authenticated Denial of Existence", RFC 5155, March 2008.
[RFC5155] Laurie、B.、Sisson、G.、Arends、R。、およびD. Blacka、「DNS Security（DNSSEC）Hashed Authenticated Denial of Existence」、RFC 5155、2008年3月。
[RFC5702] Jansen, J., "Use of SHA-2 Algorithms with RSA in DNSKEY and RRSIG Resource Records for DNSSEC", RFC 5702, October 2009.
[RFC5702] Jansen、J。、「DNSKEYのRSAを使用したSHA-2アルゴリズムとDNSSECのRRSIGリソースレコードの使用」、RFC 5702、2009年10月。
[RFC1995] Ohta, M., "Incremental Zone Transfer in DNS", RFC 1995, August 1996.
[RFC1995]太田雅明、「DNSの増分ゾーン転送」、RFC 1995、1996年8月。
[RFC1996] Vixie, P., "A Mechanism for Prompt Notification of Zone Changes (DNS NOTIFY)", RFC 1996, August 1996.
[RFC1996] Vixie、P。、「ゾーン変更の迅速な通知のためのメカニズム（DNS NOTIFY）」、RFC 1996、1996年8月。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119] Bradner、S。、「要件レベルを示すためにRFCで使用するキーワード」、BCP 14、RFC 2119、1997年3月。
[RFC2308] Andrews, M., "Negative Caching of DNS Queries (DNS NCACHE)", RFC 2308, March 1998.
[RFC2308]アンドリュースM。、「DNSクエリのネガティブキャッシング（DNS NCACHE）」、RFC 2308、1998年3月。
[RFC3007] Wellington, B., "Secure Domain Name System (DNS) Dynamic Update", RFC 3007, November 2000.
[RFC3007]ウェリントン、B。、「Secure Domain Name System（DNS）Dynamic Update」、RFC 3007、2000年11月。
[RFC3375] Hollenbeck, S., "Generic Registry-Registrar Protocol Requirements", RFC 3375, September 2002.
[RFC3375] Hollenbeck、S。、「Generic Registry-Registrar Protocol Requirements」、RFC 3375、2002年9月。
[RFC3766] Orman, H. and P. Hoffman, "Determining Strengths For Public Keys Used For Exchanging Symmetric Keys", BCP 86, RFC 3766, April 2004.
[RFC3766] Orman、H。およびP. Hoffman、「Determining Strengths for Public Keys Exchangeing Symmetric Keys」、BCP 86、RFC 3766、2004年4月。
[RFC4086] Eastlake, D., Schiller, J., and S. Crocker, "Randomness Requirements for Security", BCP 106, RFC 4086, June 2005.
[RFC4086] Eastlake、D.、Schiller、J。、およびS. Crocker、「Randomness Requirements for Security」、BCP 106、RFC 4086、2005年6月。
[RFC4641] Kolkman, O. and R. Gieben, "DNSSEC Operational Practices", RFC 4641, September 2006.
[RFC4641] Kolkman、O。およびR. Gieben、「DNSSEC Operational Practices」、RFC 4641、2006年9月。
[RFC4949] Shirey, R., "Internet Security Glossary, Version 2", RFC 4949, August 2007.
[RFC4949] Shirey、R。、「インターネットセキュリティ用語集、バージョン2」、RFC 4949、2007年8月。
[RFC5011] StJohns, M., "Automated Updates of DNS Security (DNSSEC) Trust Anchors", RFC 5011, September 2007.
[RFC5011] StJohns、M。、「DNS Security（DNSSEC）Trust Anchorsの自動更新」、RFC 5011、2007年9月。
[RFC5910] Gould, J. and S. Hollenbeck, "Domain Name System (DNS) Security Extensions Mapping for the Extensible Provisioning Protocol (EPP)", RFC 5910, May 2010.
[RFC5910] Gould、J。およびS. Hollenbeck、「Extensible Provisioning Protocol（EPP）のドメインネームシステム（DNS）セキュリティ拡張マッピング」、RFC 5910、2010年5月。
[RFC5933] Dolmatov, V., Chuprina, A., and I. Ustinov, "Use of GOST Signature Algorithms in DNSKEY and RRSIG Resource Records for DNSSEC", RFC 5933, July 2010.
[RFC5933] Dolmatov、V.、Chuprina、A。、およびI. Ustinov、「DNSSECのDNSKEYおよびRRSIGリソースレコードでのGOST署名アルゴリズムの使用」、RFC 5933、2010年7月。
[RFC6605] Hoffman, P. and W. Wijngaards, "Elliptic Curve Digital Signature Algorithm (DSA) for DNSSEC", RFC 6605, April 2012.
[RFC6605] Hoffman、P。およびW. Wijngaards、「DNSSECの楕円曲線デジタル署名アルゴリズム（DSA）」、RFC 6605、2012年4月。
[NIST-Workshop] Rose, S., "NIST DNSSEC workshop notes", July 2001, <http://www.ietf.org/mail-archive/web/dnsop/current/ msg01020.html>.
[NIST-Workshop] Rose、S。、「NIST DNSSEC Workshop notes」、2001年7月、<http://www.ietf.org/mail-archive/web/dnsop/current/ msg01020.html>。
[NIST-SP-800-90A] Barker, E. and J. Kelsey, "Recommendation for Random Number Generation Using Deterministic Random Bit Generators", NIST Special Publication 800-90A, January 2012.
[NIST-SP-800-90A] Barker、E。、およびJ. Kelsey、「決定論的乱数ビットジェネレーターを使用した乱数生成の推奨」、NIST Special Publication 800-90A、2012年1月。
[RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security (TLS) Protocol Version 1.2", RFC 5246, August 2008.
[RFC5246] Dierks、T。およびE. Rescorla、「The Transport Layer Security（TLS）Protocol Version 1.2」、RFC 5246、2008年8月。
[DNSSEC-KEY-TIMING] Morris, S., Ihren, J., and J. Dickinson, "DNSSEC Key Timing Considerations", Work in Progress, July 2012.
[DNSSEC-KEY-TIMING] Morris、S.、Ihren、J。、およびJ. Dickinson、「DNSSEC Key Timing Considerations」、Work in Progress、2012年7月。
[DNSSEC-DPS] Ljunggren, F., Eklund Lowinder, AM., and T. Okubo, "A Framework for DNSSEC Policies and DNSSEC Practice Statements", Work in Progress, November 2012.
[DNSSEC-DPS] Ljunggren、F.、Eklund Lowinder、AM。、およびT. Okubo、「AフレームワークのDNSSECポリシーとDNSSEC実践ステートメント」、作業中、2012年11月。
[DNSSEC-TRUST-ANCHOR] Larson, M. and O. Gudmundsson, "DNSSEC Trust Anchor Configuration and Maintenance", Work in Progress, October 2010.
[DNSSEC-TRUST-ANCHOR] Larson、M。およびO. Gudmundsson、「DNSSEC Trust Anchor Configuration and Maintenance」、Work in Progress、2010年10月。
[NSEC3-HASH-PERF] Schaeffer, Y., "NSEC3 Hash Performance", NLnet Labs document 2010-002, March 2010.
[NSEC3-HASH-PERF] Schaeffer、Y。、「NSEC3 Hash Performance」、NLnet Labsドキュメント2010-002、2010年3月。
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 RFC 4033 [RFC4033]. An RRset in DNSSEC is marked "Bogus" when a signature of an RRset does not validate against a DNSKEY.
偽物：RFC 4033 [RFC4033]のセクション5もご覧ください。 DNSSECのRRsetは、RRsetの署名がDNSKEYに対して検証されない場合、「偽」とマークされます。
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.
鍵のロールオーバー：鍵のロールオーバー（一部の環境では鍵の交替とも呼ばれます）は、鍵の有効期間の終わりに、ある鍵ペアを別の鍵ペアに置き換える行為です。
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）は、頂点鍵セットの署名にのみ使用される鍵です。キーがKSKであるという事実は、署名ツールにのみ関連します。
Key size: The term 'key size' can be substituted by 'modulus size' throughout the document for RSA keys. It is mathematically more correct to use modulus size for RSA keys, but as this is a document directed at operators we feel more at ease with the term 'key size'.
鍵サイズ：RSA鍵の場合、「鍵サイズ」という用語は、ドキュメント全体で「係数サイズ」に置き換えることができます。 RSAキーに係数サイズを使用する方が数学的に正しいですが、これはオペレーター向けのドキュメントであるため、「キーサイズ」という用語の方が安心できます。
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 the use of the DNSKEY Resource Record (DNSKEY RR). Private keys should remain private.
秘密キーと公開キー：DNSSECは、公開キー暗号化を使用してDNSを保護します。公開鍵暗号化は、公開鍵と秘密鍵の2つの（数学的に関連した）鍵の存在に基づいています。公開鍵は、DNSKEYリソースレコード（DNSKEY RR）を使用してDNSで公開されます。秘密鍵は秘密にしておく必要があります。
Refresh Period: The period before the expiration time of the signature, during which the signature is refreshed by the signer.
更新期間：署名の有効期限が切れる前の期間。この期間中、署名者は署名を更新します。
Re-Sign Period: This refers to the frequency with which a signing pass on the zone is performed. The Re-Sign Period defines when the zone is exposed to the signer. And on the signer, not all signatures in the zone have to be regenerated: That depends on the Refresh Period.
再署名期間：これは、ゾーンで署名パスが実行される頻度を指します。再署名期間は、ゾーンが署名者に公開される時期を定義します。また、署名者では、ゾーン内のすべての署名を再生成する必要はありません。これは、更新期間によって異なります。
Secure Entry Point (SEP) key: A KSK that has a DS record in the parent zone pointing to it or that is configured as a trust anchor. Although not required by the protocol, we suggest that the SEP flag [RFC4034] be set on these keys.
セキュアエントリポイント（SEP）キー：親ゾーンにDSレコードを指している、またはトラストアンカーとして構成されているKSK。プロトコルでは必須ではありませんが、SEPフラグ[RFC4034]をこれらのキーに設定することをお勧めします。
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.
自己署名：これはDNSKEYを介した署名にのみ適用されます。 DNSKEY xを介してDNSKEY xで作成された署名は、自己署名と呼ばれます。注：詳細情報がないと、自己署名は信頼を伝えません。これらは、DNSKEYの信頼性をチェックするのに役立ちます。つまり、ハッシュとして使用できます。
Signing jitter: A random variation in the signature validity period of RRSIGs in a zone to prevent all of them from expiring at the same time.
署名ジッター：ゾーン内のRRSIGの署名有効期間のランダムな変動で、すべてが同時に期限切れになるのを防ぎます。
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のみに署名するように構成できます。
Singing the zone file: The term used for the event where an administrator joyfully signs its zone file while producing melodic sound patterns.
ゾーンファイルを歌う：管理者がメロディックなサウンドパターンを生成しながらゾーンファイルに楽しく署名するイベントに使用される用語。
Single-Type Signing Scheme: A signing scheme whereby the distinction between Zone Signing Keys and Key Signing Keys is not made.
シングルタイプ署名スキーム：ゾーン署名キーとキー署名キーの区別が行われない署名スキーム。
Zone administrator: The 'role' that is responsible for signing a zone and publishing it on the primary authoritative server.
ゾーン管理者：ゾーンへの署名とプライマリ権限のあるサーバーでのゾーンの公開を担当する「役割」。
Zone Signing Key (ZSK): A key that is used for signing all data in a zone (except, perhaps, the DNSKEY RRset). The fact that a key is a ZSK is only relevant to the signing tool.
ゾーン署名キー（ZSK）：ゾーン内のすべてのデータ（おそらくDNSKEY RRsetを除く）に署名するために使用されるキー。キーがZSKであるという事実は、署名ツールにのみ関連します。
The following typographic conventions are used in this document:
このドキュメントでは、次の表記規則を使用しています。
Key notation: A key is denoted by DNSKEY_x_y, where x is an identifier for the type of key: K for Key Signing Key, Z for Zone Signing Key, and S when there is no distinction made between KSKs and ZSKs but the key is used as a secure entry point. The 'y' denotes a number or an identifier; y could be thought of as the key id.
鍵の表記：鍵はDNSKEY_x_yで示されます。xは鍵のタイプの識別子です。Kは鍵署名鍵、Zはゾーン署名鍵、SはKSKとZSKを区別しないが鍵が使用される場合安全なエントリポイントとして。 「y」は番号または識別子を示します。 yはキーIDと考えることができます。
RRsets ignored: If the signatures of non-DNSKEY RRsets have the same parameters as the SOA, then those are not mentioned; e.g., in the example below, the SOA is signed with the same parameters as the foo.example.com A RRset and the latter is therefore ignored in the abbreviated notation.
無視されるRRset：非DNSKEY RRsetの署名がSOAと同じパラメーターを持っている場合、それらは言及されません。たとえば、以下の例では、SOAはfoo.example.com A RRsetと同じパラメーターで署名されているため、省略表記では後者は無視されます。
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. An example of this would be "A1, A2", specifying the RRset containing two "A" records. This could again be abbreviated to just "A".
RRset表記：RRはタイプによってのみ示されます。その他のすべての情報（所有者、クラス、rdata、TTL）は省略されています。したがって、「example.com 3600 IN A 192.0.2.1」は「A」に削減されます。 RRsetはRRのリストです。この例は、 "A1、A2"で、2つの "A"レコードを含むRRsetを指定しています。これも、単に "A"に短縮できます。
Signature notation: Signatures are denoted as RRSIG_x_y(type), which means that the RRset with the specific RRTYPE 'type' is signed with DNSKEY_x_y. Signatures in the parent zone are denoted as RRSIG_par(type).
署名表記：署名はRRSIG_x_y（type）として示されます。これは、特定のRRTYPE「タイプ」のRRsetがDNSKEY_x_yで署名されていることを意味します。親ゾーンの署名はRRSIG_par（type）として示されます。
SOA representation: SOAs are represented as SOA_x, where x is the serial number.
SOA表現：SOAはSOA_xとして表されます。xはシリアル番号です。
DS representation: DSs are represented as DS_x_y, where x and y are identifiers similar to the key notation: x is an identifier for the type of key the DS record refers to; y is the 'key id' of the key it refers to.
DS表現：DSはDS_x_yとして表されます。ここで、xおよびyはキー表記と同様の識別子です。xはDSレコードが参照するキーのタイプの識別子です。 yは、参照するキーの「キーID」です。
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 "SOA_x".
ゾーン表現：上記の表記を使用して、名前などの不要な詳細をすべて省略し、すべてのデータを「SOA_x」で表すことにより、署名済みゾーンの表現を簡略化しました。
Using this notation, the following signed zone:
この表記を使用すると、次の署名済みゾーン：
example.com. 3600 IN SOA ns1.example.com. olaf.example.net. ( 2005092303 ; serial 450 ; refresh (7 minutes 30 seconds) 600 ; retry (10 minutes) 345600 ; expire (4 days) 300 ; minimum (5 minutes) ) 3600 RRSIG SOA 5 2 3600 20120824013000 ( 20100424013000 14 example.com. NMafnzmmZ8wevpCOI+/JxqWBzPxrnzPnSXfo ... OMY3rTMA2qorupQXjQ== ) 3600 NS ns1.example.com. 3600 NS ns2.example.com. 3600 NS ns3.example.com. 3600 RRSIG NS 5 2 3600 20120824013000 ( 20100424013000 14 example.com. p0Cj3wzGoPFftFZjj3jeKGK6wGWLwY6mCBEz ... +SqZIoVHpvE7YBeH46wuyF8w4XknA4Oeimc4 zAgaJM/MeG08KpeHhg== ) 3600 TXT "Net::DNS domain" 3600 RRSIG TXT 5 2 3600 20120824013000 ( 20100424013000 14 example.com. o7eP8LISK2TEutFQRvK/+U3wq7t4X+PQaQkp ... BcQ1o99vwn+IS4+J1g== ) 300 NSEC foo.example.com. NS SOA TXT RRSIG NSEC DNSKEY 300 RRSIG NSEC 5 2 300 20120824013000 ( 20100424013000 14 example.com. JtHm8ta0diCWYGu/TdrE1O1sYSHblN2i/IX+ ... PkXNI/Vgf4t3xZaIyw== ) 3600 DNSKEY 256 3 5 ( AQPaoHW/nC0fj9HuCW3hACSGiP0AkPS3dQFX ... sAuryjQ/HFa5r4mrbhkJ ) ; key id = 14 3600 DNSKEY 257 3 5 ( AQPUiszMMAi36agx/V+7Tw95l8PYmoVjHWvO ... oy88Nh+u2c9HF1tw0naH ) ; key id = 15
example.com。 3600 IN SOA ns1.example.com。 olaf.example.net。 （2005092303;シリアル450;更新（7分30秒）600;再試行（10分）345600;有効期限（4日）300;最小（5分））3600 RRSIG SOA 5 2 3600 20120824013000（20100424013000 14 example.com。NMafnzmmZ8wevpCOI + / JxqWBzPxrnzPnSXfo ... OMY3rTMA2qorupQXjQ ==）3600 NS ns1.example.com。 3600 NS ns2.example.com。 3600 NS ns3.example.com。 3600 RRSIG NS 5 2 3600 20120824013000（20100424013000 14 example.com。p0Cj3wzGoPFftFZjj3jeKGK6wGWLwY6mCBEz ... + SqZIoVHpvE7YBeH46wuyF8w4XknA4Oeimc4 zAgaJM / MeG08KpeHhg ==）3600 TXT "ネット:: DNSドメイン" 3600 RRSIG TXT 5 2 3600 20120824013000（20100424013000 14 example.com。o7eP8LISK2TEutFQRvK / + U3wq7t4X + PQaQkp ... BcQ1o99vwn + IS4 + J1g ==）300 NSEC foo.example.com。 NS SOA TXT RRSIG NSEC DNSKEY 300 RRSIG NSEC 5 2 300 20120824013000（20100424013000 14 example.com。 ; key id = 14 3600 DNSKEY 257 3 5（AQPUiszMMAi36agx / V + 7Tw95l8PYmoVjHWvO ... oy88Nh + u2c9HF1tw0naH）;キーID = 15
3600 RRSIG DNSKEY 5 2 3600 20120824013000 ( 20100424013000 14 example.com. HWj/VEr6p/FiUUiL70QQWtk+NBIlsJ9mdj5U ... QhhmMwV3tIxJk2eDRQ== ) 3600 RRSIG DNSKEY 5 2 3600 20120824013000 ( 20100424013000 15 example.com. P47CUy/xPV8qIEuua4tMKG6ei3LQ8RYv3TwE ... JWL70YiUnUG3m9OL9w== ) foo.example.com. 3600 IN A 192.0.2.2 3600 RRSIG A 5 3 3600 20120824013000 ( 20100424013000 14 example.com. xHr023P79YrSHHMtSL0a1nlfUt4ywn/vWqsO ... JPV/SA4BkoFxIcPrDQ== ) 300 NSEC example.com. A RRSIG NSEC 300 RRSIG NSEC 5 3 300 20120824013000 ( 20100424013000 14 example.com. Aaa4kgKhqY7Lzjq3rlPlFidymOeBEK1T6vUF ... Qe000JyzObxx27pY8A== )
3600 RRSIG DNSKEY 5 2 3600 20120824013000（20100424013000 14 example.com。HWj / VEr6p / FiUUiL70QQWtk + NBIlsJ9mdj5U ... QhhmMwV3tIxJk2eDRQ ==）3600 RRSIG DNSKEY 5 2 3600 201208240QURY9w3w3qy3w3w3Rym3w3w3iQ3w3w3mQ3uYm3w3w3u3mw9rw3u3w3qmw9r3q3rw9rw3u3q3rw9rw3c9rw3rw9rw3c9rw3r9w3c3uw9rw3c9y3w3w9c3w3c9w3w3c9yw3c9ew3w9c3wc9w3c9w3c9w3cw3c9w3c9w3cwc =）foo.example.com。 3600 IN A 192.0.2.2 3600 RRSIG A 5 3 3600 20120824013000（20100424013000 14 example.com。xHr023P79YrSHHMtSL0a1nlfUt4ywn / vWqsO ... JPV / SA4BkoFxIcPrDQ ==）300 NSEC example.com。 A RRSIG NSEC 300 RRSIG NSEC 5 3 300 20120824013000（20100424013000 14 example.com。Aaa4kgKhqY7Lzjq3rlPlFidymOeBEK1T6vUF ... Qe000JyzObxx27pY8A ==）
is reduced to the following representation:
は次の表現に縮小されます。
SOA_2005092303 RRSIG_Z_14(SOA_2005092303) DNSKEY_K_14 DNSKEY_Z_15 RRSIG_K_14(DNSKEY) RRSIG_Z_15(DNSKEY)
SOA_2005092303 RRSIG_Z_14（SOA_2005092303）DNSKEY_K_14 DNSKEY_Z_15 RRSIG_K_14（DNSKEY）RRSIG_Z_15（DNSKEY）
The rest of the zone data has the same signature as the SOA record, i.e., an RRSIG created with DNSKEY_K_14.
ゾーンデータの残りの部分には、SOAレコードと同じ署名があります。つまり、DNSKEY_K_14で作成されたRRSIGです。
The figures in this appendix complement and illustrate the special cases of algorithm rollovers as described in Section 4.1.4.
この付録の図は、セクション4.1.4で説明されているアルゴリズムロールオーバーの特殊なケースを補足し、示しています。
----------------------------------------------------------------
initial new RRSIGs new DNSKEY
----------------------------------------------------------------
Parent:
SOA_0 -------------------------------------------------------->
RRSIG_par(SOA) ----------------------------------------------->
DS_S_1 ------------------------------------------------------->
RRSIG_par(DS_S_1) -------------------------------------------->
Child:
SOA_0 SOA_1 SOA_2
RRSIG_S_1(SOA) RRSIG_S_1(SOA) RRSIG_S_1(SOA)
RRSIG_S_2(SOA) RRSIG_S_2(SOA)
DNSKEY_S_1 DNSKEY_S_1 DNSKEY_S_1 DNSKEY_S_2 RRSIG_S_1(DNSKEY) RRSIG_S_1(DNSKEY) RRSIG_S_1(DNSKEY) RRSIG_S_2(DNSKEY) RRSIG_S_2(DNSKEY)
DNSKEY_S_1 DNSKEY_S_1 DNSKEY_S_1 DNSKEY_S_2 RRSIG_S_1（DNSKEY）RRSIG_S_1（DNSKEY）RRSIG_S_1（DNSKEY）RRSIG_S_2（DNSKEY）RRSIG_S_2（DNSKEY）
----------------------------------------------------------------
new DS DNSKEY removal RRSIGs removal
----------------------------------------------------------------
Parent:
SOA_1 ------------------------------------------------------->
RRSIG_par(SOA) ---------------------------------------------->
DS_S_2 ------------------------------------------------------>
RRSIG_par(DS_S_2) ------------------------------------------->
Child:
-------------------> SOA_3 SOA_4
-------------------> RRSIG_S_1(SOA)
-------------------> RRSIG_S_2(SOA) RRSIG_S_2(SOA)
------------------->
-------------------> DNSKEY_S_2 DNSKEY_S_2
-------------------> RRSIG_S_1(DNSKEY)
-------------------> RRSIG_S_2(DNSKEY) RRSIG_S_2(DNSKEY)
----------------------------------------------------------------
Figure 12: Single-Type Signing Scheme Algorithm Roll
図12：単一タイプの署名方式アルゴリズムロール
Also see Section 4.1.4.1.
セクション4.1.4.1も参照してください。
----------------------------------------------------------------
initial new RRSIGs new DNSKEY
----------------------------------------------------------------
Parent:
SOA_0 -------------------------------------------------------->
RRSIG_par(SOA) ----------------------------------------------->
DS_K_1 ------------------------------------------------------->
RRSIG_par(DS_K_1) -------------------------------------------->
Child:
SOA_0 SOA_1 SOA_2
RRSIG_Z_1(SOA) RRSIG_Z_1(SOA) RRSIG_Z_1(SOA)
RRSIG_Z_2(SOA) RRSIG_Z_2(SOA)
DNSKEY_K_1 DNSKEY_K_1 DNSKEY_K_1 DNSKEY_K_2 DNSKEY_Z_1 DNSKEY_Z_1 DNSKEY_Z_1 DNSKEY_Z_2 RRSIG_K_1(DNSKEY) RRSIG_K_1(DNSKEY) RRSIG_K_1(DNSKEY) RRSIG_K_2(DNSKEY)
DNSKEY_K_1 DNSKEY_K_1 DNSKEY_K_1 DNSKEY_K_2 DNSKEY_Z_1 DNSKEY_Z_1 DNSKEY_Z_1 DNSKEY_Z_2 RRSIG_K_1（DNSKEY）RRSIG_K_1（DNSKEY）RRSIG_K_1（DNSKEY）RRSIG_K_2（DNSKEY）
----------------------------------------------------------------
new DS revoke DNSKEY DNSKEY removal
----------------------------------------------------------------
Parent:
SOA_1 ------------------------------------------------------->
RRSIG_par(SOA) ---------------------------------------------->
DS_K_2 ------------------------------------------------------>
RRSIG_par(DS_K_2) ------------------------------------------->
Child:
-------------------> SOA_3 SOA_4
-------------------> RRSIG_Z_1(SOA) RRSIG_Z_1(SOA)
-------------------> RRSIG_Z_2(SOA) RRSIG_Z_2(SOA)
-------------------> DNSKEY_K_1_REVOKED
-------------------> DNSKEY_K_2 DNSKEY_K_2
------------------->
-------------------> DNSKEY_Z_2 DNSKEY_Z_2
-------------------> RRSIG_K_1(DNSKEY)
-------------------> RRSIG_K_2(DNSKEY) RRSIG_K_2(DNSKEY)
----------------------------------------------------------------
RRSIGs removal
----------------------------------------------------------------
Parent:
------------------------------------->
------------------------------------->
------------------------------------->
------------------------------------->
Child: SOA_5 RRSIG_Z_2(SOA)
子：SOA_5 RRSIG_Z_2（SOA）
DNSKEY_K_2
DNSKEY_K_2
DNSKEY_Z_2
DNSKEY_Z_2
RRSIG_K_2(DNSKEY)
----------------------------------------------------------------
Figure 13: RFC 5011 Style Algorithm Roll
図13：RFC 5011スタイルのアルゴリズムロール
Also see Section 4.1.4.2.
セクション4.1.4.2も参照してください。
----------------------------------------------------------------
initial new RRSIGs new DNSKEY
----------------------------------------------------------------
Parent:
SOA_0 -------------------------------------------------------->
RRSIG_par(SOA) ----------------------------------------------->
DS_S_1 ------------------------------------------------------->
RRSIG_par(DS_S_1) -------------------------------------------->
Child:
SOA_0 SOA_1 SOA_2
RRSIG_S_1(SOA)
RRSIG_Z_10(SOA) RRSIG_Z_10(SOA) RRSIG_Z_10(SOA)
RRSIG_S_2(SOA) RRSIG_S_2(SOA)
DNSKEY_S_1 DNSKEY_S_1 DNSKEY_S_1 DNSKEY_Z_10 DNSKEY_Z_10 DNSKEY_Z_10 DNSKEY_S_2 RRSIG_S_1(DNSKEY) RRSIG_S_1(DNSKEY) RRSIG_S_1(DNSKEY) RRSIG_S_2(DNSKEY) RRSIG_S_2(DNSKEY)
DNSKEY_S_1 DNSKEY_S_1 DNSKEY_S_1 DNSKEY_Z_10 DNSKEY_Z_10 DNSKEY_Z_10 DNSKEY_S_2 RRSIG_S_1（DNSKEY）RRSIG_S_1（DNSKEY）RRSIG_S_1（DNSKEY）RRSIG_S_2（DNSKEY）RRSIGSKS2
----------------------------------------------------------------
new DS revoke DNSKEY DNSKEY removal
----------------------------------------------------------------
Parent:
SOA_1 ------------------------------------------------------->
RRSIG_par(SOA) ---------------------------------------------->
DS_S_2 ------------------------------------------------------>
RRSIG_par(DS_S_2) ------------------------------------------->
Child:
-------------------> SOA_3 SOA_4
-------------------> RRSIG_Z_10(SOA)
-------------------> RRSIG_S_2(SOA) RRSIG_S_2(SOA)
-------------------> DNSKEY_S_1_REVOKED
-------------------> DNSKEY_Z_10
-------------------> DNSKEY_S_2 DNSKEY_S_2
-------------------> RRSIG_S_1(DNSKEY) RRSIG_S_1(DNSKEY)
-------------------> RRSIG_S_2(DNSKEY) RRSIG_S_2(DNSKEY)
----------------------------------------------------------------
RRSIGs removal
----------------------------------------------------------------
Parent:
------------------------------------->
------------------------------------->
------------------------------------->
------------------------------------->
Child: SOA_5
子：SOA_5
RRSIG_S_2(SOA)
RRSIG_S_2（SOA）
DNSKEY_S_2
DNSKEY_S_2
RRSIG_S_2(DNSKEY)
----------------------------------------------------------------
Figure 14: RFC 5011 Algorithm Roll in a Single-Type Signing Scheme Environment
図14：単一タイプの署名スキーム環境でのRFC 5011アルゴリズムロール
Also see Section 4.1.4.3.
セクション4.1.4.3も参照してください。
The figure in this Appendix complements and illustrates the special case of changing DNS operators as described in Section 4.3.5.1.
この付録の図は、セクション4.3.5.1で説明されているように、DNSオペレーターを変更する特殊なケースを補足して示しています。
------------------------------------------------------------
new DS | pre-publish |
------------------------------------------------------------
Parent:
NS_A NS_A
DS_A DS_B DS_A DS_B
------------------------------------------------------------
Child at A: Child at A: Child at B:
SOA_A0 SOA_A1 SOA_B0
RRSIG_Z_A(SOA) RRSIG_Z_A(SOA) RRSIG_Z_B(SOA)
NS_A NS_A NS_B RRSIG_Z_A(NS) NS_B RRSIG_Z_B(NS) RRSIG_Z_A(NS)
NS_A NS_A NS_B RRSIG_Z_A（NS）NS_B RRSIG_Z_B（NS）RRSIG_Z_A（NS）
DNSKEY_Z_A DNSKEY_Z_A DNSKEY_Z_A
DNSKEY_Z_B DNSKEY_Z_B
DNSKEY_K_A DNSKEY_K_A DNSKEY_K_B
RRSIG_K_A(DNSKEY) RRSIG_K_A(DNSKEY) RRSIG_K_A(DNSKEY)
RRSIG_K_B(DNSKEY) RRSIG_K_B(DNSKEY)
------------------------------------------------------------
------------------------------------------------------------
re-delegation | post-migration |
------------------------------------------------------------
Parent:
NS_B NS_B
DS_A DS_B DS_B
------------------------------------------------------------
Child at A: Child at B: Child at B:
SOA_A1 SOA_B0 SOA_B1 RRSIG_Z_A(SOA) RRSIG_Z_B(SOA) RRSIG_Z_B(SOA)
SOA_A1 SOA_B0 SOA_B1 RRSIG_Z_A（SOA）RRSIG_Z_B（SOA）RRSIG_Z_B（SOA）
NS_A NS_B NS_B NS_B RRSIG_Z_B(NS) RRSIG_Z_B(NS) RRSIG_Z_A(NS)
NS_A NS_B NS_B NS_B RRSIG_Z_B（NS）RRSIG_Z_B（NS）RRSIG_Z_A（NS）
DNSKEY_Z_A DNSKEY_Z_A
DNSKEY_Z_B DNSKEY_Z_B DNSKEY_Z_B
DNSKEY_K_A DNSKEY_K_B DNSKEY_K_B
RRSIG_K_A(DNSKEY) RRSIG_K_B(DNSKEY) RRSIG_K_B(DNSKEY)
------------------------------------------------------------
Figure 15: An Alternative Rollover Approach for Cooperating Operators
図15：協力するオペレーターのための代替ロールオーバーアプローチ
This document differs from RFC 4641 [RFC4641] in the following ways:
このドキュメントは、次の点でRFC 4641 [RFC4641]と異なります。
o Addressed the errata listed on <http://www.rfc-editor.org/errata_search.php?rfc=4641>.
o <http://www.rfc-editor.org/errata_search.php?rfc=4641>に記載されているエラッタに対処しました。
o Recommended RSA/SHA-256 in addition to RSA/SHA-1.
o RSA / SHA-1に加えて推奨されるRSA / SHA-256。
o Did a complete rewrite of Section 3.5 of RFC 4641 (Section 3.4.2 of this document), removing the table and suggesting a key size of 1024 for keys in use for less than 8 years, issued up to at least 2015.
o RFC 4641のセクション3.5（このドキュメントのセクション3.4.2）を完全に書き直し、テーブルを削除し、8年未満使用されているキーのキーサイズとして1024を提案し、少なくとも2015年まで発行しました。
o Removed the KSK for high-level zones consideration.
o 高レベルゾーンに関するKSKを削除しました。
o Added text on algorithm rollover.
o アルゴリズムのロールオーバーに関するテキストを追加しました。
o Added text on changing (non-cooperating) DNS registrars.
o （非協力）DNSレジストラの変更に関するテキストを追加しました。
o Did a significant rewrite of Section 3, whereby the argument is made that the timescales for rollovers are made purely on operational arguments.
o セクション3の大幅な書き換えを行いました。これにより、ロールオーバーのタイムスケールは純粋に操作上の引数に基づいて行われるという主張が行われました。
o Added Section 5.
o セクション5を追加。
o Introduced Single-Type Signing Scheme terminology and made the arguments for the choice of a Single-Type Signing Scheme more explicit.
o シングルタイプ署名スキームの用語が導入され、シングルタイプ署名スキームの選択に関する議論がより明確になりました。
o Added a section about stand-by keys.
o スタンバイキーに関するセクションを追加しました。
Authors' Addresses
著者のアドレス
Olaf M. Kolkman NLnet Labs Science Park 400 Amsterdam 1098 XH The Netherlands
オラフM.コルクマンNLnet Labsサイエンスパーク400アムステルダム1098 XHオランダ
EMail: olaf@nlnetlabs.nl
URI: http://www.nlnetlabs.nl
W. (Matthijs) Mekking NLnet Labs Science Park 400 Amsterdam 1098 XH The Netherlands
W.（Matthijs）Mekking NLnet Labs Science Park 400アムステルダム1098 XHオランダ
EMail: matthijs@nlnetlabs.nl
URI: http://www.nlnetlabs.nl
R. (Miek) Gieben SIDN Labs Meander 501 Arnhem 6825 MD The Netherlands
R.（Miek）Gieben SIDN Labs Meander 501 Arnhem 6825 MDオランダ
EMail: miek.gieben@sidn.nl
URI: http://www.sidn.nl