[要約] RFC 5011は、DNSSECの信頼アンカーの自動更新に関する規格です。その目的は、信頼アンカーの更新を自動化し、DNSセキュリティの継続的な保護を確保することです。
Network Working Group M. StJohns
Request for Comments: 5011 Independent
Category: Standards Track September 2007
Automated Updates of DNS Security (DNSSEC) Trust Anchors
DNSセキュリティ（DNSSEC）トラストアンカーの自動更新
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「Trust Anchors」の自動化され、認証された、承認された更新の手段について説明しています。この方法は、Trust Point Keyセットの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」と考えてください）。これらの多くの関係を手動で管理するためにリゾルバーの所有者に要求することには問題があります。特定のトラストアンカーの主要な交換/更新の最終的な要件を考慮すると、さらに問題があります。本明細書に記載されているメカニズムは、リゾルバーの信頼アンカーの初期構成には役立ちませんが、Trust Point Keyの交換/ロールオーバーをより実行可能にする必要があります。
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].
「必須」、「そうしない」、「必須」、「必要」、「「しない」、「そうでない」、「そうではない」、「そうでない」、「推奨」、「5月」、および「オプション」は、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階層の同じ時点で新しい信頼アンカーを認証できることです。ゾーンオペレーターが新しいSEPキー（つまり、セキュアエントリポイントビットセットを備えたDNSKEY）（[RFC4034]、セクション2.1.1を参照）を信頼ポイントDNSKEY RRSETに追加する場合、およびそのRRSetが既存の信頼によって検証された場合アンカー、その後、リゾルバーはその信頼ポイントの有効な信頼のアンカーのセットに新しいキーを追加できます。
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.
このアプローチには、緩和する必要がある問題がいくつかあります。たとえば、既存のキーの1つの妥協により、攻撃者が独自の「有効な」データを追加できるようになります。これは、そのキーが侵害されているかどうかに関係なく、既存のキーを取り消す方法が必要であることを意味します。別の例として、単一のキーの妥協を仮定すると、攻撃者が新しいキーを追加して他のすべての古いキーを取り消すのを防ぐ必要があります。
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.
2つのTrust Anchor Keys AとBを想定しています。Bが損なわれていると仮定します。特定の取り消しビットがなければ、BはAを含む署名されたTrust Pointキーセットを送信するだけでAを無効にする可能性があります。これを修正するために、DNSKEYの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.
リゾルバーが自己署名のRRSetのキーを表示し、キーに「1」に設定されたqueke bit（以下のセクション7を参照）がある場合、キーは取り消されたと見なされます。ResolverがRecokeビットを見たら、このキーを信頼のアンカーとして、またはdnskey RRSetを介して署名したRRSIGを検証することを除いて、取り消しを検証するために特別に検証することを除いて、その他の目的のために使用してはなりません。以下の「追加」操作とは異なり、Resolverで有効な取り消しを受け取ると、取り消しは即時かつ永続的です。
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.
自己署名RRSTは、特定のDNSKEYを含むDNSKEY RRSETであり、対応する検証済みのRRSIGレコードがあります。それは特別なdnskey rrsetではなく、そのrrsetの検証要件を説明する方法にすぎません。
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 Bit Setを備えたDNSKEYは、ビットセットのない指とは異なる指紋を持っています。これは、親[RFC3755]のDNSKEYのDSレコードへのマッチング、または信頼ポイントの構成に使用されるリゾルバーに保存されている指紋に影響します。
In the given example, the attacker could revoke B because it has knowledge of B's private key, but could not revoke A.
与えられた例では、Bの秘密鍵の知識があるが、Aを取り消すことができなかったため、攻撃者はBを取り消すことができました。
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.
2つのトラストポイントキーAとBを仮定します。Bが妥協されたと仮定します。攻撃者は、新しいTrust AnchorキーCを生成して追加することができます（dnskey rrsetにCを追加してbで署名）してから、侵害されたキーを無効にします。これにより、攻撃者と所有者の両方がゾーン内のデータに署名し、リゾルバーによって有効なものとして受け入れられるようになります。
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.
この問題を緩和しますが、完全に解決するためには、信頼アンカーの追加にホールドダウン時間を追加します。Resolverが検証済みのTrust Point DNSKEY RRSetに新しいSEPキーを表示すると、ResolverはAcceptance Timerを開始し、RRSetを検証したすべてのキーを覚えています。Resolverが新しいキーなしでDNSKEY RRSETを見たが、有効に署名した場合、そのキーの受け入れプロセスを停止し、受け入れタイマーをリセットします。このキーを検証するために元々使用されていたすべてのキーがタイマーが切れる前に取り消された場合、リゾルバーは受け入れプロセスを停止し、タイマーをリセットします。
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.
タイマーが期限切れになると、新しいキーは、新しいキーを次にリゾルバーで検証されたRRSetが表示されるときに、トラストアンカーとして追加されます。リゾルバーは、ホールドダウン時間が失効するまで新しいキーを信頼のアンカーとして扱ってはなりません。また、新しいキーを含むホールドダウン時間の後にDNSKEY RRSetを取得して検証しました。
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 RRSetに署名することにより、妥協から回復できます。
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))
特定の信頼ポイントからキーの自動更新用に構成されたリゾルバーは、その信頼ポイント（たとえば、DNSKEY RRSetおよび関連するRRSIGレコードを検索する）をクエリする必要があります。DNSKEY RRSETの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時間に1回以上満たさず、1日間、元のTTLの10％、または元の有効期限間隔の10％よりも頻繁にクエリを繰り返す必要があります。つまり、retrytime = max（1時間、min（1日、.1 * origttl、.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.
追加時間は、新しいキーを含む最初の信頼ポイントDNSKEY RRSETの30日または元のTTLの有効期限です。これにより、新しいキーを含む少なくとも2つの検証されたDNSKEY RRSETが、キーの受け入れ前にリゾルバーによって確認されなければなりません。
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は、「Recoke」フラグとして指定されています。このビットが「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.
これは、リゾルバーから見た信頼点キーの状態です。左側の列は、現在の状態を示しています。上部のヘッダーは次の状態を示しています。2つの交差点は、州が現在の状態から次の状態に移行するイベントを示しています。
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 The Resolverは、新しいSEPキーを備えた有効なDNSKEY RRSETを表示します。そのキーは、少なくとも「追加時間」でRRSetに存在した後、指名された信頼ポイントの新しい信頼アンカーになります。
KeyPres The key has returned to the valid DNSKEY RRSet.
keypresキーが有効なdnskey rrsetに戻りました。
KeyRem The resolver sees a valid DNSKEY RRSet that does not contain this key.
Keyrem The Resolverには、このキーが含まれていない有効なDNSKEY RRSETが表示されます。
AddTime The key has been in every valid DNSKEY RRSet seen for at least the 'add time'.
追加タイムは、少なくとも「追加時間」で見られるすべての有効なdnskey rrsetにあります。
RemTime A revoked key has been missing from the trust-point DNSKEY RRSet for sufficient time to be removed from the trust set.
Remtime Trust-Point DNSKEY RRSETから取り消されたキーは、信頼セットから削除されるのに十分な時間がありません。
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.
Revbit the Keyは、「Revoked」ビットセットを備えたTrust Anchor dnskey RRSetに表示され、このキーが署名したDNSKEY RRSetにRRSIGがあります。
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 RRSet（たとえば、キーレムイベント）には存在しなかった。
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キーはリゾルバーで見られ、「SEP」ビットセットがあり、検証済みのDNSKEY RRSetに含まれています。キーが信頼のアンカーとして使用できるようにする前に、キーにはホールドダウン時間があります。
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 rrsetsに含まれています。現在、保留時間の後に到着するrrsetsを確認するために有効です。明確化：DNSKEY RRSTは、リゾルバーに継続的に存在する必要はありません（たとえば、TTLが期限切れになる可能性があります）。RRSetが見られ、検証されている場合（つまり、既存の信頼アンカーに対して検証されます）、このキーはRRSetにある必要があります。そうしないと、「キーレム」イベントがトリガーされます。
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 RRSetのリゾルバーでは見られませんでした。ゾーンオペレーターは除去前に取り消しビットを使用する必要があるため、これは異常な状態です。
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.
取り消されたこれは、リゾルバーがこのキーによって署名されたRRSIG（DNSKEY）を見るとキーが動く状態であり、そのdnskey rrsetがこのキーが「1」に設定されたこのキーが含まれています。この状態に着くと、このキーは永久に無効と見なされなければなりません。
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).
すべての信頼アンカーが取り消された信託ポイントは削除されていると見なされ、信頼ポイントが構成されていないかのように扱われます。優れた設定された信頼ポイントがない場合、削除された信頼ポイント以下のデータは、リゾルバーによって安全でないと見なされます。優れた設定された信頼ポイントがある場合、削除された信頼ポイント以下のデータが、優れた信頼ポイントに関して評価されます。
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つのアクティブキーと1つのスタンバイキーを持つことです。アクティブキーを使用して、DNSKEY RRSetに署名します。スタンバイキーは通常このRRSetに署名しませんが、リゾルバーは、信頼ポイントDNSKEY RRSETの署名を確認した場合に信頼のアンカーとしてそれを受け入れます。
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」を仮定します。
1. Generate a new key pair.
1. 新しいキーペアを生成します。
2. Create a DNSKEY record from the key pair and set the SEP and Zone Key bits.
2. キーペアからDNSKEYレコードを作成し、SEPとゾーンキービットを設定します。
3. Add the DNSKEY to the RRSet.
3. dnskeyをRRSetに追加します。
4. Sign the DNSKEY RRSet ONLY with the existing trust anchor key - 'A'.
4. 既存のトラストアンカーキー「A」でのみDNSKEY RRSETに署名します。
5. Wait for various resolvers' timers to go off and for them to retrieve the new DNSKEY RRSet and signatures.
5. さまざまなリゾルバーのタイマーがオフになり、新しいDNSKEY RRSetと署名を取得するのを待ちます。
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」を取り消して削除したいと仮定します。
1. Set the revocation bit on key 'A'.
1. キー「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. dnskey rrsetに「a」と「b」の両方で署名します。「A」が取り消されました。オペレーターには、少なくとも削除された保留時間の間、RRSetに取り消された「A」を含める必要がありますが、DNSKEY RRSetから削除する場合があります。
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 RRSetに署名しています）。「B」はスタンバイキーでした。（つまり、DNSKEY RRSetに属しており、有効な信頼アンカーですが、RRSetの署名には使用されていませんでした）。
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 rrsetに「c」を追加します。3.キー「A」に取り消しビットを設定します。4.「A」と「B」でRRSetに署名します。
'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」は、ホールドダウンが期限切れになるとスタンバイキーになります。オペレーターは、少なくとも削除された保留時間の間、RRSetに取り消された「A」を含める必要がありますが、DNSKEY RRSetから削除する場合があります。
This is the same as the mechanism for Key Roll-Over (Section 6.3) above, assuming 'A' is the active key.
これは、「A」がアクティブキーであると仮定して、上記のキーロールオーバー（セクション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 rrsetに「c」を追加します。3.キー「b」に取り消しビットを設定します。4.「A」と「B」でRRSetに署名します。
'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」が取り消され、「A」はアクティブなキーのままであり、ホールドダウンが期限切れになると「C」がスタンバイキーになります。「B」は、削除時間のために引き続きRRSetに含まれている必要があります。
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: 1. Generate a new DNSKEY and DS record and provide the DS record to the parent along with DS records for the old keys.
別の構成された信頼ポイントに従属する信託ポイントを削除するには（例：Example.comから.com）、データのジャグリングが必要です。特定のプロセスは次のとおりです。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. 親がDSSを公開したら、新しいDNSKEYをRRSETに追加し、すべての古いキーを同時に取り消し、DNSKEY RRSetに古いキーと新しいキーをすべて署名します。
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 Bit（8）にDNSKEYフラグフィールド（[RFC4034]のセクション7を参照）に少し割り当てられています。
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.
Resolverの所有者（およびリゾルバーの実装者）は、特定の信頼ポイントのこのメカニズムに基づいて、キーステータスの更新を許可または防止することを選択できます。自動更新を防ぐことを選択した場合、このドキュメントの範囲外である手動またはその他のバンド外の更新のメカニズムを確立する必要があります。
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] Bradner、S。、「要件レベルを示すためにRFCで使用するためのキーワード」、BCP 14、RFC 2119、1997年3月。
[RFC3755] Weiler, S., "Legacy Resolver Compatibility for Delegation Signer (DS)", RFC 3755, May 2004.
[RFC3755] Weiler、S。、「Legacy Resolver compatibility for Dedigation Signer（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] Arends、R.、Austein、R.、Larson、M.、Massey、D。、およびS. Rose、「DNSセキュリティの紹介と要件」、RFC 4033、2005年3月。
[RFC4034] Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose, "Resource Records for the DNS Security Extensions", RFC 4034, March 2005.
[RFC4034] Arends、R.、Austein、R.、Larson、M.、Massey、D。、およびS. Rose、「DNSセキュリティ拡張機能のリソースレコード」、RFC 4034、2005年3月。
[RFC4035] Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose, "Protocol Modifications for the DNS Security Extensions", RFC 4035, March 2005.
[RFC4035] Arends、R.、Austein、R.、Larson、M.、Massey、D。、およびS. Rose、「DNSセキュリティ拡張のプロトコル変更」、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] Eland、H.、Mundy、R.、Crocker、S。、およびS. Krishnaswamy、「DNSセキュリティ（DNSSEC）Trust Anchor Rolloverに関連する要件」、RFC 4986、2007年8月。
Author's Address
著者の連絡先
Michael StJohns Independent
Michael Stjohns Independent
EMail: mstjohns@comcast.net
Full Copyright Statement
完全な著作権声明
Copyright (C) The IETF Trust (2007).
著作権（c）The IETF Trust（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.
このドキュメントとここに含まれる情報は、「現状のまま」に基づいて提供され、貢献者、彼/彼女が代表する組織（もしあれば）、インターネット協会、IETFトラスト、インターネットエンジニアリングタスクフォースがすべてを否認します。明示的または黙示的な保証。ここでの情報の使用は、特定の目的に対する商品性または適合性の権利または暗黙の保証を侵害しないという保証を含むがこれらに限定されない。
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.
IETF事務局に行われたIPR開示のコピーと、利用可能にするライセンスの保証、またはこの仕様の実装者またはユーザーによるそのような独自の権利の使用のための一般的なライセンスまたは許可を取得するための試みの結果を取得できます。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への情報をお問い合わせください。