RFC4641 日本語訳
4641 DNSSEC Operational Practices. O. Kolkman, R. Gieben. September 2006. (Format: TXT=79894 bytes) (Obsoletes RFC2541) (Status: INFORMATIONAL)
プログラムでの自動翻訳です。
RFC一覧
英語原文
Network Working Group O. Kolkman Request for Comments: 4641 R. Gieben Obsoletes: 2541 NLnet Labs Category: Informational September 2006
Kolkmanがコメントのために要求するワーキンググループO.をネットワークでつないでください: 4641R.Giebenは以下を時代遅れにします。 2541年のNLnet研究室カテゴリ: 情報の2006年9月
DNSSEC Operational Practices
DNSSECの操作上の習慣
Status of This Memo
このメモの状態
This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited.
このメモはインターネットコミュニティのための情報を提供します。 それはどんな種類のインターネット標準も指定しません。 このメモの分配は無制限です。
Copyright Notice
版権情報
Copyright (C) The Internet Society (2006).
Copyright(C)インターネット協会(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を操作するために1セットの習慣について説明します。 対象者は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.
このドキュメントはRFC2541を時代遅れにします、主要なサイズと新しいDNSSEC仕様に関して、より操作上の地面をカバーしていて、より最新の要件を与えるとき。
Kolkman & Gieben Informational [Page 1] RFC 4641 DNSSEC Operational Practices September 2006
Kolkman&Giebenの情報[1ページ]のRFC4641のDNSSECの操作上の習慣2006年9月
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
1. 序論…3 1.1. '主要である'という用語の使用…4 1.2. 時間定義…4 2. 信頼のチェーンを完全に維持します…5 3. 重要世代とストレージ…6 3.1. ゾーンと主要な署名キー…6 3.1.1. KSKとZSK分離に関する動機…6 3.1.2. ハイレベルのゾーンへのKSKs…7 3.2. 重要世代…8 3.3. 主要な実効の期間…8 3.4. キーアルゴリズム…9 3.5. 主要なサイズ…9 3.6. 秘密鍵ストレージ…11 4. 署名世代、主要なロールオーバー、および関連方針…12 4.1. DNSSECの時間…12 4.1.1. 時間問題…12 4.2. キーロールオーバー…14 4.2.1. ゾーンの署名の主要なロールオーバー…14 4.2.1.1. 主要なロールオーバーをあらかじめ発行してください…15 4.2.1.2. 署名のゾーンの署名の主要なロールオーバーを倍にしてください…17 4.2.1.3. 体系の賛否両論…18 4.2.2. 主要な署名主要なロールオーバー…18 4.2.3. ZSKとKSKロールオーバーの違い…20 4.2.4. 自動化されたキーロールオーバー…21 4.3. 非常時の主要なロールオーバーの計画を立てます…21 4.3.1. KSKは妥協します…22 4.3.1.1. 信頼のチェーンを完全に維持します…22 4.3.1.2. 信頼のチェーンを壊します…23 4.3.2. ZSKは妥協します…23 4.3.3. キーの感染はレゾルバで投錨されました…24 4.4. 親の方針…24 4.4.1. 主要な交換と親の方針問題に頭文字をつけてください…24 4.4.2. キーかハッシュを保存しますか? ............................25 4.4.3. セキュリティの不完全さ…25 4.4.4. DS署名有効期間…26 5. セキュリティ問題…26 6. 承認…26 7. 参照…27 7.1. 標準の参照…27 7.2. 有益な参照…28 付録A.用語…30 付録のB.のゾーンの署名の主要なロールオーバーハウツーもの…31 付録のC.の印刷のコンベンション…32
Kolkman & Gieben Informational [Page 2] RFC 4641 DNSSEC Operational Practices September 2006
Kolkman&Giebenの情報[2ページ]のRFC4641のDNSSECの操作上の習慣2006年9月
1. Introduction
1. 序論
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 Security(DNSSEC)の可能にされた環境を実行する方法を説明します。 それがDNSに関する知識を持っているオペレータのために意図する、(RFC1034[1]とRFC1035[2])を見て、DNSSECを配布したいです。 プロトコルが変化するので、DNSSEC、新たに導入されたResource RecordsのためのRFC4034[5](RRs)、およびRFC4035[6]に序論のためのRFC4033[4]を見てください。
During workshops and early operational deployment tests, operators and system administrators have gained experience about operating the DNS with security extensions (DNSSEC). This document translates these experiences into a set of practices for zone administrators. At the time of writing, there exists very little experience with DNSSEC in production environments; this document should therefore explicitly not be seen as representing 'Best Current Practices'.
ワークショップと早めの操作上の展開テストの間、オペレータとシステム管理者はセキュリティ拡大(DNSSEC)と共にDNSを操作することに関して経験を積んでいます。 このドキュメントはゾーンの管理者のために1セットの習慣にこれらの経験を翻訳します。 これを書いている時点で、実稼動環境におけるDNSSECの経験はほとんど存在していません。 したがって、'最も良いCurrent Practices'を表すのを明らかにこのドキュメントを見るべきではありません。
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はキーの公共の部分に関して問題について説明します。 以来、これらの公開鍵は1つがセクション4.1で議論するすべての種類のタイミング問題を考慮に入れるために持っているDNSに現れます。 セクション4.2とセクション4.3はキーのロールオーバー、またはスーパー割譲に対処します。 最終的に、セクション4.4は両親が信頼のチェーンを維持するためにどう彼らの子供の公開鍵に対処するかに関する問題について議論します。
The typographic conventions used in this document are explained in Appendix C.
本書では使用される印刷のコンベンションはAppendix Cで説明されます。
Since this is a document with operational suggestions and there are no protocol specifications, the RFC 2119 [7] language does not apply.
これが操作上の提案があるドキュメントであり、プロトコル仕様が全くないので、RFC2119[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プロトコルの発展を反映するためにRFC2541[12]を時代遅れにします。 暗号アルゴリズムの選択における変化、DNSはタイプと型名を記録します、そして、親子キーと署名交換は主要な書き直し、追加情報、および説明を要求しました。
Kolkman & Gieben Informational [Page 3] RFC 4641 DNSSEC Operational Practices September 2006
Kolkman&Giebenの情報[3ページ]のRFC4641のDNSSECの操作上の習慣2006年9月
1.1. The Use of the Term 'key'
1.1. '主要である'という用語の使用
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 Resource Recordで発行されて、それが主要な交換に使用される公共の部分であることを理解していると思われます。
1.2. Time Definitions
1.2. 時間定義
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 署名(特定のキーで、作られている)が新しい署名(同じキーで、作られている)に取り替えられる「署名公表の期間」Time。 この交換は、マスターゾーンファイルで関連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 「最大の、または、最小のZone Time、」 Live(TTL)へのRRsの完全なセットからのTTLsのゾーンの最大か最小値。 最小のTTLがSOA RRのMINIMUM分野と同じでないことに注意してください。 詳しい情報のための[11]を見てください。
Kolkman & Gieben Informational [Page 4] RFC 4641 DNSSEC Operational Practices September 2006
Kolkman&Giebenの情報[4ページ]のRFC4641のDNSSECの操作上の習慣2006年9月
2. Keeping the Chain of Trust Intact
2. 信頼のチェーンを完全に維持します。
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.
信頼の壊れているチェーンが全体の(潜水艦)ドメインがクライアントについて確かめるのに目に見えなくなるかもしれないBogus([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を見てください。
Kolkman & Gieben Informational [Page 5] RFC 4641 DNSSEC Operational Practices September 2006
Kolkman&Giebenの情報[5ページ]のRFC4641のDNSSECの操作上の習慣2006年9月
3. Keys Generation and Storage
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.
このセクションはキーのセキュリティに関して多くの問題について説明します。 それは秘密鍵の世代、実効の期間、サイズ、およびストレージと取り引きします。
3.1. Zone and Key Signing Keys
3.1. ゾーンと主要な署名キー
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を使用できます。 実際には、オペレータは、操作の間、それらを見分けるのにKey SigningとZone Signingキーズを使用して、いわゆるSecure Entry Point(9月)[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.
ゾーン再契約と主要なロールオーバー手順を実装するのをより簡単にするように、Key Signingキーズ(KSKs)として1個以上のキーを使用するのは可能です。 これらのキーは、ゾーンで頂点がDNSKEY RRSetであると署名するだけでしょう。 他のキーは、ゾーンですべてのRRSetsに署名するのに使用できて、Zone Signingキーズ(ZSKs)と呼ばれます。 本書では、私たちは、KSKsが信じられたアンカーとして構成のための主要な交換に親と共に潜在的に使用されるキーの部分集合であると思います--9月のキー。 本書では、私たちはKSKと9月のキーの間の1〜1つのマッピングを思います、そして、9月の旗がすべてのKSKsに設定されると思います。
3.1.1. Motivations for the KSK and ZSK Separation
3.1.1. KSKとZSK分離に関する動機
Differentiating between the KSK and ZSK functions has several advantages:
KSKとZSK機能を区別するのにおいて、いくつかの利点があります:
o No parent/child interaction is required when ZSKs are updated.
o ZSKsをアップデートするとき、親/子供相互作用を全く必要としません。
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は、ゾーンの他のどんなRRSetsのためにもゾーンの主要なセットについて確かめないように使用されるだけです。
o As the KSK is only used to sign a key set, which is most probably
updated less frequently than other data in the zone, it can be
stored separately from and in a safer location than the ZSK.
o KSKが最もたぶんゾーンで他のデータほど頻繁でなくアップデートされる主要なセットに署名するのに使用されるだけであるとき、別々に位置とZSKより安全な位置にそれを保存できます。
o A KSK can have a longer key effectivity period.
o KSKは、より長い主要な実効の期間を過すことができます。
For almost any method of key management and zone signing, the KSK is used less frequently than the ZSK. Once a key set is signed with the KSK, all the keys in the key set can be used as ZSKs. If a ZSK is
かぎ管理とゾーン署名のほとんどどんなメソッドのためにも、KSKはZSKよりどんな頻繁にも使用されません。 主要なセットがいったんKSKを契約されると、ZSKsとして主要なセットにおけるすべてのキーを使用できます。 ZSKがそうなら
Kolkman & Gieben Informational [Page 6] RFC 4641 DNSSEC Operational Practices September 2006
Kolkman&Giebenの情報[6ページ]のRFC4641のDNSSECの操作上の習慣2006年9月
compromised, it can be simply dropped from the key set. The new key set is then re-signed with the KSK.
感染されて、主要なセットからそれを単に下げることができます。 そして、新しい主要なセットは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月の旗が設定されるという仮定を考えて、ZSKとDNSKEY RRの旗の分野を調べることによって、KSKを区別できます。 旗の分野が奇数であるなら、それは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.
ゾーンで定期的にすべてのデータに署名するのにZone Signing Keyを使用できます。 Zone Signing Keyが回転することになっているとき、親との相互作用は全く必要ではありません。 これは何日もの注文ときに署名の正当性のために期間を許容します。
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.
Key Signing Keyは、ゾーンでDNSKEY RRsに署名するのに単に使用されることになっています。 Key Signing Keyがひっくり返るつもりであると、ゾーンの管理者以外のパーティーとの相互作用があるでしょう。 これらが親ゾーンの登録を含むことができますか、または安全なエントリーが指すので、レゾルバのためにそれについて確かめる管理者は特定のキーを構成させます。 したがって、これらのキーの主要な実効の期間をすることができて、はるかに長くするべきです。 十分長いキーを考えて、何年もの注文には主要な実効の期間があることができますが、私たちが、数カ月の注文ときに主要な実効の計画を立てることを提案するので、主要なロールオーバーは操作上のルーチンのままで残っています。
3.1.2. KSKs for High-Level Zones
3.1.2. ハイレベルのゾーンへのKSKs
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データのアクセスと認証のためにルートサーバーで始めるでしょう。 世界中のレゾルバの莫大な人口でしっかりと信頼アンカーをアップデートするのは非常に難しくなるでしょう。
Kolkman & Gieben Informational [Page 7] RFC 4641 DNSSEC Operational Practices September 2006
Kolkman&Giebenの情報[7ページ]のRFC4641のDNSSECの操作上の習慣2006年9月
3.2. Key Generation
3.2. キー生成
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.
すべてのキーの慎重な世代はいずれの時々見落とされましたが、絶対に不可欠の要素が暗号でシステムを固定するということです。 敵がそれを徹底的に捜すことができるようにありそうな主要なスペースのサイズを下げることができるくらい推測できるなら、最も長いキーと共に使用される中で最も強いアルゴリズムはまだ無駄です。 ランダムキーの世代単位で技術的な提案はRFC4086[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.
長い実効の期間があるキーは、より貴重な目標を表して、短期より長い時間の攻撃を条件としてキーになるので、特に敏感です。 長期のキー生成がエアギャップか最小限におけるハイレベルの安定したハードウェアを通してネットワークから孤立している方法でオフラインで起こることが強く勧められます。
3.3. Key Effectivity Period
3.3. 主要な実効の期間
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.
純粋に操作上の見解から、妥当なKey Signingキーズに、主要な実効の期間は13カ月です、12カ月後にそれらに取って代わる意図をもって。 Zone Signingキーズに、1カ月の意図している主要な実効の期間は妥当です。
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.
数分のように非常に急に主要な実効の期間を作ることができます。 しかし、キーを取り替えるとき、1つはセクション4.1とセクション4.2からアカウントに問題を取らなければなりません。
Kolkman & Gieben Informational [Page 8] RFC 4641 DNSSEC Operational Practices September 2006
Kolkman&Giebenの情報[8ページ]のRFC4641のDNSSECの操作上の習慣2006年9月
3.4. Key Algorithm
3.4. 主要なアルゴリズム
There are currently three different types of algorithms that can be used in DNSSEC: RSA, DSA, and elliptic curve cryptography. The latter is fairly new and has yet to be standardized for usage in DNSSEC.
現在、DNSSECで使用できる3つの異なったタイプのアルゴリズムがあります: RSA、DSA、および楕円曲線暗号。 後者は、かなり新しくなく、またDNSSECの用法のためにまだ標準化されていません。
RSA has been developed in an open and transparent manner. As the patent on RSA expired in 2000, its use is now also free.
RSAは開いていて見え透いた方法で開発されました。 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のようにおよそ同時間がかかりますが、検証[17]には、10〜40倍遅いです。
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ハッシュには暗号文解読術問題があるのが知られています。 これらの問題を扱うときの進行中の仕事があります。 私たちはSHA-1(例えば、SHA-256)より強いハッシュに基づく公開鍵アルゴリズムの使用を推薦します、これらのアルゴリズムがプロトコル仕様で利用可能であるとすぐに。([19]、[20])、および実装を見てください。
3.5. Key Sizes
3.5. 主要なサイズ
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であって親の主要なサイズが任意にどれくらい大きいか考えてください。 その時、チェーンでキーに何度か加わることにおけるそれほど多くないより大きい感覚が、信頼のチェーンが本当に「チェーン」であるので、あります。他のもの。 いつものように、それは全体のチェーンの勢力を定義する最も弱いリンクです。 また、異なる役割(ZSK対KSK)を受けるキーがどう異なった主要なサイズを必要とするかもしれないかに関する議論に関してセクション3.1.1を見てください。
Generating a key of the correct size is a difficult problem; RFC 3766 [13] tries to deal with that problem. The first part of the selection procedure in Section 1 of the RFC states:
適度のサイズのキーを生成するのは、難問です。 RFC3766[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
1. アプリケーションのセキュリティ要件を満たすのに必要な攻撃抵抗を決定してください。 攻撃者が妥協するためにやむを得ずするコンピュータ操作の最小の数を見積もっていることによって、これをしてください。
Kolkman & Gieben Informational [Page 9] RFC 4641 DNSSEC Operational Practices September 2006
Kolkman&Giebenの情報[9ページ]のRFC4641のDNSSECの操作上の習慣2006年9月
security of the system and then take the logarithm base two of
that number. Call that logarithm value "n".
システムとその時のセキュリティはその数の対数ベースtwoを取ります。 対数値「n」にそれに電話をしてください。
A 1996 report recommended 90 bits as a good all-around choice
for system security. The 90 bit number should be increased by
about 2/3 bit/year, or about 96 bits in 2005.
1996年のレポートはシステムセキュリティのための良い統合的な選択として90ビットを推薦しました。 90ビットの数は2005年におよそ2/3ビット/年、またはおよそ96ビットによって増強されるべきです。
[13] goes on to explain how this number "n" can be used to calculate the key sizes in public key cryptography. This culminated in the table given below (slightly modified for our purpose):
[13]は、公開鍵暗号の主要なサイズについて計算するのにどうこの数「n」を使用できるかを説明し続けます。 これは以下(私たちの目的のためにわずかに変更される)に与えられたテーブルに終わりました:
+-------------+-----------+--------------+
| System | | |
| requirement | Symmetric | RSA or DSA |
| for attack | key size | modulus size |
| resistance | (bits) | (bits) |
| (bits) | | |
+-------------+-----------+--------------+
| 70 | 70 | 947 |
| 80 | 80 | 1228 |
| 90 | 90 | 1553 |
| 100 | 100 | 1926 |
| 150 | 150 | 4575 |
| 200 | 200 | 8719 |
| 250 | 250 | 14596 |
+-------------+-----------+--------------+
+-------------+-----------+--------------+ | システム| | | | 要件| 左右対称| RSAかDSA| | 攻撃のために| 主要なサイズ| 係数サイズ| | 抵抗| (ビット) | (ビット) | | (ビット) | | | +-------------+-----------+--------------+ | 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.
与えられた主要なサイズはかなり大きいです。 これはこれらのキーがtrillionaire攻撃者に対して弾力があるからです。 この金持ちの攻撃者があなたのキーを攻撃しないで、キーが1年に一度ひっくり返ると仮定して、私たちは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.
ドメインには低いか、中型の、または、高い価値があるかは唯一ゾーン所有者の視点によります。 例えば、人は低値、および最上位のドメイン(TLDs)現在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が、より容易に(その結果、よりしばしば)ひっくり返ることができるように、主要なサイズをより小さくすることができます。 しかし、このパラグラフの導入で言われているように、ZSKsの主要なサイズを小さく(KSKsのサイズと関連した)し過ぎるのはあまり理解できません。 サイズの違いをおよそ100ビットに制限するようにしてください。
Kolkman & Gieben Informational [Page 10] RFC 4641 DNSSEC Operational Practices September 2006
Kolkman&Giebenの情報[10ページ]のRFC4641のDNSSECの操作上の習慣2006年9月
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.
だれも未来を調べることができないで、これらの主要なサイズがガイドとしてここに提供されるだけであることに注意してください。 [17]の[16]とセクション7.5で詳細を見つけることができます。 その[16]はどんな主要なサイズが安全であると考えられるかに関してひどく楽観的であると既に考えられますが、それは注意されるべきです。
One final note concerning key sizes. Larger keys will increase the sizes of the RRSIG and DNSKEY records and will therefore increase the chance of DNS UDP packet overflow. Also, the time it takes to validate and create RRSIGs increases with larger keys, so don't needlessly double your key sizes.
主要なサイズに関する1つの最後通達。 より大きいキーは、RRSIGとDNSKEY記録のサイズを増強して、したがって、DNS UDPパケットオーバーフローの可能性を増強するでしょう。 また、RRSIGsを有効にして、それが作成するわざわざが、より大きいキーで増加するので、不必要に主要なサイズを倍にしないでください。
3.6. Private Key Storage
3.6. 秘密鍵ストレージ
It is recommended that, where possible, zone private keys and the zone file master copy that is to be signed be kept and used in off- line, non-network-connected, physically secure machines only. Periodically, an application can be run to add authentication to a zone by adding RRSIG and NSEC RRs. Then the augmented file can be transferred.
可能であるところのゾーン秘密鍵と署名されることになっているゾーンファイルマスター写しがオフ系列、非ネットワークが接続していて、肉体的に安全なマシンだけで取っておかれて、使用されるのは、お勧めです。 定期的に、RRSIGとNSEC RRsを加えることによって認証をゾーンに追加するためにアプリケーションを実行されることができます。 そして、増大しているファイルを移すことができます。
When relying on dynamic update to manage a signed zone [10], be aware that at least one private key of the zone will have to reside on the master server. This key is only as secure as the amount of exposure the server receives to unknown clients and the security of the host. Although not mandatory, one could administer the DNS in the following way. The master that processes the dynamic updates is unavailable from generic hosts on the Internet, it is not listed in the NS RR set, although its name appears in the SOA RRs MNAME field. The nameservers in the NS RRSet are able to receive zone updates through NOTIFY, IXFR, AXFR, or an out-of-band distribution mechanism. This approach is known as the "hidden master" setup.
署名しているゾーン[10]を管理するためにダイナミックなアップデートに依存するときには、ゾーンの少なくとも1つの秘密鍵がマスターサーバになければならないのを意識してください。このキーはサーバが未知のクライアントに受け取る暴露量と単にホストのセキュリティと同じくらい安全です。 義務的ではありませんが、人は以下の方法でDNSを管理できました。 ダイナミックなアップデートを処理するマスターがインターネットでジェネリックホストから入手できません、それはNS RRセットで記載されていません、名前がSOA RRs MNAME分野に現れますが。 NS RRSetのネームサーバはNOTIFY、IXFR、AXFR、またはバンドで出ている分配メカニズムを通してゾーンアップデートを受けることができます。 このアプローチは「隠されたマスター」セットアップとして知られています。
The ideal situation is to have a one-way information flow to the network to avoid the possibility of tampering from the network. Keeping the zone master file on-line on the network and simply cycling it through an off-line signer does not do this. The on-line version could still be tampered with if the host it resides on is compromised. For maximum security, the master copy of the zone file should be off-net and should not be updated based on an unsecured network mediated communication.
理想的な状況は一方向情報にネットワークからいじる可能性を避けるためにネットワークに注がせることです。 ネットワークでゾーン基本ファイルをオンラインに保って、オフライン署名者を通してそれを単に循環させる場合、これはしません。 それが住んでいるホストが感染されるなら、オンラインバージョンはまだいじられているかもしれません。 最大のセキュリティのために、ゾーンファイルのマスターコピーをオフネットであるべきであり、非機密保護しているネットワーク調停されたコミュニケーションに基づいてアップデートするべきではありません。
In general, keeping a zone file off-line will not be practical and the machines on which zone files are maintained will be connected to a network. Operators are advised to take security measures to shield unauthorized access to the master copy.
一般に、ゾーンファイルをオフラインに保つのは実用的でないでしょう、そして、ゾーンファイルが保守されるマシンはネットワークに接続されるでしょう。 オペレータがマスターコピーへの不正アクセスを保護するために安全策を取るようにアドバイスされます。
Kolkman & Gieben Informational [Page 11] RFC 4641 DNSSEC Operational Practices September 2006
Kolkman&Giebenの情報[11ページ]のRFC4641のDNSSECの操作上の習慣2006年9月
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]に、マスターコピーとアップデートされたRRsで署名をアップデートするのに使用される秘密鍵の両方が、オンラインである必要があるでしょう。
4. Signature Generation, Key Rollover, and Related Policies
4. 署名世代、主要なロールオーバー、および関連方針
4.1. Time in DNSSEC
4.1. DNSSECの時間
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分野のREFRESH、RETRY、およびEXPIRATIONは奴隷サーバがマスターサーバと同期した後に経過時間を決定するのに使用されるタイマです。Live(TTL)値とSOA RRの最小のTTLパラメタ[11]へのTimeは、正式のサーバからそれをとって来てある後にどれくらい長い混載業者がデータをキャッシュするべきであるかを決定するのに使用されます。署名有効期間を費やすことによって、DNSSECはDNSで絶対時間の概念を紹介します。 DNSSECの署名には、署名が無効であるとマークされて、Bogusであると考えられた署名しているデータがことであった後有効期限があります。
4.1.1. Time Considerations
4.1.1. 時間問題
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 私たちは、あなたのゾーンデータのMaximum Zone TTLがあなたの署名有効期間の部分であると示唆します。
If the TTL would be of similar order as the signature validity
period, then all RRSets fetched during the validity period
would be cached until the signature expiration time. Section
7.1 of [4] suggests that "the resolver may use the time
remaining before expiration of the signature validity period of
a signed RRSet as an upper bound for the TTL". As a result,
query load on authoritative servers would peak at signature
expiration time, as this is also the time at which records
simultaneously expire from caches.
TTLが署名有効期間として同様のオーダーのものであるなら、有効期間の間にとって来られたすべてのRRSetsが署名満了時間までキャッシュされるでしょう。 「レゾルバは署名しているRRSetの署名有効期間の満了の前にTTLのための上限として残りながら、時間を費やすかもしれません。」と、[4]のセクション7.1は示します。 その結果、正式のサーバに関する質問負荷は署名満了時間にピークに達するでしょう、また、これが記録が同時にキャッシュから期限が切れる時であるので。
To avoid query load peaks, we suggest the TTL on all the RRs in
your zone to be at least a few times smaller than your
signature validity period.
質問負荷ピークを避けるために、私たちは、あなたのゾーンのすべてのRRsの上のTTLがあなたの署名有効期間より少なくとも数倍小さいと示唆します。
o We suggest the signature publication period to end at least one
Maximum Zone TTL duration before the end of the signature validity
period.
o 私たちは、署名有効期間の終わりまでに少なくとも1Maximum Zone TTLの持続時間を終わらせるために署名公表の期間を勧めます。
Kolkman & Gieben Informational [Page 12] RFC 4641 DNSSEC Operational Practices September 2006
Kolkman&Giebenの情報[12ページ]のRFC4641のDNSSECの操作上の習慣2006年9月
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 私たちは、Minimum Zone TTLが信頼チェーンでともにすべてのRRsをとって来て、確かめることができるくらい長いと示唆します。 ワークショップ環境で、[18] 低いTTL(5〜10分の下における)が以下の2つの問題のために分裂を引き起こしたのが示されました:
1. During validation, some data may expire before the
validation is complete. The validator should be able to
keep all data until it is completed. This applies to all
RRs needed to complete the chain of trust: DSes, DNSKEYs,
RRSIGs, and the final answers, i.e., the RRSet that is
returned for the initial query.
1. 合法化の間、合法化が完全になる前にいくつかのデータが期限が切れるかもしれません。 validatorは完成するまですべてのデータを保つはずであることができます。 これは信頼のチェーンを完成するのに必要であるすべてのRRsに適用されます: DSes、DNSKEYs、RRSIGs、および最終的な答え、すなわち、初期の質問のために返されるRRSet。
2. Frequent verification causes load on recursive nameservers.
Data at delegation points, DSes, DNSKEYs, and RRSIGs
benefit from caching. The TTL on those should be
relatively long.
2. 頻繁な検証原因は再帰的なネームサーバでロードされます。 委譲ポイント、DSes、DNSKEYs、および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.
o 奴隷サーバは、奴隷サーバによって役立たれるゾーンのRRSIGsが彼らの署名満了時間を過ぎる前に上手に新たに署名しているゾーンをとって来ることができる必要があるでしょう。
When a slave server is out of sync with its master and data in
a zone is signed by expired signatures, it may be better for
the slave server not to give out any answer.
奴隷サーバがマスターと同期していて、満期の署名でゾーンのデータが署名されるとき、奴隷サーバはどんな答えも配らないほうがよいかもしれません。
Normally, a slave server that is not able to contact a master
server for an extended period will expire a zone. When that
happens, the server will respond differently to queries for
that zone. Some servers issue SERVFAIL, whereas others turn
off the 'AA' bit in the answers. The time of expiration is set
in the SOA record and is relative to the last successful
refresh between the master and the slave servers. There exists
no coupling between the signature expiration of RRSIGs in the
zone and the expire parameter in the SOA.
通常、長期間の間にマスターサーバに連絡できない奴隷サーバはゾーンを吐き出すでしょう。 それが起こると、サーバはそのゾーンのための質問に異なって反応するでしょう。 いくつかのサーバがSERVFAILを発行しますが、他のものは答えで'AA'ビットをオフにします。 最終に比例して、満了の時間は、SOAに記録を設定することであり、うまくいっています。マスターと奴隷サーバの間でリフレッシュしてください。 そして、間にゾーンでの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
サーバがDNSSECゾーンに役立つなら、SOA満了タイマがゼロまで数えられる前に署名がよく期限が切れるのはたぶん起こるでしょう。 これがSOAパラメタをひねりながら偶然通りかかるのを完全に防ぐのは可能ではありません。 しかしながら、SOA満了時間が署名有効期間より等しいか、または短いところで効果を最小にすることができます。 アップデートするできない正式のサーバの結果
Kolkman & Gieben Informational [Page 13] RFC 4641 DNSSEC Operational Practices September 2006
Kolkman&Giebenの情報[13ページ]のRFC4641のDNSSECの操作上の習慣2006年9月
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.
そのゾーンは満期の署名を含んでいますが、ゾーンは非安全なレゾルバがずっとセキュリティ意識しているレゾルバがBogusとしてマークされる答えのために問題を経験しますが、特定の奴隷サーバによって役立たれるデータを決議できるということです。
We suggest the SOA expiration timer being approximately one
third or one fourth of the signature validity period. It will
allow problems with transfers from the master server to be
noticed before the actual signature times out. We also suggest
that operators of nameservers that supply secondary services
develop 'watch dogs' to spot upcoming signature expirations in
zones they slave, and take appropriate action.
私たちは署名有効期間のSOA満了タイマ存在およそonethirdかonefourthを勧めます。 それは実際の署名時間の前に気付かれるべきマスターサーバからの外の転送に関する問題を許容するでしょう。 また、私たちは、ゾーンでそれらが身を粉にして働いて、適切な行動を取ることを供給のセカンダリサービスが開発するネームサーバのオペレータが染みになるように'犬を見る'というその今度の署名満期に提案します。
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特有ではありませんが、あなたの署名正当性間隔の選択に影響を及ぼすかもしれません。
4.2. Key Rollovers
4.2. 主要なロールオーバー
A DNSSEC key cannot be used forever (see Section 3.3). So key rollovers -- or supercessions, as they are sometimes called -- are a fact of life when using DNSSEC. Zone administrators who are in the process of rolling their keys have to take into account that data published in previous versions of their zone still lives in caches. When deploying DNSSEC, this becomes an important consideration; ignoring data that may be in caches may lead to loss of service for clients.
いつまでも、DNSSECキーを使用できません(セクション3.3を見てください)。 呼ばれて、時々彼らがそうであることのように--主要なロールオーバー、またはスーパー割譲によって、現実はいつ使用DNSSECですか? 彼らのキーを回転させることの途中にいるゾーンの管理者は、それらのゾーンの旧バージョンで発表されたデータがキャッシュにまだ生きているのを考慮に入れなければなりません。 DNSSECを配布するとき、これは重要な考慮すべき事柄になります。 キャッシュにはあるかもしれないデータを無視すると、クライアントのためのサービスの損失は出されるかもしれません。
The most pressing example of this occurs when zone material signed with an old key is being validated by a resolver that does not have the old zone key cached. If the old key is no longer present in the current zone, this validation fails, marking the data "Bogus". Alternatively, an attempt could be made to validate data that is signed with a new key against an old key that lives in a local cache, also resulting in data being marked "Bogus".
古いキーで署名されたゾーンの材料が古いゾーンキーをキャッシュしないレゾルバによって有効にされているとき、この最も緊急の例は現れます。 古いキーがもう現在のゾーンに存在していないなら、データが「にせである」とマークして、この合法化は失敗します。 あるいはまた、ローカルなキャッシュに生きる古いキーに対して新しいキーで署名されるデータを有効にするのを試みをすることができました、また、「にせである」とマークされるデータをもたらして。
4.2.1. Zone Signing Key Rollovers
4.2.1. ゾーンの署名の主要なロールオーバー
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
「ゾーンSigning Keyロールオーバー」のために、確実にするまだキャッシュされていたロールオーバーデータの間に新しい主要なセットで確かめることができる2つの方法があるか、またはキーでまだキャッシュで新たに生成している署名について確かめることができます。 1つの図式、セクション4.2.1では、.2、用途について説明します。
Kolkman & Gieben Informational [Page 14] RFC 4641 DNSSEC Operational Practices September 2006
Kolkman&Giebenの情報[14ページ]のRFC4641のDNSSECの操作上の習慣2006年9月
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に説明されます。
4.2.1.1. Pre-Publish Key Rollover
4.2.1.1. 主要なロールオーバーをあらかじめ発行してください。
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ロールオーバーがあるケースのように。Appendix 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)
---------------------------------------------------------------- 初期の新しいDNSKEY新しいRRSIGs DNSKEY取り外し---------------------------------------------------------------- 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)
----------------------------------------------------------------
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.
頭文字をつけます: ゾーンのバージョンに頭文字をつけてください: DNSKEY1はKey Signing Keyです。 DNSKEY10は、ゾーン、Zone Signing Keyに関するすべてのデータに署名するのに使用されます。
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: DNSKEY11は主要なセットに取り入れられます。 署名が全くこのキーでまだ生成されていませんが、これが公開鍵でブルートフォースアタックに対して安全でなくすることに注意してください。 このプレロールフェーズの最小の持続時間はデータが正式のサーバに伝播されるにはかかって、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
新しいRRSIGs: 「新しいRRSIGs」段階(SOAの連続の2)では、DNSKEY11は、ゾーンで排他的にデータに署名するのに使用されます(ゾーンからDNSKEY10からのすなわち、すべての署名を取り除きます)。 DNSKEY10は主要なセットで発行されたままで残っています。 この道、ロードされたデータ
Kolkman & Gieben Informational [Page 15] RFC 4641 DNSSEC Operational Practices September 2006
Kolkman&Giebenの情報[15ページ]のRFC4641のDNSSECの操作上の習慣2006年9月
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.
バージョンからのキャッシュに、主要なセットがゾーンのバージョン2からとって来られている状態で、まだゾーンの1つについて確かめることができます。 DNSKEY10を含む主要なセットが発行されることになっている最小の時間は古いキャッシュから吐き出すゾーンの旧バージョンからゾーンデータに取る時間です、すなわち、このゾーンがすべての正式のサーバに伝播されるにはかかって、Maximum Zone 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取り外し: DNSKEY10はゾーンから取り外されます。 現在DNSKEY1とDNSKEY11を含むだけであって、主要なセットはDNSKEY1と共に再契約されます。
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つのロールオーバーを示しています)。 将来のキーはDNSKEY12と再びより新しいものとしての「新しいDNSKEY」、番号付の13で紹介されます、「新しいDNSKEY(II)」で:
----------------------------------------------------------------
initial new RRSIGs new DNSKEY
----------------------------------------------------------------
SOA0 SOA1 SOA2
RRSIG10(SOA0) RRSIG11(SOA1) RRSIG11(SOA2)
---------------------------------------------------------------- 初期の新しいRRSIGs新しい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)
----------------------------------------------------------------
DNSKEY1 DNSKEY1 DNSKEY1 DNSKEY10 DNSKEY10DNSKEY11 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)
---------------------------------------------------------------- 新しいRRSIGs(II)の新しいDNSKEY(II)---------------------------------------------------------------- SOA3 SOA4 RRSIG12(SOA3)RRSIG12(SOA4)
DNSKEY1 DNSKEY1
DNSKEY11 DNSKEY12
DNSKEY12 DNSKEY13
RRSIG1(DNSKEY) RRSIG1(DNSKEY)
RRSIG12(DNSKEY) RRSIG12(DNSKEY)
----------------------------------------------------------------
DNSKEY1 DNSKEY1 DNSKEY11 DNSKEY12 DNSKEY12 DNSKEY13 RRSIG1(DNSKEY)RRSIG1(DNSKEY)RRSIG12(DNSKEY)RRSIG12(DNSKEY)----------------------------------------------------------------
Pre-Publish Key Rollover, Showing Two Rollovers
2つのロールオーバーを示して、主要なロールオーバーをあらかじめ発行してください。
Kolkman & Gieben Informational [Page 16] RFC 4641 DNSSEC Operational Practices September 2006
Kolkman&Giebenの情報[16ページ]のRFC4641のDNSSECの操作上の習慣2006年9月
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」フェーズで紹介されたキーが生産にまだ使用されていないことに注意してください。 秘密鍵はその結果、肉体的に安全な方法で保存できて、ゾーンが、署名される必要があるときはいつも、'とって来られる必要はありません'。
4.2.1.2. Double Signature Zone Signing Key Rollover
4.2.1.2. 二重署名ゾーン署名主要なロールオーバー
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」ステージの間、ゾーンファイルの新しいバージョンは、すべての正式のサーバに伝播する必要があるでしょう、そして、(遠方)のキャッシュで存在するデータは期限が切れる必要があるでしょう、少なくともMaximum Zone TTLを必要として。
Double signature ZSK rollover involves three stages as follows:
二重署名ZSKロールオーバーは以下の3つのステージにかかわります:
----------------------------------------------------------------
initial new DNSKEY DNSKEY removal
----------------------------------------------------------------
SOA0 SOA1 SOA2
RRSIG10(SOA0) RRSIG10(SOA1) RRSIG11(SOA2)
RRSIG11(SOA1)
---------------------------------------------------------------- 初期の新しいDNSKEY DNSKEY取り外し---------------------------------------------------------------- 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)
----------------------------------------------------------------
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.
頭文字をつけます: ゾーンのバージョンに頭文字をつけてください: DNSKEY1はKey Signing Keyです。 DNSKEY10は、ゾーン、Zone Signing Keyに関するすべてのデータに署名するのに使用されます。
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)では、DNSKEY11は主要なセットに取り入れられます、そして、ゾーンのすべてのデータがDNSKEY10とDNSKEY11を契約されます。 ロールオーバーの期間は、ゾーンのバージョン0からのデータがリモートキャッシュから吐き出したすべてまで続く必要があるでしょう。 これは少なくともゾーンのバージョン0のMaximum Zone 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取り外し: DNSKEY10はゾーンから取り外されます。 ゾーンからDNSKEY10からのすべての署名を取り除きます。 現在DNSKEY11を含むだけであって、主要なセットはDNSKEY1と共に再契約されます。
Kolkman & Gieben Informational [Page 17] RFC 4641 DNSSEC Operational Practices September 2006
Kolkman&Giebenの情報[17ページ]のRFC4641のDNSSECの操作上の習慣2006年9月
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.
あらゆるインスタンスでは、DNSKEY RRSetと共に最新版と他のおよそ道からゾーンの旧バージョンからのRRSIGsについて確かめることができます。 ゾーンの旧バージョンからのデータで最新版からのデータについて確かめることができます。 「新しいDNSKEY」フェーズとロールオーバーの間の期間の持続時間は少なくともMaximum Zone 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」フェーズがゾーンの初期のバージョンのデータの署名満了時間を続けるのを確実にするのはお勧めです。 このように、すべてのキャッシュは古い署名をクリアされます。 しかしながら、ロールオーバーを長い手順にして、この持続時間はMaximum Zone 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.
この例では、私たちが、ゾーンがロールオーバーの間変更されなかったと思ったことに注意してください。それが両方のキーで署名される限り、ゾーンで新しいデータは紹介できます。
4.2.1.3. Pros and Cons of the Schemes
4.2.1.3. 体系の賛否両論
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ステップを必要とするということです。 また、KSKロールオーバーにセクション4.2.3で説明されるように使用されると、あらかじめ発行している体系は、より多くの親の仕事にかかわります。
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ステップしか必要としないということです。
4.2.2. Key Signing Key Rollovers
4.2.2. 主要な署名主要なロールオーバー
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.
Key Signing Keyのロールオーバーのために、Zone Signing Keyのロールオーバーのような同じ問題は申し込まれます。 しかしながら、私たちは、新しい主要なセットで逆もまた同様に、キャッシュにおける古いデータ(頂点の主要なセットだけ)について確かめることができるのを保証するのに二重署名計画を使用できます。 主要なセットだけがKSKを契約されるので、ゾーンサイズ問題は適用されません。
Kolkman & Gieben Informational [Page 18] RFC 4641 DNSSEC Operational Practices September 2006
Kolkman&Giebenの情報[18ページ]のRFC4641のDNSSECの操作上の習慣2006年9月
--------------------------------------------------------------------
initial new DNSKEY DS change DNSKEY removal
--------------------------------------------------------------------
Parent:
SOA0 --------> SOA1 -------->
RRSIGpar(SOA0) --------> RRSIGpar(SOA1) -------->
DS1 --------> DS2 -------->
RRSIGpar(DS) --------> RRSIGpar(DS) -------->
-------------------------------------------------------------------- 初期の新しいDNSKEY DS変化DNSKEY取り外し-------------------------------------------------------------------- 親: 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)
--------------------------------------------------------------------
子供: SOA0 SOA1-------->SOA2 RRSIG10(SOA0)RRSIG10(SOA1)-------->RRSIG10(SOA2)-------->DNSKEY1 DNSKEY1-------->DNSKEY2 DNSKEY2-------->DNSKEY10 DNSKEY10-------->DNSKEY10 RRSIG1(DNSKEY)RRSIG1(DNSKEY)-------->RRSIG2(DNSKEY)RRSIG2(DNSKEY)-------->RRSIG10(DNSKEY)RRSIG10(DNSKEY)-------->RRSIG10(DNSKEY)--------------------------------------------------------------------
Stages of Deployment for a Double Signature Key Signing Key Rollover
二重署名主要な調印主要なロールオーバーのための展開のステージ
initial: Initial version of the zone. The parental DS points to
DNSKEY1. Before the rollover starts, the child will have to
verify what the TTL is of the DS RR that points to DNSKEY1 -- it
is needed during the rollover and we refer to the value as TTL_DS.
頭文字をつけます: ゾーンのバージョンに頭文字をつけてください。 親のDSはDNSKEY1を示します。 ロールオーバーが始まる前に、子供は、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」段階の間、ゾーンの管理者は第2のKSK、DNSKEY2を発生させます。 キーを親に提供します、そして、DNSKEY2を示す新しいDS RRが発生するまで、子供は待たなければならないでしょう。 そのDS RRが発行された後に、親のゾーン、ゾーンの管理者にとって、正式のすべてのサーバでは、確実にする少なくとも古いDS RRがキャッシュから吐き出したTTL_DSは待っていなければなりません。
DS change: The parent replaces DS1 with DS2.
DSは変化します: 親はDS1をDS2に取り替えます。
DNSKEY removal: DNSKEY1 has been removed.
DNSKEY取り外し: DNSKEY1は取り外されました。
The scenario above puts the responsibility for maintaining a valid chain of trust with the child. It also is based on the premise that the parent only has one DS RR (per algorithm) per zone. An alternative mechanism has been considered. Using an established trust relation, the interaction can be performed in-band, and the removal of the keys by the child can possibly be signaled by the parent. In this mechanism, there are periods where there are two DS
上のシナリオは子供と共に信用の有効なチェーンを維持することへの責任を置きます。 また、それは基づいています、そして、親はゾーン単位で1DS RRしか持っていません(アルゴリズム単位で)。 代替のメカニズムは考えられました。 確立した信用関係を使用して、バンドで相互作用を実行できます、そして、親は子供によるキーの取り外しに合図できます。 このメカニズムには、期間が2DSがあるところにあります。
Kolkman & Gieben Informational [Page 19] RFC 4641 DNSSEC Operational Practices September 2006
Kolkman&Giebenの情報[19ページ]のRFC4641のDNSSECの操作上の習慣2006年9月
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.
親のRRs。 この相互作用のためのこの文を書いているときにプロトコルが開発されていないので、このドキュメントのための範囲の外にさらなる議論があります。
4.2.3. Difference Between ZSK and KSK Rollovers
4.2.3. ZSKとKSKロールオーバーの違い
Note that KSK rollovers and ZSK rollovers are different in the sense that a KSK rollover requires interaction with the parent (and possibly replacing of trust anchors) and the ensuing delay while waiting for it.
それを待っている間、KSKロールオーバーとZSKロールオーバーがKSKロールオーバーが親との相互作用を必要とするという(ことによると信用の取り替えるのは投錨されます)感覚と続く遅れにおいて異なっていることに注意してください。
A zone key rollover can be handled in two different ways: pre-publish (Section 4.2.1.1) and double signature (Section 4.2.1.2).
2つの異なった方法でゾーンの主要なロールオーバーを扱うことができます: あらかじめ発行してください、(セクション4.2.1の.1と)二重署名、(セクション4.2 .1 .2)。
As the KSK is used to validate the key set and because the KSK is not changed during a ZSK rollover, a cache is able to validate the new key set of the zone. The pre-publish method would also work for a KSK rollover. The records that are to be pre-published are the parental DS RRs. The pre-publish method has some drawbacks for KSKs. We first describe the rollover scheme and then indicate these drawbacks.
KSKが主要なセットを有効にするのに使用されて、KSKがZSKロールオーバーの間、変えられないので、キャッシュはゾーンの新しい主要なセットを有効にすることができます。 また、あらかじめ広めている方法はKSKロールオーバーのために利くでしょう。あらかじめ発表されることになっているレコードは親のDS RRsです。 あらかじめ広めている方法には、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)
-------------------------------------------------------------------- 初期の新しいDS新しいDNSKEY DS/DNSKEY取り外し-------------------------------------------------------------------- 親: 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)
--------------------------------------------------------------------
子供: 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
あらかじめ発行している主要な調印主要なロールオーバーのための展開のステージ
Kolkman & Gieben Informational [Page 20] RFC 4641 DNSSEC Operational Practices September 2006
Kolkman&Giebenの情報[20ページ]のRFC4641のDNSSECの操作上の習慣2006年9月
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を発行します。 ロールオーバー(「新しいDNSKEY」フェーズ)の間、子供はDNSKEY1をDNSKEY2に取り替えます。(新しいDSセットがDNSを通して伝播されるとすぐに、それは、行われることができます)。 その(「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ステップから成ります。 「二重署名」方法は1回の相互作用しか必要としません。
4.2.4. Automated Key Rollovers
4.2.4. 自動化された主要なロールオーバー
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ロールオーバーは親子の間の相互作用を必要とします。 データ交換が親の新しいキーを提供するのに必要です。 その結果、このデータを認証しなければなりません、そして、ロールオーバーに対する攻撃を避けるために保全を保証しなければなりません。
4.3. Planning for Emergency Key Rollover
4.3. 非常時の主要なロールオーバーの計画を立てます。
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 キーがレゾルバに据えつけられて、合法化に出発点として使用される(一般に、これは最もアップデートしにくいです)限り。
Kolkman & Gieben Informational [Page 21] RFC 4641 DNSSEC Operational Practices September 2006
Kolkman&Giebenの情報[21ページ]のRFC4641のDNSSECの操作上の習慣2006年9月
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.
あなたの妥協しているキーへの信用チェーンは存在しますが、あなたの名前空間はキーの違法な所持を得ただれでも乱用するのにおいて傷つきやすいです。 ゾーンのオペレータは妥協しているキーの誤用が有効にすることができないキャッシュにおけるデータを持っているより悪いならトレードオフをしなければなりません。 ゾーンのオペレータが、妥協しているキーに信用チェーンを切り出すのを選ぶなら、このキーで署名されたキャッシュにおけるデータを有効にすることができません。 しかしながら、ゾーンの管理者が、通常のロールオーバーの経路を取るのを選ぶなら、悪意がある主要な所有者がデータをだますことができるので、それは有効であるように見えます。
4.3.1. KSK Compromise
4.3.1. KSK妥協
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.
信用アンカーか親のDSがそれを示すとき妥協しているKSKが構成される限り、妥協しているKSKとDNSKEY RRSetを含むゾーンは傷つきやすいです。
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が子供のゾーンから取り外されるとき、信用チェーンは壊れているでしょう。(仮定は1DSしか親にないということです。 複数のDSesがあれば、これは適用されません--しかしながら、この特定のキーの信用のチェーンは壊れています。).
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の存在が有効であるとしてこのゾーンのデータを現れさせることに注意してください。 妥協しているキーを取り外すと、有効であるとして見える攻撃者のゾーンと子供のゾーンはBogusとして引き起こされるでしょう。 したがって、私たちは、親が適所にある新しいKSKにDSを持つ前にKSKを取り外さないようにアドバイスします。
4.3.1.1. Keeping the Chain of Trust Intact
4.3.1.1. 信用のチェーンを完全に維持します。
If we follow this advice, the timing of the replacement of the KSK is somewhat critical. The goal is to remove the compromised KSK as soon as the new DS RR is available at the parent. And also make sure that the signature made with a new KSK over the key set with the compromised KSK in it expires just after the new DS appears at the parent, thus removing the old cruft in one swoop.
私たちがこのアドバイスに従うなら、KSKの交換のタイミングはいくらか重要です。 目標は新しいDS RRが親で利用可能であるとすぐに、妥協しているKSKを取り外すことです。 そして、また、新しいDSが親に現れたすぐ後に新しいKSKと共にそれの妥協しているKSKで主要なセットについてされた署名が期限が切れるのを確実にしてください、その結果、一撃で古い粗末な作りの結果を取り除きます。
The procedure is as follows:
手順は以下の通りです:
1. Introduce a new KSK into the key set, keep the compromised KSK in
the key set.
1. 主要なセットに新しいKSKを取り入れてください、そして、主要なセットで妥協しているKSKを保ってください。
Kolkman & Gieben Informational [Page 22] RFC 4641 DNSSEC Operational Practices September 2006
Kolkman&Giebenの情報[22ページ]のRFC4641のDNSSECの操作上の習慣2006年9月
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が親に現れると予想されたすぐ後に有効期間は期限が切れるべきです、そして、古いDSesはキャッシュから期限が切れました。
3. Upload the DS for this new key to the parent.
3. 親のこの新しいキーのためにDSをアップロードしてください。
4. Follow the procedure of the regular KSK rollover: Wait for the DS
to appear in the authoritative servers and then wait as long as
the TTL of the old DS RRs. If necessary re-sign the DNSKEY RRSet
and modify/extend the expiration time.
4. 通常のKSKロールオーバーの手順に従ってください: DSが正式のサーバに現れて、次に、古いDS RRsのTTLと同じくらい長い間待つのを待ってください。 満了時間を必要なら、DNSKEY RRSetを再契約してください、そして、変更するか、または延ばしてください。
5. Remove the compromised DNSKEY RR from the zone and re-sign the
key set using your "normal" validity interval.
5. ゾーンから妥協しているDNSKEY RRを取り外してください、そして、「正常な」正当性間隔を費やすことで主要なセットを再契約してください。
An additional danger of a key compromise is that the compromised key could be used to facilitate a legitimate DNSKEY/DS rollover and/or nameserver changes at the parent. When that happens, the domain may be in dispute. An authenticated out-of-band and secure notify mechanism to contact a parent is needed in this case.
主要な妥協の付加的な危険性は親で正統のDNSKEY/DSロールオーバー、そして/または、ネームサーバ変化を容易にするのに妥協しているキーを使用できたということです。 それが起こるとき、ドメインは論争中であるかもしれません。 バンドで出かけていて安全な状態で認証されて、メカニズムが親に連絡するように通知してください。この場合、必要です。
Note that this is only a problem when the DNSKEY and or DS records are used for authentication at the parent.
または、そして、DNSKEYであるときにだけ、これが問題であることに注意してください、DS記録は認証に親で使用されます。
4.3.1.2. Breaking the Chain of Trust
4.3.1.2. 信用のチェーンを壊します。
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 RRsを取り外すことです。 その結果、子供ゾーンは不安定になるでしょう。
4.3.2. ZSK Compromise
4.3.2. ZSK妥協
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
主としてZSKが妥協するとき必要であるどんな親の相互作用もないので、状況はKSK妥協ほど厳しくはありません。 できるだけ早く、新しいZSKと共にゾーンをまだ再契約しなければなりません。 これが地方の操作であり、親子のコミュニケーションを全く必要としないとき、かなりすばやくこれを達成できます。 しかしながら、人がそれを考慮に入れなければならない、正当
Kolkman & Gieben Informational [Page 23] RFC 4641 DNSSEC Operational Practices September 2006
Kolkman&Giebenの情報[23ページ]のRFC4641のDNSSECの操作上の習慣2006年9月
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の上のRRSIGが満期でない限り、ゾーンがまだ危険であるかもしれないことに注意してください。
4.3.3. Compromises of Keys Anchored in Resolvers
4.3.3. レゾルバに据えつけられたキーの妥協
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]を使用することで保証される発表ウェブサイトの使用で認証されるべきです。
4.4. Parental Policies
4.4. 親の方針
4.4.1. Initial Key Exchanges and Parental Policies Considerations
4.4.1. 初期の主要な交換と親の方針問題
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.
初期の主要な交換はいつも親で方針セットを受けることがあります。 主要な為替政策を設計するとき、メカニズムが主要な交換の間に使用した認証と認可がメカニズムが親子の間の代表団情報の交換に使用した認証と認可と同じくらい強いはずであるのを考慮に入れるべきです。 すなわち、認証過程をそれより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質問ツールはDNSSECの主要なセットから適切なキーを選択するのに9月ビット[3]を利用できます、その結果、間違ったDNSKEYを送るという可能性を小さくします。 それはキーの上の自己署名を有効にすることができます。 その結果、秘密鍵の材料の所有権について確かめます。 DNSからDNSKEYをとって来るのは、親がいったん子供が安全であることを示すDS RRを発行すると信用のチェーンが元の状態のままになるのを確実にします。
Note: the out-of-band verification is still needed when the key material is fetched via the DNS. The parent can never be sure whether or not the DNSKEY RRs have been spoofed.
以下に注意してください。 主要な材料がDNSを通してとって来られるとき、バンドで出ている検証がまだ必要です。 親はDNSKEY RRsがだまされたかどうかを確信しているはずがありません。
Kolkman & Gieben Informational [Page 24] RFC 4641 DNSSEC Operational Practices September 2006
Kolkman&Giebenの情報[24ページ]のRFC4641のDNSSECの操作上の習慣2006年9月
4.4.2. Storing Keys or Hashes?
4.4.2. 格納は、合わせますか、論じ尽くしますか?
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、そして/または、対応するDSesのどれを格納したらよいかを考えるはずです。 子供ゾーンがまだ登録に解釈されていなかったメッセージダイジェストアルゴリズムを使用することで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.
また、DNSKEYsを格納するのも役に立つかもしれません、彼らがいるのがトラブルシューティングの間、助けるかもしれなくて、子供の選ばれたメッセージダイジェストが支持される限り、それらからDS記録を発生させるオーバーヘッドが最小限ので。 また、どのキーが特定の所有者、そして/または、ゾーンにDS Resource Recordsを発生させるのに使用されるかを見つけるために、登録ディレクトリなどのバンドで出ているメカニズム(例えば、Whois)を持っているのはトラブルシューティングで助けるかもしれません。
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 RRsをアップロードできるでしょうか、インタフェースがDNSKEYsを許容するだけですか? 登録記録係モデルでは、1つはExtensible Provisioningプロトコル(EPP)[15]にDNSSEC拡張子を使用できます、任意にDS RRsの転送を許容するもの。DNSKEY RRs。
4.4.3. Security Lameness
4.4.3. セキュリティの不完全さ
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.
セキュリティの不完全さは親がDS RRに非既存のDNSKEY RRを示させるとき、何が起こるかと定義されます。 これが起こるとき、子供のゾーンは、「にせであること」がDNSクライアントについて確かめることによって、示されるかもしれません。
As part of a comprehensive delegation check, the parent could, at key exchange time, verify that the child's key is actually configured in the DNS. However, if a parent does not understand the hashing algorithm used by child, the parental checks are limited to only comparing the key id.
包括的な代表団チェックの一部として、主要な交換時に、親は、子供のキーが実際にDNSで構成されることを確かめることができました。 しかしながら、親が子供によって使用された論じ尽くすアルゴリズムを理解していないなら、親のチェックは主要なイドを比較するだけに制限されます。
Child zones should be very careful in removing DNSKEY material, specifically SEP keys, for which a DS RR exists.
子供ゾーンはDNSKEYの材料、明確に9月のキーを取り外すのにおいて非常に慎重であるはずです。(DS RRはキーに関して存在します)。
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を通して伝播するには時間がかかるでしょう。
Kolkman & Gieben Informational [Page 25] RFC 4641 DNSSEC Operational Practices September 2006
Kolkman&Giebenの情報[25ページ]のRFC4641のDNSSECの操作上の習慣2006年9月
4.4.4. DS Signature Validity Period
4.4.4. DS署名有効期間
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署名有効期間に1週間と何カ月もの間のどこかに結果として生じるかもしれません。
In addition to the signature validity period, which sets a lower bound on the number of times the zone owner will need to sign the zone data and which sets an upper bound to the time a child is vulnerable after key compromise, there is the TTL value on the DS RRs. Shortening the TTL means that the authoritative servers will see more queries. But on the other hand, a short TTL lowers the persistence of DS RRSets in caches thereby increasing the speed with which updated DS RRSets propagate through the DNS.
署名有効期間に加えて、TTL値がDS RRsにあります。有効期間は、ゾーン所有者が必要とする回数における下界にゾーンデータにサインするように設定して、子供が主要な妥協の後に傷つきやすい時に上限を設定します。 TTLを短くするのは、正式のサーバが、より多くの質問を見ることを意味します。 しかし、他方では、短いTTLはアップデートされたDS RRSetsがDNSを通して伝播するその結果スピードを出すキャッシュへのDS RRSetsの固執を下ろします。
5. Security Considerations
5. セキュリティ問題
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の'データ伝播'の特性を考慮に入れないのに、合法化に失敗を引き起こして、安全にされたゾーンはセキュリティ意識しているレゾルバに入手できなくなるかもしれません。
6. Acknowledgments
6. 承認
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
考えの元の貢献者であった個人を忘れるというリスクで、だれを住ませるように認めたいと思います。
Kolkman & Gieben Informational [Page 26] RFC 4641 DNSSEC Operational Practices September 2006
Kolkman&Giebenの情報[26ページ]のRFC4641のDNSSECの操作上の習慣2006年9月
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.
活発に、このドキュメントの編集にかかわりました。 順不同に: ルーミス、Olafurグドムンソン、ウエスリー・グリフィン、マイケル・リチャードソン、スコット・ローズ、リックバンRein、ティム・マクギニス、ジルGuetteオリビエCourtay、サム・ウィーラー、Jelteヤンセン、ニオール・オライリー、オルガーZuleger、Ed Lewis、Hilarie Orman、マルコス・サンス、およびピーター・コッホを裂いてください。
Some material in this document has been copied from RFC 2541 [12].
何らかの材料がRFC2541[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すべて(原文のまま)を導入するために罪を着ます。
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によって使われました。
7. References
7. 参照
7.1. Normative References
7.1. 引用規格
[1] Mockapetris, P., "Domain names - concepts and facilities", STD
13, RFC 1034, November 1987.
[1]Mockapetris、P.、「ドメイン名--、概念と施設、」、STD13、RFC1034、11月1987日
[2] Mockapetris, P., "Domain names - implementation and
specification", STD 13, RFC 1035, November 1987.
[2]Mockapetris、P.、「ドメイン名--、実現と仕様、」、STD13、RFC1035、11月1987日
[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.ルイス、「ドメインネームシステムの主要な(DNSKEY)リソース記録(RR)安全なエントリー・ポイント(9月)旗」、RFC3757)は2004がそうするかもしれません。
[4] Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose,
"DNS Security Introduction and Requirements", RFC 4033, March
2005.
[4]はArendsします、R.、Austein、R.、ラーソン、M.、マッシー、D.、S.ローズと、「DNSセキュリティ序論と要件」(RFC4033)は2005を行進させます。
[5] Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose,
"Resource Records for the DNS Security Extensions", RFC 4034,
March 2005.
[5] Arends、R.、Austein、R.、ラーソン、M.、マッシー、D.、およびS.が上昇したと「リソースはDNSセキュリティ拡張子のために記録します」、RFC4034、2005年3月。
[6] Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose,
"Protocol Modifications for the DNS Security Extensions", RFC
4035, March 2005.
[6] Arends(R.、Austein、R.、ラーソン、M.、マッシー、D.、およびS.ローズ)は「DNSセキュリティ拡張子のための変更について議定書の中で述べます」、RFC4035、2005年3月。
Kolkman & Gieben Informational [Page 27] RFC 4641 DNSSEC Operational Practices September 2006
Kolkman&Giebenの情報[27ページ]のRFC4641のDNSSECの操作上の習慣2006年9月
7.2. Informative References
7.2. 有益な参照
[7] Bradner, S., "Key words for use in RFCs to Indicate Requirement
Levels", BCP 14, RFC 2119, March 1997.
[7] ブラドナー、S.、「Indicate Requirement LevelsへのRFCsにおける使用のためのキーワード」、BCP14、RFC2119、1997年3月。
[8] Ohta, M., "Incremental Zone Transfer in DNS", RFC 1995, August
1996.
[8] 太田、M.、「DNSの増加のゾーン転送」、RFC1995、1996年8月。
[9] Vixie, P., "A Mechanism for Prompt Notification of Zone Changes
(DNS NOTIFY)", RFC 1996, August 1996.
[9]Vixie、P.、「ゾーン変化(DNSは通知する)の迅速な通知のためのメカニズム」、RFC1996、1996年8月。
[10] Wellington, B., "Secure Domain Name System (DNS) Dynamic
Update", RFC 3007, November 2000.
[10] ウェリントン、2000年11月、B.、「安全なドメインネームシステム(DNS)ダイナミック・アップデート」RFC3007。
[11] Andrews, M., "Negative Caching of DNS Queries (DNS NCACHE)",
RFC 2308, March 1998.
[11] アンドリュース、M.、「DNS質問(DNS NCACHE)の否定的キャッシュ」、RFC2308、1998年3月。
[12] Eastlake, D., "DNS Security Operational Considerations", RFC
2541, March 1999.
[12] イーストレーク、D.、「DNSのセキュリティの操作上の問題」、RFC2541、1999年3月。
[13] Orman, H. and P. Hoffman, "Determining Strengths For Public
Keys Used For Exchanging Symmetric Keys", BCP 86, RFC 3766,
April 2004.
[13]OrmanとH.とP.ホフマン、「対称鍵を交換するのに使用される公開鍵のために強さを測定する」BCP86、RFC3766、2004年4月。
[14] Eastlake, D., Schiller, J., and S. Crocker, "Randomness
Requirements for Security", BCP 106, RFC 4086, June 2005.
[14] イーストレークとD.とシラー、J.とS.クロッカー、「セキュリティのための偶発性要件」BCP106、2005年6月のRFC4086。
[15] Hollenbeck, S., "Domain Name System (DNS) Security Extensions
Mapping for the Extensible Provisioning Protocol (EPP)", RFC
4310, December 2005.
[15]Hollenbeck、S.、「広げることができる食糧を供給するプロトコルのために(EPP)を写像するドメインネームシステム(DNS)セキュリティ拡大」、RFC4310、2005年12月。
[16] Lenstra, A. and E. Verheul, "Selecting Cryptographic Key
Sizes", The Journal of Cryptology 14 (255-293), 2001.
[16]LenstraとA.とE.フェルヘール、「暗号化キーサイズを選択します」、暗号理論のジャーナル、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.、「適用された暗号:」 ISBN(ハードカバー)0-471-12845-7ISBN(ペーパーバック)0-471-59756-2は、ジョンワイリーと息子株式会社、1996年までに「Cのプロトコル、アルゴリズム、およびソースコード」と発行しました。
[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.、「DNSSECでのRSA/SHA-256 DNSKEYとRRSIGリソース記録の使用」が進歩、2006年1月に働いています。
[20] Hardaker, W., "Use of SHA-256 in DNSSEC Delegation Signer (DS)
Resource Records (RRs)", RFC 4509, May 2006.
[20]Hardaker(W.、「DNSSEC代表団署名者(DS)リソース記録(RRs)におけるSHA-256の使用」、RFC4509)は2006がそうするかもしれません。
Kolkman & Gieben Informational [Page 28] RFC 4641 DNSSEC Operational Practices September 2006
Kolkman&Giebenの情報[28ページ]のRFC4641のDNSSECの操作上の習慣2006年9月
[21] Blake-Wilson, S., Nystrom, M., Hopwood, D., Mikkelsen, J., and
T. Wright, "Transport Layer Security (TLS) Extensions", RFC
4366, April 2006.
[21] ブレーク-ウィルソン、S.、ニストロム、M.、Hopwood(D.、ミッケルセン、J.、およびT.ライト)は「層のセキュリティ(TLS)拡大を輸送します」、RFC4366、2006年4月。
Kolkman & Gieben Informational [Page 29] RFC 4641 DNSSEC Operational Practices September 2006
Kolkman&Giebenの情報[29ページ]のRFC4641のDNSSECの操作上の習慣2006年9月
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を見てください。 RRSetの署名がDNSKEYを有効にしないと、DNSSECのRRSetは「にせである」とマークされます。
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: Key Signing Key(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個(数学的に関係する)のキーの存在、公開鍵、および秘密鍵に基づいています。 公開鍵はDNSでDNSKEY Resource Record(DNSKEY RR)の使用で発行されます。 秘密鍵は個人的に残るべきです。
Key rollover: A key rollover (also called key supercession in some
environments) is the act of replacing one key pair with another at
the end of a key effectivity period.
キーロールオーバー: 主要なロールオーバー(また、いくつかの環境で主要なスーパー割譲と呼ばれる)は主要な実効の期間の終わりに主要な1組を別のものに取り替える行為です。
Secure Entry Point (SEP) key: A KSK that has a parental DS record
pointing to it or is configured as a trust anchor. Although not
required by the protocol, we recommend that the SEP flag [3] is
set on these keys.
Entry Point(9月)キーを固定してください: 親のDSにそれを示しながら記録させるか、または信用アンカーとして構成されるKSK。 プロトコルは必要ではありませんが、私たちは、9月の旗[3]がこれらのキーの上に設定されることを勧めます。
Self-signature: This only applies to signatures over DNSKEYs; a
signature made with DNSKEY x, over DNSKEY x is called a self-
signature. Note: without further information, self-signatures
convey no trust. They are useful to check the authenticity of the
DNSKEY, i.e., they can be used as a hash.
自己署名: これはDNSKEYsの上の署名に適用されるだけです。 DNSKEY xと共に署名をして、DNSKEYの上では、xは自己署名と呼ばれます。 以下に注意してください。 詳細がなければ、自己署名は信用を全く伝えません。 それらがDNSKEYの信憑性をチェックするために役に立つ、すなわち、細切れ肉料理としてそれらを使用できます。
Kolkman & Gieben Informational [Page 30] RFC 4641 DNSSEC Operational Practices September 2006
Kolkman&Giebenの情報[30ページ]のRFC4641のDNSSECの操作上の習慣2006年9月
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.
署名者: 秘密鍵の材料に近づく手段を持って、Resource Recordにサインするシステムはゾーンにセットします。 署名者は、ゾーン(例えば、既存の署名が期限が切れようとしているそれらのRRSetsだけ)の部分だけにサインするために構成されるかもしれません。
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つが「アクティブであり」、もう片方が「発行されている」とマークしてください。 ゾーンデータにサインするのに「アクティブな」キーを使用してください。 「発行された」キーの個人的な部分、望ましくはオフ線を格納してください。 プロトコルは、アクティブであるか発行されるとしてキーをマークするために属性に備えません。 これはあなたが一人でノートかかぎ管理ツールの使用でしなければならないことです。
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: 満了を決定してください: ロールオーバーの始めに、署名の現在のキーがアクティブであるとしてマークされている状態で作成されたあなたのゾーンファイルで最も高い満了時間を記録してください。 Step1でマークされた満了時間が過ぎるまで、待ってください。
Step 2: Then start using the key that was marked "published" to sign
your data (i.e., mark it "active"). Stop using the key that was
marked "active"; mark it "rolled".
ステップ2: そして、マークされたキーを使用する始めは、あなたのデータにサインするために「発行された」(すなわち、それが「アクティブである」とマークしてください)。 「アクティブである」とマークされたキーを使用するのを止めてください。 それが「回転されている」とマークしてください。
Step 3: It is safe to engage in a new rollover (Step 1) after at
least one signature validity period.
ステップ3: 少なくとも1回の署名有効期間の後に新しいロールオーバー(ステップ1)に従事しているのは安全です。
Kolkman & Gieben Informational [Page 31] RFC 4641 DNSSEC Operational Practices September 2006
Kolkman&Giebenの情報[31ページ]のRFC4641のDNSSECの操作上の習慣2006年9月
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.
主要な記法: DNSKEYxはキーを指示して、主要なイドとしてxを考えることができました。(そこでは、xは、数か識別子です)。
RRSet notations: RRs are only denoted by the type. All other information -- owner, class, rdata, and TTL--is left out. Thus: "example.com 3600 IN A 192.0.2.1" is reduced to "A". RRSets are a list of RRs. A example of this would be "A1, A2", specifying the RRSet containing two "A" records. This could again be abbreviated to just "A".
RRSet記法: RRsはタイプによって指示されるだけです。 他のすべての情報(所有者、クラス、rdata、およびTTL)が省かれます。 このようにして: 「example.com3600IN A、192.0 .2 0.1インチは「A」」に減少します。 RRSetsはRRsのリストです。 この例は「A1、1記録あたり2を含むRRSetを指定するA2"」でしょう。 再びまさしく「A」にこれを簡略化できました。
Signature notation: Signatures are denoted as RRSIGx(RRSet), which means that RRSet is signed with DNSKEYx.
署名記法: RRSIGx(RRSet)(そのRRSetを意味する)がDNSKEYxを契約されるとき、署名は指示されます。
Zone representation: Using the above notation we have simplified the representation of a signed zone by leaving out all unnecessary details such as the names and by representing all data by "SOAx"
ゾーン表現: 上の記法を使用して、私たちは、名前などの不要なすべての詳細を省いて、"SOAx"ですべてのデータを表すことによって、サインされたゾーンの表現を簡素化しました。
SOA representation: SOAs are represented as SOAx, where x is the serial number.
SOA表現: SOAsはSOAxとして表されます。そこでは、xが通し番号です。
Using this notation the following signed zone:
この記法を使用して、以下はゾーンにサインしました:
example.net. 86400 IN SOA ns.example.net. bert.example.net. (
2006022100 ; serial
86400 ; refresh ( 24 hours)
7200 ; retry ( 2 hours)
3600000 ; expire (1000 hours)
28800 ) ; minimum ( 8 hours)
86400 RRSIG SOA 5 2 86400 20130522213204 (
20130422213204 14 example.net.
cmL62SI6iAX46xGNQAdQ... )
86400 NS a.iana-servers.net.
86400 NS b.iana-servers.net.
86400 RRSIG NS 5 2 86400 20130507213204 (
20130407213204 14 example.net.
SO5epiJei19AjXoUpFnQ ... )
86400 DNSKEY 256 3 5 (
EtRB9MP5/AvOuVO0I8XDxy0... ) ; id = 14
86400 DNSKEY 257 3 5 (
gsPW/Yy19GzYIY+Gnr8HABU... ) ; id = 15
86400 RRSIG DNSKEY 5 2 86400 20130522213204 (
20130422213204 14 example.net.
J4zCe8QX4tXVGjV4e1r9... )
example.net。 86400 IN SOA ns.example.net bert.example.net。 (2006022100; 連続の86400;は7200年の(24時間)の間、リフレッシュします; 3600000を再試行してください(2時間); 28800を吐き出してください(1000時間)) ; (8時間)の最小の86400RRSIG SOA5 2 86400 20130522213204(20130422213204 14example.net cmL62SI6iAX46xGNQAdQ…) 86400NS a.のiana-servers.net。 86400NS b.のiana-servers.net。 86400 RRSIGナノ秒5 2 86400 20130507213204( 20130407213204 14example.net。 SO5epiJei19AjXoUpFnQ… ) 86400 DNSKEY256 3 5(EtRB9MP5/AvOuVO0I8XDxy0…) ; イド=14 86400DNSKEY257 3 5(gsPW/Yy19GzYIY+Gnr8HABU) ; イドは15 86400RRSIG DNSKEY5 2 86400 20130522213204と等しいです。( 20130422213204 14example.net。 J4zCe8QX4tXVGjV4e1r9… )
Kolkman & Gieben Informational [Page 32] RFC 4641 DNSSEC Operational Practices September 2006
Kolkman&Giebenの情報[32ページ]のRFC4641のDNSSECの操作上の習慣2006年9月
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 DNSKEY5 2 86400 20130522213204(20130422213204 15example.net keVDCOpsSeDReyV6O.) 86400 RRSIG NSEC5 2 86400 20130507213204(20130407213204 14example.net obj3HEp1GjnmhRjX…)a.example.net。 86400 IN TXT「ラベル」86400RRSIG TXT5 3 86400 20130507213204( 20130407213204 14example.net。 IkDMlRdYLmXH7QJnuF3v.。 ) 86400 NSEC b.example.com。 TXT RRSIG NSEC86400RRSIG NSEC5 3 86400 20130507213204(20130407213204 14example.net bZMjoZ3bHjnEz0nIsPMM…) ...
is reduced to the following representation:
以下の表現に減少します:
SOA2006022100
RRSIG14(SOA2006022100)
DNSKEY14
DNSKEY15
SOA2006022100 RRSIG14(SOA2006022100)DNSKEY14 DNSKEY15
RRSIG14(KEY)
RRSIG15(KEY)
RRSIG14の(主要)のRRSIG15(主要)です。
The rest of the zone data has the same signature as the SOA record, i.e., an RRSIG created with DNSKEY 14.
ゾーンデータの残りには、SOA記録(すなわち、DNSKEY14と共に作成されたRRSIG)と同じ署名があります。
Kolkman & Gieben Informational [Page 33] RFC 4641 DNSSEC Operational Practices September 2006
Kolkman&Giebenの情報[33ページ]のRFC4641のDNSSECの操作上の習慣2006年9月
Authors' Addresses
作者のアドレス
Olaf M. Kolkman NLnet Labs Kruislaan 419 Amsterdam 1098 VA The Netherlands
オラフM.Kolkman NLnet研究室Kruislaan419アムステルダム1098ヴァージニアオランダ
EMail: olaf@nlnetlabs.nl URI: http://www.nlnetlabs.nl
メール: olaf@nlnetlabs.nl ユリ: http://www.nlnetlabs.nl
R. (Miek) Gieben
R.(Miek)Gieben
EMail: miek@miek.nl
メール: miek@miek.nl
Kolkman & Gieben Informational [Page 34] RFC 4641 DNSSEC Operational Practices September 2006
Kolkman&Giebenの情報[34ページ]のRFC4641のDNSSECの操作上の習慣2006年9月
Full Copyright Statement
完全な著作権宣言文
Copyright (C) The Internet Society (2006).
Copyright(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.
このドキュメントはBCP78に含まれた権利、ライセンス、および制限を受けることがあります、そして、そこに詳しく説明されるのを除いて、作者は彼らのすべての権利を保有します。
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.
このドキュメントと「そのままで」という基礎と貢献者、その人が代表する組織で提供するか、または後援されて、インターネット協会とインターネット・エンジニアリング・タスク・フォースはすべての保証を放棄します、と急行ORが含意したということであり、他を含んでいて、ここに含まれて、情報の使用がここに侵害しないどんな保証も少しもまっすぐになるという情報か市場性か特定目的への適合性のどんな黙示的な保証。
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はどんなIntellectual Property Rightsの正当性か範囲、実現に関係すると主張されるかもしれない他の権利、本書では説明された技術の使用またはそのような権利の下におけるどんなライセンスも利用可能であるかもしれない、または利用可能でないかもしれない範囲に関しても立場を全く取りません。 または、それはそれを表しません。どんなそのような権利も特定するためのどんな独立している努力もしました。 BCP78とBCP79でRFCドキュメントの権利に関する手順に関する情報を見つけることができます。
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倉庫からこの仕様のimplementersかユーザによるそのような所有権の使用のために許可を得ることができます。
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 Editor機能のための基金はIETF Administrative Support Activity(IASA)によって提供されます。
Kolkman & Gieben Informational [Page 35]
Kolkman&Gieben情報です。[35ページ]
一覧
スポンサーリンク
