Network Working Group M. StJohns
Request for Comments: 5011 Independent
Category: Standards Track September 2007
Automated Updates of DNS Security (DNSSEC) Trust Anchors
Status of This Memo
このメモのステータス
This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited.
この文書は、インターネットコミュニティのためのインターネット標準トラックプロトコルを指定し、改善のための議論と提案を要求します。このプロトコルの標準化状態と状態への「インターネット公式プロトコル標準」（STD 1）の最新版を参照してください。このメモの配布は無制限です。
Abstract
抽象
This document describes a means for automated, authenticated, and authorized updating of DNSSEC "trust anchors". The method provides protection against N-1 key compromises of N keys in the trust point key set. Based on the trust established by the presence of a current anchor, other anchors may be added at the same place in the hierarchy, and, ultimately, supplant the existing anchor(s).
この文書では、自動化された手段を説明し、認証、およびDNSSEC「トラストアンカー」の更新を承認しました。この方法は、信頼ポイントキーセット内のN個のキーのN-1鍵妥協に対する保護を提供します。現在のアンカーの存在によって確立された信頼に基づいて、他のアンカーは、最終的には、既存のアンカー（複数可）を取って代わる、階層内の同じ場所に添加することができます。
This mechanism will require changes to resolver management behavior (but not resolver resolution behavior), and the addition of a single flag bit to the DNSKEY record.
このメカニズムは、管理動作（ただし、レゾルバ解像度挙動）、およびDNSKEYレコードに単一のフラグビットの付加をリゾルバの変更を必要とするであろう。
Table of Contents
目次
1. Introduction ....................................................2
1.1. Compliance Nomenclature ....................................3
2. Theory of Operation .............................................3
2.1. Revocation .................................................4
2.2. Add Hold-Down ..............................................4
2.3. Active Refresh .............................................5
2.4. Resolver Parameters ........................................6
2.4.1. Add Hold-Down Time ..................................6
2.4.2. Remove Hold-Down Time ...............................6
2.4.3. Minimum Trust Anchors per Trust Point ...............6
3. Changes to DNSKEY RDATA Wire Format .............................6
4. State Table .....................................................6
4.1. Events .....................................................7
4.2. States .....................................................7
5. Trust Point Deletion ............................................8
6. Scenarios - Informative .........................................9
6.1. Adding a Trust Anchor ......................................9
6.2. Deleting a Trust Anchor ....................................9
6.3. Key Roll-Over .............................................10
6.4. Active Key Compromised ....................................10
6.5. Stand-by Key Compromised ..................................10
6.6. Trust Point Deletion ......................................10
7. IANA Considerations ............................................11
8. Security Considerations ........................................11
8.1. Key Ownership vs. Acceptance Policy .......................11
8.2. Multiple Key Compromise ...................................12
8.3. Dynamic Updates ...........................................12
9. Normative References ...........................................12
10. Informative References ........................................12
As part of the reality of fielding DNSSEC (Domain Name System Security Extensions) [RFC4033] [RFC4034] [RFC4035], the community has come to the realization that there will not be one signed name space, but rather islands of signed name spaces each originating from specific points (i.e., 'trust points') in the DNS tree. Each of those islands will be identified by the trust point name, and validated by at least one associated public key. For the purpose of this document, we'll call the association of that name and a particular key a 'trust anchor'. A particular trust point can have more than one key designated as a trust anchor.
DNSSEC（ドメインネームシステムセキュリティ拡張）[RFC4033] [RFC4034] [RFC4035]を守備の現実の一環として、コミュニティは1つの署名した名前空間がないだろうという認識に来ているのではなく、署名の名前空間の島々各DNSツリー内の特定のポイント（すなわち、「トラスト・ポイント」）からの発信。これらの島々の各トラストポイントの名前で識別されると、少なくとも1つの関連する公開鍵によって検証されます。このドキュメントの目的のために、私たちはその名前の団体や特定のキー「トラストアンカー」を呼ぶことにします。特定のトラストポイントは、トラストアンカーとして指定された複数のキーを持つことができます。
For a DNSSEC-aware resolver to validate information in a DNSSEC protected branch of the hierarchy, it must have knowledge of a trust anchor applicable to that branch. It may also have more than one trust anchor for any given trust point. Under current rules, a chain of trust for DNSSEC-protected data that chains its way back to ANY known trust anchor is considered 'secure'.
DNSSEC対応リゾルバは、階層のDNSSEC保護されたブランチ内の情報を検証するために、それはそのブランチに適用されるトラストアンカーの知識を持っている必要があります。また、任意の与えられた信頼ポイントに複数のトラストアンカーを有することができます。現在のルールの下では、DNSSECで保護されたデータの信頼のチェーンチェーンバック任意の既知のトラストアンカーへの道は、「安全な」とみなされていること。
Because of the probable balkanization of the DNSSEC tree due to signing voids at key locations, a resolver may need to know literally thousands of trust anchors to perform its duties (e.g., consider an unsigned ".COM"). Requiring the owner of the resolver to manually manage these many relationships is problematic. It's even more problematic when considering the eventual requirement for key replacement/update for a given trust anchor. The mechanism described herein won't help with the initial configuration of the trust anchors in the resolvers, but should make trust point key replacement/rollover more viable.
信頼がその職務を行うためにアンカーのためにより重要な場所で署名ボイドへのDNSSECの木の可能性バルカンの、リゾルバは、文字通り何千ものを知っている必要があるかもしれません（例えば、符号なしの「.COM」を検討してください）。手動でこれらの多くの関係を管理するためにレゾルバの所有者を必要とすることは問題です。与えられた信頼アンカーのためのキーの交換/更新のための最終的な要件を検討する際にはさらに問題です。本明細書中に記載の仕組みは、リゾルバでトラストアンカーの初期設定で助けにはなりませんが、信頼ポイントの鍵交換/ロールオーバーは、より現実的にする必要があります。
As mentioned above, this document describes a mechanism whereby a resolver can update the trust anchors for a given trust point, mainly without human intervention at the resolver. There are some corner cases discussed (e.g., multiple key compromise) that may require manual intervention, but they should be few and far between. This document DOES NOT discuss the general problem of the initial configuration of trust anchors for the resolver.
上述したように、このドキュメントは、レゾルバは、主にリゾルバに人間の介入なしに、所与のトラストポイントのトラストアンカーを更新することができる機構を記載しています。そこ手動の介入を必要とするかもしれない（例えば、複数の鍵の危殆化）検討し、いくつかのコーナーケースがありますが、それらは少なく、これまでの間でなければなりません。この文書では、リゾルバのためのトラストアンカーの初期構成の一般的な問題については説明していません。
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14, [RFC2119].
この文書のキーワード "MUST"、 "MUST NOT"、 "REQUIRED"、、、、 "べきではない" "べきである" "ないもの" "ものとし"、 "推奨"、 "MAY"、および "OPTIONAL" はありますBCP 14、[RFC2119]に記載されているように解釈されます。
The general concept of this mechanism is that existing trust anchors can be used to authenticate new trust anchors at the same point in the DNS hierarchy. When a zone operator adds a new SEP key (i.e., a DNSKEY with the Secure Entry Point bit set) (see [RFC4034], Section 2.1.1) to a trust point DNSKEY RRSet, and when that RRSet is validated by an existing trust anchor, then the resolver can add the new key to its set of valid trust anchors for that trust point.
このメカニズムの一般的な概念は、既存のトラストアンカーがDNS階層内の同じポイントで新しいトラストアンカーを認証するために使用することができるということです。ゾーンのオペレータは、新たな9月のキー（すなわち、セキュアエントリポイントのビットがセットされたDNSKEY）を追加すると（[RFC4034]を参照して、セクション2.1.1）信頼ポイントDNSKEY資源レコード集合に、その資源レコード集合は、既存の信頼によって検証されたときアンカーは、その後、リゾルバはその信頼ポイントの有効なトラストアンカーのセットに新しいキーを追加することができます。
There are some issues with this approach that need to be mitigated. For example, a compromise of one of the existing keys could allow an attacker to add their own 'valid' data. This implies a need for a method to revoke an existing key regardless of whether or not that key is compromised. As another example, assuming a single key compromise, we need to prevent an attacker from adding a new key and revoking all the other old keys.
軽減する必要があり、このアプローチにはいくつかの問題があります。例えば、既存のキーの一つの妥協案は、攻撃者は、自分の「有効」データを追加する可能性があります。これは関係なく、そのキーが侵害されたかどうかの既存のキーを取り消す方法の必要性を意味します。別の例として、単一のキーの妥協を想定し、我々は新しいキーを追加し、他のすべての古いキーを取り消すから攻撃を阻止する必要があります。
Assume two trust anchor keys A and B. Assume that B has been compromised. Without a specific revocation bit, B could invalidate A simply by sending out a signed trust point key set that didn't contain A. To fix this, we add a mechanism that requires knowledge of the private key of a DNSKEY to revoke that DNSKEY.
AとBは、Bが侵害されたと仮定2つのトラストアンカーキーを想定しています。特定の失効ビットがなければ、BはA.この問題を解決するには含まれていませんでした署名トラストポイントのキーセットを送信するだけで無効にでき、私たちはそのDNSKEYを取り消すためにDNSKEYの秘密鍵の知識を必要とする仕組みを追加します。
A key is considered revoked when the resolver sees the key in a self-signed RRSet and the key has the REVOKE bit (see Section 7 below) set to '1'. Once the resolver sees the REVOKE bit, it MUST NOT use this key as a trust anchor or for any other purpose except to validate the RRSIG it signed over the DNSKEY RRSet specifically for the purpose of validating the revocation. Unlike the 'Add' operation below, revocation is immediate and permanent upon receipt of a valid revocation at the resolver.
リゾルバは、自己署名資源レコード集合にキーを見て、キーが「1」に設定REVOKEビット（以下のセクション7を参照）を有する場合鍵が失効であると考えられます。リゾルバは、REVOKEビットを見たら、それがトラストアンカーとして、あるいはそれが失効を検証する目的のために特別DNSKEY資源レコード集合の上に署名したRRSIGを検証する以外に、他の目的のために、このキーを使用してはなりません。下の「追加」の操作とは異なり、失効は、リゾルバで有効取消しの受信時に即時かつ永続的です。
A self-signed RRSet is a DNSKEY RRSet that contains the specific DNSKEY and for which there is a corresponding validated RRSIG record. It's not a special DNSKEY RRSet, just a way of describing the validation requirements for that RRSet.
自己署名資源レコード集合は、特定のDNSKEYを含有しているため、対応する検証RRSIGレコードが存在するDNSKEYの資源レコード集合です。これは、特別のDNSKEY資源レコード集合、その資源レコード集合の検証要件を記述するだけの方法ではありません。
N.B.: A DNSKEY with the REVOKE bit set has a different fingerprint than one without the bit set. This affects the matching of a DNSKEY to DS records in the parent [RFC3755], or the fingerprint stored at a resolver used to configure a trust point.
N.B .:ビットセットREVOKEとDNSKEYは、ビットが設定されていないものとは異なるフィンガープリントを有します。これは、親[RFC3755]、またはトラストポイントを設定するために使用されるリゾルバに記憶されている指紋におけるDSのレコードにDNSKEYのマッチングに影響を与えます。
In the given example, the attacker could revoke B because it has knowledge of B's private key, but could not revoke A.
与えられた例では、攻撃者は、それがBの秘密鍵の知識を持っているので、Bを取り消すことができますが、Aを取り消すことができませんでした
Assume two trust point keys A and B. Assume that B has been compromised. An attacker could generate and add a new trust anchor key C (by adding C to the DNSKEY RRSet and signing it with B), and then invalidate the compromised key. This would result in both the attacker and owner being able to sign data in the zone and have it accepted as valid by resolvers.
AとBは、Bが損なわれていると仮定する2つのトラストポイントキーをとります。攻撃者は、生成し（DNSKEY資源レコード集合にCを追加し、Bと、それに署名することによって）新しいトラストアンカーキーCを追加し、妥協キーを無効にすることができます。これにより、攻撃者と所有者の両方がゾーン内のデータに署名することができることになり、それはリゾルバによって有効なものとして受け入れられています。
To mitigate but not completely solve this problem, we add a hold-down time to the addition of the trust anchor. When the resolver sees a new SEP key in a validated trust point DNSKEY RRSet, the resolver starts an acceptance timer, and remembers all the keys that validated the RRSet. If the resolver ever sees the DNSKEY RRSet without the new key but validly signed, it stops the acceptance process for that key and resets the acceptance timer. If all of the keys that were originally used to validate this key are revoked prior to the timer expiring, the resolver stops the acceptance process and resets the timer.
軽減するが、完全にこの問題を解決しないために、我々は、トラストアンカーのほかにホールドダウン時間を追加します。リゾルバが検証され、トラストポイントDNSKEY資源レコード集合の新しい9月キーを見ると、リゾルバは受け入れタイマーを開始し、資源レコード集合を検証し、すべてのキーを覚えています。リゾルバが今まで新しいキーなしDNSKEY資源レコード集合を見ているが、有効に署名した場合は、そのキーの受付処理を停止し、受け入れタイマーをリセットします。もともと、このキーを検証するために使用されたすべてのキーは、タイマ満了前に取り消された場合、リゾルバは、受付処理を停止し、タイマーをリセットします。
Once the timer expires, the new key will be added as a trust anchor the next time the validated RRSet with the new key is seen at the resolver. The resolver MUST NOT treat the new key as a trust anchor until the hold-down time expires AND it has retrieved and validated a DNSKEY RRSet after the hold-down time that contains the new key.
タイマーの期限が切れると、新しいキーがトラストアンカーとして新しいキーで検証資源レコード集合は、リゾルバで見られる次の時間を追加されます。ホールドダウンタイムが切れるまでリゾルバは、トラストアンカーとして新しいキーを処理してはならず、それが取得され、新しいキーが含まれているホールドダウンタイムの後DNSKEY資源レコード集合を検証しました。
N.B.: Once the resolver has accepted a key as a trust anchor, the key MUST be considered a valid trust anchor by that resolver until explicitly revoked as described above.
リゾルバは、信頼アンカーとしてキーを受け入れた後は前述のように、明示的に取り消されるまでN.Bは：、キーはそのリゾルバによって有効なトラストアンカー考えなければなりません。
In the given example, the zone owner can recover from a compromise by revoking B and adding a new key D and signing the DNSKEY RRSet with both A and B.
与えられた例では、ゾーンの所有者は、Bを取り消して、新しい鍵Dを追加し、AとBの両方とDNSKEY資源レコード集合に署名することによって妥協点から回復することができ
The reason this does not completely solve the problem has to do with the distributed nature of DNS. The resolver only knows what it sees. A determined attacker who holds one compromised key could keep a single resolver from realizing that the key had been compromised by intercepting 'real' data from the originating zone and substituting their own (e.g., using the example, signed only by B). This is no worse than the current situation assuming a compromised key.
これは完全に問題が解決しない理由は、DNSの分散性に関係しています。リゾルバは、それが見ているものを知っています。 1つの危殆化鍵を保持し、決定攻撃者は、キー（例えば、例を使用して、唯一のBによって署名された）元のゾーンから「実際の」データをインターセプトし、自分自身を置換することによって危険にさらされたことを認識から単リゾルバを保つことができます。これは妥協キーを想定して、現在の状況よりも悪化していません。
A resolver that has been configured for an automatic update of keys from a particular trust point MUST query that trust point (e.g., do a lookup for the DNSKEY RRSet and related RRSIG records) no less often than the lesser of 15 days, half the original TTL for the DNSKEY RRSet, or half the RRSIG expiration interval and no more often than once per hour. The expiration interval is the amount of time from when the RRSIG was last retrieved until the expiration time in the RRSIG. That is, queryInterval = MAX(1 hr, MIN (15 days, 1/2*OrigTTL, 1/2*RRSigExpirationInterval))
特定のトラストポイントからキーの自動更新に設定されているリゾルバはその信頼ポイント劣らず、多くの場合、15日間の少ない方よりも（例えば、DNSKEY資源レコード集合と関連するRRSIGレコードの検索を行いません）、元の半分を照会しなければなりませんDNSKEY資源レコード集合のTTL、またはハーフRRSIGの有効期間と無より頻繁に1時間に1回以上。期限切れ間隔はRRSIGがRRSIGに有効期限まで、最後に取得されたときからの時間の量です。すなわち、queryInterval = MAX（1時間、MIN（15日1/2 * OrigTTL 1/2 * RRSigExpirationInterval））であります
If the query fails, the resolver MUST repeat the query until satisfied no more often than once an hour and no less often than the lesser of 1 day, 10% of the original TTL, or 10% of the original expiration interval. That is, retryTime = MAX (1 hour, MIN (1 day, .1 * origTTL, .1 * expireInterval)).
クエリが失敗した場合、リゾルバはないより頻繁に何度も時間と劣らず、しばしば1日のうちの小さい方よりも、元のTTLの10％、または元の期限切れ間隔の10％を満足するまで、問い合わせを繰り返す必要があります。つまり、RETRYTIME = MAX（1時間、MIN（1日、0.1 * origTTL、0.1 * expireInterval））です。
The add hold-down time is 30 days or the expiration time of the original TTL of the first trust point DNSKEY RRSet that contained the new key, whichever is greater. This ensures that at least two validated DNSKEY RRSets that contain the new key MUST be seen by the resolver prior to the key's acceptance.
追加ホールドダウン時間が30日以上である方新しいキーを、含まれている最初の信頼ポイントDNSKEY資源レコード集合の元のTTLの有効期限です。これは、新しいキーが含まれている少なくとも二つの検証済みのDNSKEY RRセットがキーの受け入れに先立って、リゾルバで見なければならないことを保証します。
The remove hold-down time is 30 days. This parameter is solely a key management database bookeeping parameter. Failure to remove information about the state of defunct keys from the database will not adversely impact the security of this protocol, but may end up with a database cluttered with obsolete key information.
削除ホールドダウン時間は30日です。このパラメータは、単に鍵管理データベースbookeepingパラメータです。データベースからの故人となったキーの状態についての情報を削除に失敗すると、悪影響このプロトコルのセキュリティに影響を与えませんが、廃止されたキー情報と雑然とデータベースで終わることがあります。
A compliant resolver MUST be able to manage at least five SEP keys per trust point.
対応リゾルバは、信頼ポイントあたり少なくとも5つのSEP鍵を管理できなければなりません。
Bit 8 of the DNSKEY Flags field is designated as the 'REVOKE' flag. If this bit is set to '1', AND the resolver sees an RRSIG(DNSKEY) signed by the associated key, then the resolver MUST consider this key permanently invalid for all purposes except for validating the revocation.
DNSKEYのフラグフィールドのビット8は「REVOKE」フラグとして指定されています。このビットが「1」に設定されている場合は、レゾルバは、関連する鍵で署名RRSIG（DNSKEY）を見て、その後、リゾルバは失効を検証するため除いて、全ての目的のために、このキーは恒久的に無効考慮する必要があります。
The most important thing to understand is the resolver's view of any key at a trust point. The following state table describes this view at various points in the key's lifetime. The table is a normative part of this specification. The initial state of the key is 'Start'. The resolver's view of the state of the key changes as various events occur.
理解するために最も重要なことは、信頼点で任意のキーのリゾルバの図です。以下の状態テーブルには、キーの有効期間内の様々な点で、このビューを説明しています。表には、この仕様書の規範的部分です。キーの初期状態は、「スタート」です。キーの状態が変化するのリゾルバの観点様々なイベントが発生したとして。
This is the state of a trust-point key as seen from the resolver. The column on the left indicates the current state. The header at the top shows the next state. The intersection of the two shows the event that will cause the state to transition from the current state to the next.
これは、リゾルバから見た信頼点キーの状態です。左の列には、現在の状態を示します。上部のヘッダは、次の状態を示しています。両者の交点は状態が次の現在の状態から遷移させますイベントを示しています。
NEXT STATE
--------------------------------------------------
FROM |Start |AddPend |Valid |Missing|Revoked|Removed|
----------------------------------------------------------
Start | |NewKey | | | | |
----------------------------------------------------------
AddPend |KeyRem | |AddTime| | | |
----------------------------------------------------------
Valid | | | |KeyRem |Revbit | |
----------------------------------------------------------
Missing | | |KeyPres| |Revbit | |
----------------------------------------------------------
Revoked | | | | | |RemTime|
----------------------------------------------------------
Removed | | | | | | |
----------------------------------------------------------
State Table
状態表
NewKey The resolver sees a valid DNSKEY RRSet with a new SEP key. That key will become a new trust anchor for the named trust point after it's been present in the RRSet for at least 'add time'.
リゾルバNEWKEY新しい9月キーで有効なDNSKEY資源レコード集合のを見ています。それは、少なくとも「時間を追加」の資源レコード集合に存在していた後、そのキーは、名前のトラストポイントの新しいトラストアンカーとなります。
KeyPres The key has returned to the valid DNSKEY RRSet.
キーが有効なDNSKEY資源レコード集合に戻ってきたKeyPres。
KeyRem The resolver sees a valid DNSKEY RRSet that does not contain this key.
KeyRemリゾルバは、このキーが含まれていない有効なDNSKEY資源レコード集合のを見ています。
AddTime The key has been in every valid DNSKEY RRSet seen for at least the 'add time'.
でaddTime鍵は、少なくとも「時間を追加する」のため見られ、すべての有効なDNSKEYの資源レコード集合になっています。
RemTime A revoked key has been missing from the trust-point DNSKEY RRSet for sufficient time to be removed from the trust set.
RemTime Aは鍵が信頼セットから削除されるのに十分な時間の信頼点DNSKEY資源レコード集合から欠落している取り消されました。
RevBit The key has appeared in the trust anchor DNSKEY RRSet with its "REVOKED" bit set, and there is an RRSig over the DNSKEY RRSet signed by this key.
キーはその「REVOKED」ビットが設定されたトラストアンカーDNSKEY資源レコード集合に登場しているし、この鍵で署名DNSKEY資源レコード集合オーバーRRSIGがあるRevBit。
Start The key doesn't yet exist as a trust anchor at the resolver. It may or may not exist at the zone server, but either hasn't yet been seen at the resolver or was seen but was absent from the last DNSKEY RRSet (e.g., KeyRem event).
まだリゾルバのトラストアンカーとして存在しないキーを開始します。なお、またはゾーンサーバに存在しない場合があり、まだリゾルバで見れていない、または見られたが、最後のDNSKEY資源レコード集合（例えば、KeyRemイベント）から存在しなかったのいずれか。
AddPend The key has been seen at the resolver, has its 'SEP' bit set, and has been included in a validated DNSKEY RRSet. There is a hold-down time for the key before it can be used as a trust anchor.
AddPend鍵はリゾルバで、その「9月」ビットがセットされている、および検証DNSKEY資源レコード集合に含まれている見られています。それがトラストアンカーとして使用することができます前に、キーのホールドダウンタイムがあります。
Valid The key has been seen at the resolver and has been included in all validated DNSKEY RRSets from the time it was first seen through the hold-down time. It is now valid for verifying RRSets that arrive after the hold-down time. Clarification: The DNSKEY RRSet does not need to be continuously present at the resolver (e.g., its TTL might expire). If the RRSet is seen and is validated (i.e., verifies against an existing trust anchor), this key MUST be in the RRSet, otherwise a 'KeyRem' event is triggered.
有効なキーは、リゾルバで見てきたし、それが最初のホールドダウン時間を通して見た時から、すべての検証済みのDNSKEY RRセットに含まれています。それは今のホールドダウン時間後に到着のRRsetを検証するために有効です。明確化：DNSKEY資源レコード集合は、リゾルバで連続的に存在する必要はない（例えば、そのTTLが期限切れになるかもしれません）。資源レコード集合は（すなわち、既存のトラストアンカーに対して検証）見られ、検証された場合、このキーは、そうでなければ「KeyRem」イベントがトリガされ、資源レコード集合でなければなりません。
Missing This is an abnormal state. The key remains a valid trust-point key, but was not seen at the resolver in the last validated DNSKEY RRSet. This is an abnormal state because the zone operator should be using the REVOKE bit prior to removal.
この不足していることは異常な状態です。キーが有効なトラストポイントのキーのままですが、最後の検証DNSKEY資源レコード集合でリゾルバでは見られませんでした。ゾーンオペレータは除去前にREVOKEビットを使用しなければならないので、これは異常な状態です。
Revoked This is the state a key moves to once the resolver sees an RRSIG(DNSKEY) signed by this key where that DNSKEY RRSet contains this key with its REVOKE bit set to '1'. Once in this state, this key MUST permanently be considered invalid as a trust anchor.
失効これはリゾルバが資源レコード集合がREVOKEとこのキーが「1」に設定ビットが含まれるDNSKEYこのキーによって署名されたRRSIG（DNSKEY）を見た後に鍵が移動状態です。一度この状態では、このキーは永久にトラストアンカーとして無効であると見なされなければなりません。
Removed After a fairly long hold-down time, information about this key may be purged from the resolver. A key in the removed state MUST NOT be considered a valid trust anchor. (Note: this state is more or less equivalent to the "Start" state, except that it's bad practice to re-introduce previously used keys -- think of this as the holding state for all the old keys for which the resolver no longer needs to track state.)
かなり長いホールドダウン時間後に除去し、このキーの情報は、リゾルバからパージすることができます。取り外した状態のキーが有効なトラストアンカーと見なされてはなりません。 （注：この状態は「開始」状態に多かれ少なかれ同等である、それは再導入以前に使用したキーに悪い習慣だことを除いて - そのためのリゾルバは、もはやすべての古いキーのニーズのための保持状態と考えます状態を追跡することができます。）
A trust point that has all of its trust anchors revoked is considered deleted and is treated as if the trust point was never configured. If there are no superior configured trust points, data at and below the deleted trust point are considered insecure by the resolver. If there ARE superior configured trust points, data at and below the deleted trust point are evaluated with respect to the superior trust point(s).
そのトラストアンカーのすべてが取り消されたトラストポイントが削除とみなされ、トラストポイントが設定されなかったかのように扱われています。全く優れ構成されるトラスト・ポイントがない場合、削除されたトラストポイントで、以下のデータは、レゾルバによって安全でないと考えられます。優れた構成トラスト・ポイントがある場合、削除されたトラストポイントで、以下のデータは、優れた信頼ポイント（S）に対して評価されます。
Alternately, a trust point that is subordinate to another configured trust point MAY be deleted by a resolver after 180 days, where such a subordinate trust point validly chains to a superior trust point. The decision to delete the subordinate trust anchor is a local configuration decision. Once the subordinate trust point is deleted, validation of the subordinate zone is dependent on validating the chain of trust to the superior trust point.
代替的に、別の構成トラストポイントに従属する信頼ポイントは、優れた信頼ポイントにこのような従属信頼ポイント正当チェーン180日後にレゾルバによって削除されてもよいです。下位のトラストアンカーを削除するという決定は、ローカル設定の決定です。下位の信頼ポイントを削除すると、下位ゾーンの検証は、優れたトラストポイントに信頼の連鎖の検証に依存しています。
The suggested model for operation is to have one active key and one stand-by key at each trust point. The active key will be used to sign the DNSKEY RRSet. The stand-by key will not normally sign this RRSet, but the resolver will accept it as a trust anchor if/when it sees the signature on the trust point DNSKEY RRSet.
操作のための提案されたモデルは、一つの活性の鍵と1つのスタンドバイ各トラストポイントでキーを持つことです。アクティブなキーはDNSKEY資源レコード集合に署名するために使用されます。スタンバイキーは、通常は、この資源レコード集合に署名しないだろうが、それは信頼ポイントDNSKEY資源レコード集合の署名を見たとき/場合リゾルバは、トラストアンカーとしてそれを受け入れます。
Since the stand-by key is not in active signing use, the associated private key may (and should) be provided with additional protections not normally available to a key that must be used frequently (e.g., locked in a safe, split among many parties, etc). Notionally, the stand-by key should be less subject to compromise than an active key, but that will be dependent on operational concerns not addressed here.
スタンバイキーがアクティブに署名使用されていないので、関連する秘密鍵は（とすべきである）（頻繁に使用されなければならないキーに通常は利用できない追加的な保護を提供することができるなど、多くの関係者の間で安全な、スプリットでロック、など）。概念的に、スタンバイキーがアクティブなキーよりも妥協する小さい対象とすべきであるが、それはここでは取り上げない運用の懸念に依存することになります。
Assume an existing trust anchor key 'A'.
既存のトラストアンカーキー「A」を前提としています。
2. Create a DNSKEY record from the key pair and set the SEP and Zone Key bits.
2.鍵ペアからDNSKEYレコードを作成し、9月とゾーンキービットを設定します。
4. Sign the DNSKEY RRSet ONLY with the existing trust anchor key - 'A'.
「A」 - 4. ONLY既存のトラストアンカーキーでDNSKEY資源レコード集合に署名します。
5. Wait for various resolvers' timers to go off and for them to retrieve the new DNSKEY RRSet and signatures.
5.オフに行くと、彼らは新しいDNSKEY資源レコード集合と署名を取得するためにするために、様々なリゾルバタイマーを待ちます。
6. The new trust anchor will be populated at the resolvers on the schedule described by the state table and update algorithm -- see Sections 2 and 4 above.
6.新しいトラストアンカーは、状態テーブルと更新アルゴリズムによって記述スケジュールでリゾルバに移入する - 上記のセクション2及び4を参照されたいです。
Assume existing trust anchors 'A' and 'B' and that you want to revoke and delete 'A'.
既存のトラストアンカー「A」と「B」を想定し、「A」を取り消して削除すること。
2. Sign the DNSKEY RRSet with both 'A' and 'B'. 'A' is now revoked. The operator should include the revoked 'A' in the RRSet for at least the remove hold-down time, but then may remove it from the DNSKEY RRSet.
2.「A」と「B」の両方でDNSKEY資源レコード集合に署名します。 「A」は、今取り消されます。オペレータは、少なくとも削除ホールドダウン時間「」資源レコード集合に失効含むべきであるが、その後DNSKEY資源レコード集合からそれを除去することができます。
Assume existing keys A and B. 'A' is actively in use (i.e. has been signing the DNSKEY RRSet). 'B' was the stand-by key. (i.e. has been in the DNSKEY RRSet and is a valid trust anchor, but wasn't being used to sign the RRSet).
AとB「A」は（すなわちDNSKEY資源レコード集合に署名されている）の使用に積極的であり、既存のキーをとります。 「B」はスタンドバイ鍵となりました。 （すなわちDNSKEY資源レコード集合にされており、有効なトラストアンカーであるが、資源レコード集合に署名するために使用されていませんでした）。
1. Generate a new key pair 'C'. 2. Add 'C' to the DNSKEY RRSet. 3. Set the revocation bit on key 'A'. 4. Sign the RRSet with 'A' and 'B'.
1.新しい鍵ペア「C」を生成します。 2. DNSKEY資源レコード集合に「C」を追加します。 3.キー「A」に失効ビットを設定します。 4.「A」と「B」との資源レコード集合に署名します。
'A' is now revoked, 'B' is now the active key, and 'C' will be the stand-by key once the hold-down expires. The operator should include the revoked 'A' in the RRSet for at least the remove hold-down time, but may then remove it from the DNSKEY RRSet.
「A」は今取り消され、「B」は、現在アクティブキー、及び「C」で待機キーホールドダウンの有効期限が切れた後であろう。オペレータは、少なくとも削除ホールドダウン時間「」資源レコード集合に失効含むべきであるが、その後DNSKEY資源レコード集合からそれを除去することができます。
This is the same as the mechanism for Key Roll-Over (Section 6.3) above, assuming 'A' is the active key.
これは、 'アクティブ鍵であると仮定すると、上記のキーロールオーバ（セクション6.3）のための機構と同じです。
Using the same assumptions and naming conventions as Key Roll-Over (Section 6.3) above:
キーロールオーバー（6.3節）上記と同じ仮定と命名規則を使用します：
1. Generate a new key pair 'C'. 2. Add 'C' to the DNSKEY RRSet. 3. Set the revocation bit on key 'B'. 4. Sign the RRSet with 'A' and 'B'.
1.新しい鍵ペア「C」を生成します。 2. DNSKEY資源レコード集合に「C」を追加します。 3.キー「B」に失効ビットを設定します。 4.「A」と「B」との資源レコード集合に署名します。
'B' is now revoked, 'A' remains the active key, and 'C' will be the stand-by key once the hold-down expires. 'B' should continue to be included in the RRSet for the remove hold-down time.
「B」は今取り消され、 'アクティブキーのままであり、「C」は待機キーホールドダウンの有効期限が切れた後であろう。 「B」は削除ホールドダウンタイムのための資源レコード集合に含まれるように継続すべきです。
To delete a trust point that is subordinate to another configured trust point (e.g., example.com to .com) requires some juggling of the data. The specific process is:
別の構成されたトラストポイントに従属するトラストポイントを削除する（例えば、example.com .COMには）データのいくつかのジャグリングを必要とします。具体的なプロセスは次のとおりです。
1. Generate a new DNSKEY and DS record and provide the DS record to the parent along with DS records for the old keys.
1.新しいDNSKEYとDSレコードを生成し、古いキーのDSレコードと一緒に親にDSレコードを提供します。
2. Once the parent has published the DSs, add the new DNSKEY to the RRSet and revoke ALL of the old keys at the same time, while signing the DNSKEY RRSet with all of the old and new keys.
2.親がのDSを公開していたら、資源レコード集合に新しいDNSKEYを追加し、古いものと新しいキーのすべてにDNSKEY資源レコード集合に署名しながら、同時に、古いキーのすべてを取り消します。
3. After 30 days, stop publishing the old, revoked keys and remove any corresponding DS records in the parent.
3. 30日後に、古い、取り消されたキーを公開停止し、親にどんな対応するDSレコードを削除します。
Revoking the old trust-point keys at the same time as adding new keys that chain to a superior trust prevents the resolver from adding the new keys as trust anchors. Adding DS records for the old keys avoids a race condition where either the subordinate zone becomes unsecure (because the trust point was deleted) or becomes bogus (because it didn't chain to the superior zone).
優れた信頼にチェーンする新しいキーを追加すると同時に、古いトラストポイントのキーを取り消すとトラストアンカーとして新しいキーを追加することからリゾルバを防ぐことができます。 （それは、優れたゾーンに連鎖しなかったので）古いキーのDSレコードを追加すると、下位のゾーンが安全でないとなり（信頼ポイントが削除されたため）または偽のいずれかとなり競合状態を避けることができます。
The IANA has assigned a bit in the DNSKEY flags field (see Section 7 of [RFC4034]) for the REVOKE bit (8).
IANAは、REVOKEビット（8）のための（[RFC4034]のセクション7を参照）DNSKEYフラグフィールドにビットを割り当てています。
In addition to the following sections, see also Theory of Operation above (Section 2) and especially Section 2.2 for related discussions.
以下のセクションに加えて、（第2）と関連する議論のために特にセクション2.2上記動作原理を参照。
Security considerations for trust anchor rollover not specific to this protocol are discussed in [RFC4986].
このプロトコルに固有のものではありませんトラストアンカーのロールオーバーのためのセキュリティの考慮事項は、[RFC4986]で議論されています。
The reader should note that, while the zone owner is responsible for creating and distributing keys, it's wholly the decision of the resolver owner as to whether to accept such keys for the authentication of the zone information. This implies the decision to update trust-anchor keys based on trusting a current trust-anchor key is also the resolver owner's decision.
読者は、ゾーンの所有者がキーを作成し、配布する責任がある一方で、それはゾーン情報の認証のため、このような鍵を受け入れるかどうかについての完全リゾルバの所有者の決断だ、ということに注意してください。また、これはリゾルバの所有者の決定である現在の信頼アンカーキーを信頼に基づいた信頼アンカーキーを更新する決定を意味します。
The resolver owner (and resolver implementers) MAY choose to permit or prevent key status updates based on this mechanism for specific trust points. If they choose to prevent the automated updates, they will need to establish a mechanism for manual or other out-of-band updates, which are outside the scope of this document.
リゾルバの所有者（とレゾルバ実装）は、許可または特定のトラストポイントのため、このメカニズムに基づいてキーステータスの更新を防ぐために選ぶかもしれません。彼らは、自動更新を防止することを選択した場合、彼らはこの文書の範囲外にある手動または他の帯域外の更新のためのメカニズムを確立する必要があります。
This scheme permits recovery as long as at least one valid trust-anchor key remains uncompromised, e.g., if there are three keys, you can recover if two of them are compromised. The zone owner should determine their own level of comfort with respect to the number of active, valid trust anchors in a zone and should be prepared to implement recovery procedures once they detect a compromise. A manual or other out-of-band update of all resolvers will be required if all trust-anchor keys at a trust point are compromised.
この方式は、回復を許可する限り、少なくとも1つの有効なトラストアンカーキーは、3つのキーがある場合は、それらの2が侵害された場合、あなたが回復することができ、例えば、妥協のないまま。ゾーンの所有者は、ゾーンでアクティブ、有効な信頼アンカーの数に対する慰めの自分のレベルを決定する必要があり、彼らは妥協を検出したら、復旧手順を実装するために準備する必要があります。トラストポイントですべてのトラストアンカーキーが侵害された場合、すべてのリゾルバの手動または他の帯域外の更新が必要になります。
Allowing a resolver to update its trust anchor set based on in-band key information is potentially less secure than a manual process. However, given the nature of the DNS, the number of resolvers that would require update if a trust anchor key were compromised, and the lack of a standard management framework for DNS, this approach is no worse than the existing situation.
リゾルバは、インバンドキー情報に基づいて、そのトラストアンカーセットを更新できるようにすると、潜在的に手動プロセスよりも安全です。しかし、DNSの性質を考えると、トラストアンカーキーが危険にさらされた場合は、更新を必要とするリゾルバの数、およびDNSのための標準的な管理フレームワークの欠如は、このアプローチは、既存の状況よりも悪化していません。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119]ブラドナーの、S.、 "要件レベルを示すためにRFCsにおける使用のためのキーワード"、BCP 14、RFC 2119、1997年3月。
[RFC3755] Weiler, S., "Legacy Resolver Compatibility for Delegation Signer (DS)", RFC 3755, May 2004.
[RFC3755]ワイラー、S.、 "委任署名者のためのレガシーレゾルバの互換性（DS）"、RFC 3755、2004年5月。
[RFC4033] Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose, "DNS Security Introduction and Requirements", RFC 4033, March 2005.
[RFC4033]アレンズ、R.、Austeinと、R.、ラーソン、M.、マッシー、D.、およびS.ローズ、 "DNSセキュリティ序論と要件"、RFC 4033、2005年3月。
[RFC4034] Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose, "Resource Records for the DNS Security Extensions", RFC 4034, March 2005.
[RFC4034]アレンズ、R.、Austeinと、R.、ラーソン、M.、マッシー、D.、およびS.ローズ、 "DNSセキュリティ拡張機能のためのリソースレコード"、RFC 4034、2005年3月。
[RFC4035] Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose, "Protocol Modifications for the DNS Security Extensions", RFC 4035, March 2005.
[RFC4035]アレンズ、R.、Austeinと、R.、ラーソン、M.、マッシー、D.、およびS.ローズ、 "DNSセキュリティ拡張のためのプロトコル変更"、RFC 4035、2005年3月。
[RFC4986] Eland, H., Mundy, R., Crocker, S., and S. Krishnaswamy, "Requirements Related to DNS Security (DNSSEC) Trust Anchor Rollover", RFC 4986, August 2007.
[RFC4986]エランド、H.、マンディ、R.、クロッカー、S.、およびS・クリシュナズワミー、RFC 4986、2007年8月 "DNSセキュリティ（DNSSEC）トラストアンカーのロールオーバーに関する要求事項"。
Author's Address
著者のアドレス
Michael StJohns Independent
マイケルStJohns独立
EMail: mstjohns@comcast.net
メールアドレス：mstjohns@comcast.net
Full Copyright Statement
完全な著作権声明
Copyright (C) The IETF Trust (2007).
著作権（C）IETFトラスト（2007）。
This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights.
この文書では、BCP 78に含まれる権利と許可と制限の適用を受けており、その中の記載を除いて、作者は彼らのすべての権利を保有します。
This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
この文書とここに含まれている情報は、基礎とCONTRIBUTOR「そのまま」、ORGANIZATION HE / SHEが表すまたはインターネットSOCIETY、（もしあれば）を後援し、IETF TRUST ANDインターネットエンジニアリングタスクフォース放棄ALLに設けられています。保証は、明示または黙示、この情報の利用および特定目的に対する権利または商品性または適合性の黙示の保証を侵害しない任意の保証がこれらに限定されません。
Intellectual Property
知的財産
The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79.
IETFは、本書またはそのような権限下で、ライセンスがたりないかもしれない程度に記載された技術の実装や使用に関係すると主張される可能性があります任意の知的財産権やその他の権利の有効性または範囲に関していかなる位置を取りません利用可能です。またそれは、それがどのような権利を確認する独自の取り組みを行ったことを示すものでもありません。 RFC文書の権利に関する手続きの情報は、BCP 78およびBCP 79に記載されています。
Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.
IPRの開示のコピーが利用できるようにIETF事務局とライセンスの保証に行われた、または本仕様の実装者または利用者がそのような所有権の使用のための一般的なライセンスまたは許可を取得するために作られた試みの結果を得ることができますhttp://www.ietf.org/iprのIETFのオンラインIPRリポジトリから。
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org.
IETFは、その注意にこの標準を実装するために必要とされる技術をカバーすることができる任意の著作権、特許または特許出願、またはその他の所有権を持ってすべての利害関係者を招待します。 ietf-ipr@ietf.orgのIETFに情報を記述してください。