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