------------------------------------------------------------------------ 本文書は総務省「令和5年度ISPにおけるネットワークセキュリティ技術の導入 及び普及促進に関する調査の請負事業DNSSECガイドライン作成チーム」の活動 の成果物として作成されました。 JPRSでは本文書を無償でご提供いただき、総務省の許諾のもと、ご提供いただ いた形で無償公開します。 ------------------------------------------------------------------------ Internet Engineering Task Force (IETF) S. Morris RFC: 7583 ISC 分類: 情報提供(Informational) J. Ihren ISSN: 2070-1721 Netnod J. Dickinson Sinodun W. Mekking Dyn 2015年10月 DNSSECにおける鍵のロールオーバーのタイミングに関する考慮点 要旨 本文書は、DNSSECで保護されたゾーンにおける鍵のロールオーバーイベント のタイミングにまつわる問題を記述する。鍵ロールオーバーのタイムライン を示し、プロセスに影響を与える様々なパラメーター間の関係を明示的に 特定する。 Status of This Memo This document is not an Internet Standards Track specification; it is published for informational purposes. This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Not all documents approved by the IESG are a candidate for any level of Internet Standard; see Section 2 of RFC 5741. Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at http://www.rfc-editor.org/info/rfc7583. Morris, et al. Informational [Page 1] RFC 7583 Key Timing October 2015 Copyright Notice Copyright (c) 2015 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. 目次 1. はじめに ........................................................3 1.1. 鍵のロールオーバーの考慮点 .................................3 1.2. 鍵の種類 ...................................................4 1.3. 用語 .......................................................4 1.4. 対象範囲の限定 .............................................5 2. ロールオーバー方式 ..............................................5 2.1. ZSKのロールオーバー ........................................5 2.2. KSKのロールオーバー ........................................7 3. 鍵のロールオーバーのタイムライン ................................8 3.1. 鍵の状態 ...................................................8 3.2. ZSKのロールオーバーのタイムライン .........................10 3.2.1. 事前公開法 .........................................10 3.2.2. 二重署名法 .........................................12 3.3. KSKのロールオーバーのタイムライン .........................14 3.3.1. 二重KSK法 ..........................................14 3.3.2. 二重DS法 ...........................................17 3.3.3. 二重RRset法 ........................................20 3.3.4. トラストアンカーが設定されている場合の相互作用 .....22 3.3.5. 最初の鍵の導入 .....................................24 4. スタンバイ鍵 ...................................................24 5. アルゴリズムに関する考慮点 .....................................25 6. 要旨 ...........................................................26 7. Security Considerations ........................................26 8. Normative References ...........................................26 付録A. 記号の一覧 .................................................28 Acknowledgements ..................................................31 Authors' Addresses ................................................31 Morris, et al. Informational [Page 2] RFC 7583 Key Timing October 2015 1. はじめに 1.1. 鍵のロールオーバーの考慮点 ゾーンがDNSSECで保護されている場合、ゾーン管理者は、署名プロセスで 使用される鍵の置き換え("ロールオーバー")の準備をしておかなければ ならない。鍵のロールオーバーは、既存の鍵が1つ以上漏洩したことに起因 する場合もあれば、セキュリティ上の理由あるいは運用上の理由から定期的 な鍵の更新を求める管理ポリシーによるものである場合もある。鍵のロール オーバーを実施するためには、適切なタイミングで鍵をゾーンに導入したり 取り除いたりしなければならない。その際に考慮されなければならない点は 以下のとおりである。 o DNSKEYレコードと関連情報(DSレコードや、その鍵で作成されたRRSIG レコードなど)は、権威ネームサーバーに保持されるだけでなく、 リゾルバーにもキャッシュされる。複数のシステム上にあるこれらの データは、連動する可能性がある。例えば、署名を検証するリゾルバー は、キャッシュから取得した署名を、別途取得した鍵で検証しようと するかもしれない。 o ゾーンが初めて署名される"ブートストラップ"イベントは、多数の ゾーンにサービスを提供する環境では一般的である。手順は、ゾーン に初めて鍵が導入される場合だけでなく、"通常状態"すなわち通常の ゾーン保守の一環としてレコードが置き換えられる場合にも対処できる べきである。 o 鍵の漏洩が検知された後、可能な限り早くゾーンの緊急再署名を行える ようにするため、スタンバイ鍵(ゾーンの署名に使用される鍵以外の追加 の鍵)が存在する必要がある。 o DNSKEY RRsetへの問合わせに対しては、ゾーン内の全てのDNSKEYレコード が返される。(EDNS0のサポートがあったとしても)UDPパケットの容量は 限られているので、もはや使用されない鍵レコードは定期的に削除され なければならない。(同じ理由で、ゾーン内のスタンバイ鍵の数は、 鍵管理ポリシーをサポートするために必要な最小限の数に制限すべき である)。 鍵をどの程度の期間使用するかといった管理ポリシーも検討される必要が ある。しかし、鍵管理ロジックの核心は、ロールオーバーがある時点で完了 していることを保証することではなく、ゾーンで公開されている鍵の状態が、 変更しても"安全"な状態になるまで変更されないことを保証することである (このコンテキストの"安全"とは、ロールオーバープロセスの期間中、 ゾーンのどの部分も"Bogus"にならないことを意味する)。言い換えると、 鍵管理ロジックはポリシーを強制するが、そのポリシーは厳格に施行 されない可能性がある。 Morris, et al. Informational [Page 3] RFC 7583 Key Timing October 2015 鍵のロールオーバーの大まかな概要は[RFC6781]で得られる。対照的に 本文書は、[RFC6781]に記述された2つのクラスの操作、ゾーン署名鍵(ZSK) のロールオーバーと鍵署名鍵(KSK)のロールオーバーに関して、具体的レベル でタイミングの詳細に焦点を当てる。 ゾーンに鍵を導入するプロセスは、鍵のロールオーバーとは異なることに 注意せよ。詳細についてはセクション3.3.5を参照せよ。 1.2. 鍵の種類 DNSSECの署名検証は、全ての鍵を同等に扱うが、[RFC4033]では、ZSKとKSK に大きく分類している。ZSKはゾーン内の情報を認証するために使用され、 KSKはゾーンのDNSKEY RRsetを認証するために使用される。この違いは主に、 ロールオーバー中の情報の一貫性に影響する。 ロールオーバー期間中、署名を検証するリゾルバーは、認証を実行する際 に別々の情報を使用しなければならない。認証の時点で、ある情報は キャッシュ内にあるかもしれないし、ある情報は権威サーバーから取得する 必要があるかもしれない。ロールオーバープロセスは、ロールオーバーの 全期間に渡って情報が一貫するように生じる必要がある。ZSKの場合、 この情報はRRSIG(と関連するRRset)とDNSKEYになる。これらは、どちらも 同じゾーンから取得される。KSKの場合、この情報はDNSKEY RRsetとDS RRset になるが、後者は別のゾーンから取得される。 ZSKとKSKをロールオーバーするためのアルゴリズムには類似点もあるが、 多くの違いが存在する。このため、2種類のロールオーバーを別々に記述 する。 1.3. 用語 本文書で使用される用語は、[RFC4033]と[RFC5011]で定義されたとおりの ものである。 時刻、期間などを識別するために多くの記号が使用されている。その一覧 は付録Aで得られる。 Morris, et al. Informational [Page 4] RFC 7583 Key Timing October 2015 1.4. 対象範囲の限定 本文書は、発行時点の最新の考え方を示すものである。しかし、題材は進化 しており、この文書を包括的なものにすることはできない。特に、以下は カバーしていない。 o ZSKとKSKの両方として使用されている鍵のロールオーバー。 o アルゴリズムのロールオーバー。ここでは、同一アルゴリズムの鍵の ロールオーバーだけを記述する。アルゴリズムの移行については扱わない。 o TTLの変更。 アルゴリズムのロールオーバーに関しては、DNSKEY RRsetに含まれる アルゴリズムそれぞれについて、少なくとも1つのDNSKEYに対応するRRSIGが 存在している必要があることから、本文書では除外する。先の必要性は ロールオーバーに更なる制約をもたらすが、本文書では検討しない。 そのような検討は、ロールオーバー中に鍵の他の特性、例えば鍵長が変更 されるような場合には適用されないからである。DNSSECプロトコルは、 そのような場合に何も制限を課していない。 ゾーン内のレコードのTTLを変更した場合の影響についても、検討からは 除外する。TTLはいつでも変更できるが、鍵のロールオーバー近辺でそれを 行うと、イベントのタイミングに影響があるかもしれない。後ほど示す タイムラインでは、TTLは一定だと想定している。 2. ロールオーバー方式 2.1. ZSKのロールオーバー ZSKの場合、ゾーン管理者/署名者の課題は、特定の署名にアクセスできる キャッシングバリデーターが、対応する有効なZSKにもアクセスできると 保証することである。 ZSKは、以下の3通りの方法のうちの1つでロールオーバー可能である。 o 事前公開法: [RFC6781]に記述。新しい鍵がDNSKEY RRsetに導入され、 その後古い鍵で再署名される。イベントの状態は、キャッシュされた DNSKEY RRsetに両方の鍵が含まれることが保証される程度に十分長い 時間維持される。その時点で、古い鍵で作成された署名を新しい鍵で 作成された署名に置き換えられるようになる。再署名プロセス中は (ゾーン管理方法に応じて、アトミックに行われるかもしれないし、 そうでないかもしれない)、リゾルバーに取得されたRRSIGレコードを 作成したのがどちらの鍵であったかは問題にならない。キャッシュ されたDNSKEY RRsetのコピーには、古い鍵も新しい鍵も含まれるから である。 Morris, et al. Informational [Page 5] RFC 7583 Key Timing October 2015 ゾーンに含まれるものが新しい鍵で作成された署名だけになってから、 古い鍵で作成されたRRSIGレコードのキャッシュ期限が満了するまで には時間差が存在する。それ以降は、古い鍵を使用して作成された署名 はどこにも存在しなくなるので、DNSKEY RRsetから削除できるように なる。 o 二重署名法: これも[RFC6781]に記述されている。これは、新しい鍵の ゾーンへの導入と、新しい鍵を使用した追加のRRSIGレコード作成を必要 とする。古い鍵と既存のRRSIGレコードは維持される。ゾーンが署名 されている期間中 (署名プロセスは、アトミックかもしれないしそうでは ないかもしれない)、署名検証をするリゾルバーは常にRRSIGを署名検証 できる。古いDNSKEY RRsetとRRSIG、新しいDNSKEY RRsetとRRSIGの どちらかの組み合わせにより、少なくとも1つの署名は検証できるから である。 署名プロセスが完了し、DNSKEYと署名をキャッシュ内に保持する バリデーターが古い情報と新しい情報の両方を持つことが保証される 程度に十分長い時間が経過すると、古い鍵と署名をゾーンから削除 できるようになる。この期間中は先ほどと同様に、新旧どちらかの DNSKEY RRsetとRRSIGの組み合わせにより、少なくとも1つの署名は 検証できる。 o 二重RRSIG法: 厳密に言えば、先の"二重署名法"という用語の使用は誤用 である。というのも、この方法は2つの署名だけではなく、2つの鍵も使用 するからである。真の二重署名法(ここでは二重RRSIG法と呼ぶ)は、 ゾーンに(古い署名を残したまま)新しい署名を導入するが、新しい鍵は 導入しない。 署名プロセスが完了し、RRと関連付けられたRRSIGを保持する可能性が ある全てのキャッシュが新旧両方のコピーを持つことが保証される程度 に十分な時間が経過した後に、鍵が変更される。古いDNSKEY RRsetが キャッシュから廃棄されるまでの期間がさらに経過すると、ゾーンから 古い署名が削除される。 3つの方法の中では、二重署名法が概念的に最もシンプルである。新しい鍵 と新しい署名を導入し、約1TTL後に古い鍵と古い署名を削除する。また 最も高速にロールオーバー可能だが、ゾーンサイズと応答サイズが大きく なるという難点がある。 事前公開法はより複雑である。新しい鍵を導入し、約1TTL後に新しい鍵で レコードに署名し、約1TTL後に古い鍵を削除する。しかし、ゾーンと応答の サイズは最小限に抑えられる。 Morris, et al. Informational [Page 6] RFC 7583 Key Timing October 2015 二重RRSIG法は、本質的に事前公開法の逆である。新しい署名を導入し、 約1TTL後に鍵を変更し、約1TTL後に古い署名を削除する。しかし、ロール オーバーに要する時間という点では事前公開法の欠点を持ち、ゾーンと応答 のサイズという点では二重署名法の欠点を持つ。そして、どちらの利点も 持たない。このような理由により、実世界の状況で使用される可能性は低い ため、本文書ではこれ以上検討しない。 2.2. KSKのロールオーバー KSKの場合、キャッシングバリデーターが有効なKSKで作成された署名に アクセスできなくても、問題は生じないはずである。KSKは、(DNSKEY RRset に対する)ただ1つの署名だけのために使用され、鍵と署名は一緒に配送 される。課題はむしろ、KSKが信頼できる状態を保証することにある。 KSKの信頼は、署名されその署名が検証されたDSレコードが親ゾーンに存在 することか、トラストアンカーが明示的に設定されているかのどちらかに 由来する。前者であれば、ロールオーバーアルゴリズムは、DSレコードの 追加と削除の部分で親ゾーンの関与が必要なため、タイミングはゾーン 管理者の完全な管理下にはならない。後者の場合、[RFC5011]のタイミング が鍵のロールオーバーに必要となる。(認証がDSレコードによる場合で あっても、ゾーン管理者は、鍵がトラストアンカーとして明示的に設定 されている可能性に対処するため、鍵のロールオーバープロセスに[RFC5011] タイミングを含めると選択してもよい)。 親とやりとりを行う必要性は、鍵のロールオーバーロジックの開発を 妨げないことに留意することが重要である。ロールオーバーロジックの目標 が、状態を変更しても"安全"になるのはいつかを判断できることにあるの なら、親に依存することの唯一の影響は、鍵のロールオーバーロジックが 要求する何らかの遅延に加えて、親が対応してくれるのを待つ期間がある かもしれないことだけである。これは追加の遅延をもたらすが、理想的に 応答しない親であっても、その影響は、ロールオーバーの状態遷移が遅く なるだけである。これによりポリシー違反が発生する可能性はあるが、 運用上の問題は生じない。 ZSKと同様に、KSKをロールオーバーする方法は以下の3つである。 o 二重KSK法: 新しいKSKがDNSKEY RRsetに追加され、新旧両方の鍵で署名 される。古いRRsetがキャッシュから廃棄されるのを待った後、親ゾーン のDSレコードが変更される。この変更がキャッシュに反映されるまで さらなる期間待機した後、古い鍵がRRsetから削除される。 Morris, et al. Informational [Page 7] RFC 7583 Key Timing October 2015 o 二重DS法: 新しいDSレコードが公開される。この変更がキャッシュに 伝播されるのを待った後、KSKが変更される。古いDNSKEY RRsetが キャッシュから廃棄されるまでさらなる期間待機した後、古いDSレコード が削除される。 o 二重RRset法: 新しいKSKがDNSKEY RRsetに追加され、新旧両方の鍵で 署名される。同時に、新しいDSレコードが親ゾーンに追加される。 古いDSとDNSKEY RRsetがキャッシュから廃棄されるまでの適当な期間 待機した後、古いDNSKEYレコードとDSレコードが削除される。 二重KSK法は本質的に、新しいKSKがまず導入され、それを使用してDNSKEY RRsetが署名されることを意味する。DSレコードが変更され、最後に古いKSK が削除される。親とのやり取りは最小限に制限されるが、ロールオーバー 期間中はDNSKEY RRsetのサイズが増加する。 二重DS法では、作業の順番が逆になり、新しいDSの導入、DNSKEYの変更、 古いDSの削除となる。DNSKEY RRsetのサイズは最小に保たれるが、親との やり取りは2回必要になる。 最後に、二重RRset法はKSKをロールオーバーする最速の方法だが、他の 2つの方法の欠点を併せ持つ。つまり、DNSKEY RRsetは大きくなり、 親とのやり取りが2回発生する。 3. 鍵のロールオーバーのタイムライン 3.1. 鍵の状態 DNSSEC署名検証は、DNSKEYと、そこから作成された情報(本セクションでは "関連データ"と呼ぶ)の両方を必要とする。RRを署名検証する場合、鍵の 関連データは、対応するRRSIGである。信頼の連鎖を検証する必要がある 場合、関連データはDSレコードである。 ロールオーバープロセスの期間中、鍵は、様々な状態に変化する。定義 されている状態は以下のとおりである。 Generated 鍵は、初めて使用する直前に作成してもよいが、一部の実装 では、1回の操作で鍵のプールを作成しておき、必要に応じて そこから取り出すのが便利だと判断している。(注: このような 事前作成されたプールは、密かに使用されないように保護され なければならない)。後ほど示すタイムラインでは、最初の イベントの前に、鍵は作成されたがまだ使用されていない状態 と見なされる。これを"Generated"状態と呼ぶ。 Morris, et al. Informational [Page 8] RFC 7583 Key Timing October 2015 Published 鍵または鍵の関連データが適切なゾーンに現れた時、鍵は Published状態になる。 Ready DNSKEYまたはDNSKEYの関連データが公開されてから、置き換え られようとしている鍵(またはその鍵の関連データ)のコピーが キャッシュから廃棄されていることが保証される程度に十分に 長い時間が経過した状態。 Active データは、署名検証で使用され始めている。ZSKの場合、その鍵 がRRsetへの署名で使用されており、鍵と作成したRRSIGの両方 がゾーンに現れていることを意味する。KSKの場合、DNSKEYとDS レコードの両方が、それぞれ対応するゾーンに存在するので、 DNSKEY RRsetの署名検証に使用できることを意味する。この 状態に移行しても、署名を検証するリゾルバーがいかなる場合 でもこのデータを使用して署名検証できるとは限らないことに 注意せよ。ゾーン署名作業が終わっていないかもしれないし、 伝播遅延、キャッシュの問題のどちらかあるいは両方が原因で、 データがリゾルバーに届かないかもしれないからである。その 場合リゾルバーは、代わりに一世代前のデータに頼らなければ ならない。 Retired データは、署名検証で使用されなくなっている。ZSKの場合、 その鍵がRRsetの署名に使われなくなったことを意味する。 KSKの場合、後継のDNSKEYとDSレコードが存在していることを 意味する。どちらの場合も、鍵(と関連データ)は、削除しても 安全になったら、すなわち署名検証をするリゾルバー全てが 新しい鍵とその関連データを使用してゾーンを署名検証できる ようになったら、すぐに削除できる。しかし、そうなるまでは、 現在の鍵とその関連データは、それぞれのゾーンで維持され なければならない。 Dead 鍵と鍵の関連データは、それぞれのゾーン内に存在するが、 署名検証で使用するためにそれらの存在を必要とする情報は もはやどこにもない。したがって、いつでも削除できる。 Removed DNSKEYとその関連データは、それぞれのゾーンから削除されて いる。 Revoked DNSKEYは、"失効(revoke)"ビットが設定された状態で一定期間 公開される。これは、その鍵が[RFC5011]方式でトラスト アンカーとして設定されている署名を検証するリゾルバーに 対し、その鍵がゾーンから削除されようとしていることを通知 する手段である。[RFC5011]の考慮点が当てはまる場合に、 この状態が使用される(セクション3.3.4参照)。 Morris, et al. Informational [Page 9] RFC 7583 Key Timing October 2015 3.2. ZSKのロールオーバーのタイムライン 以下のセクションで、ZSKのロールオーバーについて記述する。ある鍵("鍵N" と呼ぶ)のライフタイムにおけるイベントを示し、その後継("鍵N+1")への 置き換えをカバーする。 3.2.1. 事前公開法 この方法では、まず新しい鍵がDNSKEY RRsetに導入される。キャッシュ されたDNSKEY RRsetが両方の鍵を含むことを保証できるほど十分に長い時間 の後、新しい鍵を使用してゾーンが署名され、古い署名は削除される。最後 に、古い鍵で作成された全ての署名がキャッシュから廃棄されると、古い鍵 が削除される。 以下の図は、事前公開法によるロールオーバーのタイムラインを示して いる。時間は、横軸の目盛りに沿って左から右へと進んでいき、縦軸は プロセス中のイベントを示す。重要な時刻と期間には記号が付与される。 |1| |2| |3| |4| |5| |6| |7| |8| | | | | | | | | 鍵N |<-Ipub->|<--->|<-------Lzsk------>|<-Iret->|<--->| | | | | | | | | 鍵N+1 | | | |<-Ipub->|<-->|<---Lzsk---- - - | | | | | | | | 鍵N Tpub Trdy Tact Tret Tdea Trem 鍵N+1 Tpub Trdy Tact ---- 時間 ----> 図1: 事前公開法によるZSKのロールオーバーのタイムライン イベント1: 鍵NのDNSKEYレコードがゾーンに投入される。すなわち、鍵Nの DNSKEYがDNSKEY RRsetに追加され、現在ActiveなKSKによって再署名される。 これが生じた時刻が公開時刻(Tpub)であり、この時点で鍵はPublishedだと 見なされる。この鍵は、まだレコードの署名には使用されていないことに 注意せよ。 イベント2: 鍵が使用可能になるまでに、キャッシュされたゾーンのDNSKEY RRsetにその鍵が含まれることが保証される程度に十分長い間、その鍵が 公開されていなければならない。 この期間は公開期間(Ipub)で、ゾーン内で2つめ以降の鍵の場合、次式で 与えられる。 Ipub = Dprp + TTLkey Morris, et al. Informational [Page 10] RFC 7583 Key Timing October 2015 ここで、Dprpは伝播遅延、すなわちマスターに導入された変更が全ての ネームサーバーに複製されるまでに要する時間である。TTLkeyは、ゾーン 内のDNSKEYレコードのTTLである。したがってこの合計は、既存のDNSKEY レコードがキャッシュから廃棄されるまでに要する時間の最大値となる。 この値は、既存のDNSKEYがどのネームサーバーから取得されたかには無関係 である。 (ゾーンに初めてZSKを導入する場合については、セクション3.3.5で説明する)。 Ipubの遅延の後、鍵はReadyと見なされ、レコードの署名に使用できるように なる。 このイベントが発生する時刻が鍵Nの準備完了時刻(Trdy)であり、 次式で与えられる。 Trdy(N) = Tpub(N) + Ipub イベント3: 若干の時間が経過した後に、鍵がRRsetの署名に使用され始める。 この時点がアクティベーション時刻(Tact)で、これ以後、鍵NはActiveと 見なされる。 Tact(N) >= Trdy(N) イベント4: ある時点で、後継(鍵N+1)について検討しなければならない。 現在Activeな鍵をゾーンに導入した時のように、後継の鍵も、アクティベーション より少なくともIpub前に公開されている必要がある。鍵N+1の公開時刻は、 鍵Nのアクティベーション時刻に依存する。 Tpub(N+1) <= Tact(N) + Lzsk - Ipub ここで、LzskはZSKが使用される期間の長さ(ZSKのライフタイム)である。 図中には、実際の鍵のライフタイムが表示されていることに注意すべき である。これは、鍵管理ポリシーによって設定される意図されたライフ タイムとは若干異なる可能性がある。 イベント5: 鍵NがActiveな間に、後継の鍵がReadyになる。この時点以降、 ゾーンへの署名に鍵N+1が使用できる。 イベント6: 鍵NがZSKのライフタイムに等しい期間使用された段階で、鍵N はRetiredになり(新たに署名を生成されるために使用されることは二度と なくなる)、鍵N+1がアクティベーションされゾーンの署名に使用される。 ここが鍵Nのリタイア時刻(Tret)となり、次式で与えられる。 Tret(N) = Tact(N) + Lzsk この時刻は、後継の鍵N+1のアクティベーション時刻でもある。運用上の 考慮により、鍵管理ポリシーで設定されたライフタイムより長い(または 短い)期間、鍵Nが使用され続けられる可能性があることに注意せよ。 Morris, et al. Informational [Page 11] RFC 7583 Key Timing October 2015 イベント7: Retiredになった鍵は、その鍵を使用して生成されたあらゆる RRSIGレコードがゾーンで公開されているかまたはキャッシュに保持されて いる間は、ゾーン内に維持される必要がある。(署名を検証するリゾルバー のキャッシュに古いRRSIGレコードは保持されているが、古いDNSKEY RRset は廃棄されたという状況で、クライアントからその両方を提供するように 依頼される可能性がある。その場合、DNSKEY RRsetを再度検索する必要が ある)。これは、鍵がレコードの署名に使用されなくなっても、少なくとも 次式で与えられるリタイア期間(Iret)の間はゾーン内に維持されるべき であることを意味する。 Iret = Dsgn + Dprp + TTLsig Dsgnは、既存の全RRsetが新しい鍵で再署名されていることを保証するために 必要な遅延である。Dprpは更新されたゾーン情報が全スレーブサーバーに 到達したことを保証するために必要な伝播遅延で、TTLsigは現在Retiredに なっている鍵で作成されたゾーン内の全RRSIGレコードのTTLの最大値である。 この鍵で作成された全RRSIGレコードがリゾルバーキャッシュから廃棄される 時刻が機能終了時刻(Tdea)で、次式で与えられる。 Tdea(N) = Tret(N) + Iret この時点で、鍵はDeadと見なされる。 イベント8: 鍵がDeadになった後はいつでも、その鍵をゾーンのDNSKEY RRset から削除できる。削除後は現在のKSKで再署名されなければならない。この 時刻が削除時刻(Trem)で、次式で与えられる。 Trem(N) >= Tdea(N) この時点で、鍵はRemovedと見なされる。 3.2.2. 二重署名法 このロールオーバー手法では、新しい鍵が導入され直ちにゾーンの署名に 使用される。古い鍵と署名は維持される。キャッシュされたDNSKEY、RRSIG のどちらかあるいは両方の情報が、新しいDNSKEYや新しいDNSKEYで作成 されたRRSIGのコピーを含むようになると、古いDNSKEYやRRSIGをゾーンから 削除できるようになる。 二重署名法によるロールオーバーのタイムラインを以下に示す。この図は、 セクション3.2.1で説明した慣例に従っている。 Morris, et al. Informational [Page 12] RFC 7583 Key Timing October 2015 |1| |2| |3| |4| | | | | 鍵N |<-------Lzsk----------->|<--->| | | | | | |<--Iret-->| | | | | | 鍵N+1 | |<----Lzsk------- - - | | | | 鍵N Tact Tdea Trem 鍵N+1 Tact ---- 時間 ----> 図2: 二重署名法によるZSKのロールオーバーのタイムライン イベント1: 鍵NがDNSKEY RRsetに追加され、ゾーンの署名に使用される。 ゾーン内の既存の署名は削除されない。鍵はPublishedでもあり、Active でもある。この時刻が鍵Nのアクティベーション時刻(Tact)で、これ以降、 鍵はActiveと見なされる。 イベント2: 現在の鍵(鍵N)の実際の有効期間(Lzsk)の終了が近づくと、 後継の鍵(鍵N+1)がゾーンに導入され、 RRsetの署名に使用され始める。 現在の鍵も、その鍵で作成された署名も削除されない。 この時点で、 後継の鍵もActiveになっている。 Tact(N+1) = Tact(N) + Lzsk - Iret イベント3: 鍵Nがゾーンから削除できるようになるまでに、署名されて いる必要のあるRRsetは全て後継の鍵(鍵N+1)で署名されていなければならず、 新しい鍵や新しいRRSIGを含まない古いRRsetはキャッシュから廃棄されて いなければならない。署名は置き換えられるわけではないことに注意せよ。 各RRsetは、古い鍵と新しい鍵の両方で署名される。 これにはリタイア期間Iretを要する。Iretは次式で与えられる。 Iret = Dsgn + Dprp + max(TTLkey, TTLsig) 先ほどと同様に、Dsgnは、既存の全RRsetが新しい鍵で署名されている ことを保証するために必要な遅延で、Dprpは、更新されたゾーン情報が 全スレーブサーバーに到達していることを保証するために必要な遅延である。 最後の項(TTLkeyとTTLsigの最大値)は、鍵Nと鍵Nに関連する署名データが キャッシュから廃棄されるまで待機する期間である。(TTLKeyはDNSKEY RRsetのTTLで、TTLsigはZSKで作成されたゾーン内の全RRSIGレコードの TTLの最大値である。この2つは異なる可能性がある。 Morris, et al. Informational [Page 13] RFC 7583 Key Timing October 2015 RRSIGのTTLは、関連付けられたRRsetのRRと同じになるが[RFC4034]、DNSKEY RRsetに署名する必要があるのはKSKだけだからである)。 この期間が終わると、鍵NはDeadと見なされる。これが発生する時刻が機能 終了時刻(Tdea)で、次式で与えられる。 Tdea(N) = Tact(N+1) + Iret イベント4: 若干の時間が経過すると、鍵Nと鍵Nで作成された署名をゾーン から削除できるようになる。この時刻が削除時刻(Trem)で、次式で与え られる。 Trem(N) >= Tdea(N) 3.3. KSKのロールオーバーのタイムライン 以下のセクションで、KSKのロールオーバーについて記述する。ある鍵("鍵N" と呼ぶ)のライフタイムにおけるイベントを示し、その後継("鍵N+1")への 置き換えをカバーする。(ゾーンに初めてKSKを導入する場合については、 セクション3.3.5で説明する)。 3.3.1. 二重KSK法 このロールオーバー手法では、まず新しい鍵がDNSKEY RRsetに導入される。 キャッシュされたDNSKEY RRsetが新しいDNSKEYを含むことを保証できる程度 十分に長い時間の後、親ゾーンのDSレコードが変更される。古いDSレコード がキャッシュから廃棄されるまでさらなる期間を待機した後、古いDNSKEYが ゾーンから削除される。 二重KSK法によるロールオーバーのタイムラインを以下に示す。この図は、 セクション3.2.1で説明した慣例に従っている。 Morris, et al. Informational [Page 14] RFC 7583 Key Timing October 2015 |1| |2| |3| |4| | | | | 鍵N |<-IpubC->|<--->|<-Dreg->|<-----Lksk--- - - | | | | 鍵N+1 | | | | | | | | 鍵N Tpub Trdy Tsbm Tact 鍵N+1 ---- 時間 ----> (上の続き) |5| |6| |7| |8| |9| |10| | | | | | | 鍵N - - --------------Lksk------->|<-Iret->|<----->| | | | | | | 鍵N+1 |<-IpubC->|<--->|<-Dreg->|<--------Lksk----- - - | | | | | | 鍵N Tret Tdea Trem 鍵N+1 Tpub Trdy Tsbm Tact ---- 時間 ----> 図3: 二重KSK法によるKSKのロールオーバーのタイムライン イベント1: 鍵NのDNSKEYレコードがゾーンに投入される。すなわち、鍵Nの DNSKEYがDNSKEY RRsetに追加され、現在Activeな全てのKSKによって再署名 される。(この時点でDNSKEY RRsetは、鍵N自身とその先任のKSKの両方に よって署名される。他にもActiveなKSKがあれば、そのKSKでも署名される)。 この時刻が鍵Nの公開時刻(Tpub)で、これ以降、鍵はPublishedと見なされる。 イベント2: 鍵が使用できるようになる前の段階で、DNSKEY RRsetのコピーを キャッシュしている署名を検証するリゾルバーが、その鍵を含むRRsetのコピー を保持していることが保証される程度に十分長い間、その鍵が公開されて いなければならない。言い換えると、以前にキャッシュされていたあらゆる DNSKEY RRsetに関する情報は、廃棄されていなければならない。 この期間は子ゾーンの公開期間(IpubC)で、次式で与えられる。 IpubC = DprpC + TTLkey Morris, et al. Informational [Page 15] RFC 7583 Key Timing October 2015 ここでDprpCは、子ゾーン(ロールオーバー中のKSKを含むゾーン)の伝播遅延 で、TTLkeyは、DNSKEY RRsetのTTLである。これが発生する時刻が鍵Nの準備 完了時刻(Trdy)で、次式で与えられる。 Trdy(N) = Tpub(N) + IpubC イベント3: 若干の時間が経過した後に、新しいKSKに対応するDSレコード が、公開のために親ゾーンに提出される。次式で与えられるこの時刻が 提出時刻(Tsbm)である。 Tsbm(N) >= Trdy(N) イベント4: DSレコードが親ゾーンで公開される。この時点で、認証で使用 される全情報、DNSKEYレコードとDSレコードの両方が2つのゾーンで利用可能 になるので、他のロールオーバー手法にあわせて、次式で与えられるこの 時刻を鍵Nのアクティベーション時刻(Tact)とする。 Tact(N) = Tsbm(N) + Dreg ここで、Dregは登録遅延で、DSレコードが親ゾーン管理者に提出されてから ゾーンに配置されるまでの時間である。(親ゾーンは、大抵異なるエンティティ によって管理されているため、この用語は、レコードを転送する組織的な オーバーヘッドを参照する。実際には、Dregは固定長の時間ではない。 代わりに、Dregの終了は、親ゾーンにDSレコードが現れることで通知される)。 イベント5: 鍵NがActiveな間に、後継(鍵N+1)について検討しなければ ならない。予定されているKSKのライフタイム終了より少し前に、後継の KSKがゾーンに公開される。(先ほどと同じように、これは、DNSKEY RRset が全てのKSKで署名されることを意味する)。この時刻が後継の鍵N+1の公開 時刻で、次式で与えられる。 Tpub(N+1) <= Tact(N) + Lksk - Dreg - IpubC ここで、LkskはKSKの実際のライフタイムで、Dregは登録遅延である。 イベント6: IpubCの期間の後に、(DNSKEY RRsetのコピーを持つ全キャッシュ がこの鍵を持っているので)鍵N+1はReadyになる。この時刻が、後継の鍵N+1 の準備完了時刻(Trdy)である。 イベント7: 後継の鍵N+1の提出時刻Tsbm(N+1)になると、鍵N+1に対応する DSレコードが親ゾーンに提出される。 Morris, et al. Informational [Page 16] RFC 7583 Key Timing October 2015 イベント8: 後継のDSレコードが親ゾーンで公開され、現行のDSレコードは 取り下げられる。鍵NはRetiredになったと見なされる。これが発生する時刻 がTret(N)で、次式で与えられる。 Tret(N) = Tsbm(N+1) + Dreg イベント9: 鍵Nは、DS RRsetのコピーを含むあらゆるキャッシュが新しい DSレコードを含むコピーを持つまでは、ゾーン内に留めておかなければ ならない。この期間がリタイア期間で、次式で与えられる。 Iret = DprpP + TTLds ここでDprpPは、親ゾーンの伝播遅延で、TTLdsは、親ゾーンのDSレコード のTTLである。 その鍵はもう何にも使用されないので、Deadと見なされる。この時点が 機能終了時刻(Tdea)で、次式で与えられる。 Tdea(N) = Tret(N) + Iret イベント10: 若干の時間が経過すると、(削除時刻Tremに)鍵Nがゾーンの DNSKEY RRsetから削除される。この時点で、鍵はRemovedと見なされる。 Trem(N) >= Tdea(N) 3.3.2. 二重DS法 このロールオーバー手法では、新しいDSレコードがまず親ゾーンで公開 される。キャッシュに含まれるDS RRsetの中に新しいレコードのコピーが 含まれるようになったならば、ゾーンのKSKが変更される。古いDNSKEY RRsetがキャッシュから削除されるまでさらなる時間待機した後、古いDS レコードが親から削除される。 二重DS法によるロールオーバーのタイムラインを以下に示す。この図は、 セクション3.2.1で説明した慣例に従っている。 Morris, et al. Informational [Page 17] RFC 7583 Key Timing October 2015 |1| |2| |3| |4| |5| | | | | | 鍵N |<-Dreg->|<-IpubP->|<-->|<-------Lksk---- - - | | | | | 鍵N+1 | | | | |<--Dreg-- - - | | | | | 鍵N Tsbm Tpub Trdy Tact 鍵N+1 Tsbm ---- 時間 ----> (上の続き) |6| |7| |8| |9| |10| | | | | | 鍵N - ----------Lksk--------->|<-Iret->|<---->| | | | | | 鍵N+1 - --Dreg-->|<-IpubP->|<-->|<---Lksk------- - - | | | | | 鍵N Tret Tdea Trem 鍵N+1 Tpub Trdy Tact ---- 時間 ----> 図4: 二重DS法によるKSKのロールオーバーのタイムライン イベント1: 公開のため、DS RRが親ゾーンに提出される。この時刻が提出 時刻Tsbmとなる。 イベント2: 登録遅延Dregの後、親ゾーンでDSレコードが公開される。 この時刻が鍵Nの公開時刻(Tpub)で、次式で与えられる。 Tpub(N) = Tsbm(N) + Dreg 先ほどと同じように、Dregは実際には固定長の時間ではない。代わりに、 Dregの終了は、親ゾーンにDSレコードが現れることで通知される。 イベント3: 若干の時間が経過すると、DS RRsetのコピーを持つキャッシュ は、鍵NのDSレコードのコピーを持つようになる。この時点で、鍵NをDNSKEY RRsetに導入すれば、ゾーンの署名検証に使用できる状態になる。このため、 この時刻が準備完了時刻(Trdy)で、次式で与えられる。 Trdy(N) = Tpub(N) + IpubP Morris, et al. Informational [Page 18] RFC 7583 Key Timing October 2015 IpubPは、(親ゾーンにおける)DSレコードの公開期間で、次式で与えられる。 IpubP = DprpP + TTLds ここで、Drprは親ゾーンの伝播遅延で、TTLdsはそのゾーンのDSレコードに 割り当てられたTTLである。 イベント4: 若干の時間が経過すると、鍵のロールオーバーが行わる。すなわち、 新しい鍵(鍵N)がDNSKEY RRsetに導入され、署名に使用されるようになる。 この時刻が鍵Nのアクティベーション時刻(Tact)で、これ以降、鍵NはActive と見なされる。 Tact(N) >= Trdy(N) イベント5: ある時点で、鍵の置き換えを検討しなければならない。後継の 鍵に対応するDSレコードは、現行の鍵が取り下げられるとき、ゾーンのDS レコードを含むキャッシュが後継の鍵のDSレコードデータを持てるように、 時間を考慮して親ゾーンに提出されなければならない。これが発生する 時刻が後継の鍵N+1の提出時刻で、次式で与えられる。 Tsbm(N+1) <= Tact(N) + Lksk - IpubP - Dreg ここで、Lkskは鍵Nの実際のライフタイム(鍵管理ポリシーで設定された ライフタイムとは多少異なる可能性がある)で、Dregは登録遅延である。 イベント6: 期間Dregの後、後継のDSレコードが親ゾーンで公開される。 イベント7: 後継の鍵(鍵N+1)がReady状態になる。すなわち、親ゾーンの DS RRsetのキャッシュに鍵N+1のDSレコードが含まれるようになる。 イベント8: 鍵NがActiveなライフタイム(Lksk)が終了すると、DNSKEY RRset 内で鍵N+1に置き換えられ、そのRRsetは新しい鍵で署名される。この時点で、 新旧両方のDSレコードがDS RRsetのキャッシュに含まれていると保証される 程度に十分長い間親ゾーンで公開されているので、ロールオーバー期間中を 通してゾーンは認証可能である。署名を検証するリゾルバーは、古いKSKか 新しいKSKのどちらかで認証を行える。 この時刻が鍵Nのリタイア時刻(Tret)で、次式で与えられる。 Tret(N) = Tact(N) + Lksk この時刻は、鍵N+1のアクティベーション時刻でもある。 Morris, et al. Informational [Page 19] RFC 7583 Key Timing October 2015 イベント9: 若干の時間が経過すると、古いDNSKEY RRsetのコピー全てが キャッシュから廃棄され、古いDSレコードは不要になる。他のロールオーバー 手法にあわせて、この時刻を機能終了時刻(Tdea)とする。この時刻は次式で 与えられる。 Tdea(N) = Tret(N) + Iret ここで、Iretはリタイア期間で、次式で与えられる。 Iret = DprpC + TTLkey 先ほどと同様に、この用語には、DprpCすなわちRRsetの変更が子ゾーンの マスター－スレーブ階層を介して伝播するために必要な時間と、TTLkey すなわちDNSKEY RRsetがキャッシュから廃棄されるまでに必要な時間が 含まれる。 イベント10: 若干の時間が経過すると、DSレコードは親ゾーンから削除 される。他のロールオーバー手法にあわせて、この時刻を削除時刻(Trem) とする。この時刻は次式で与えられる。 Trem(N) >= Tdea(N) 3.3.3. 二重RRset法 二重RRset法によるロールオーバーでは、新しいDNSKEYレコードとDSレコード が、適切なゾーンでそれぞれ同時に公開される。古いDNSKEY RRsetとDS RRsetがキャッシュから廃棄される程度に十分な時間が経過すると、古い DNSKEYレコードとDSレコードがそれぞれのゾーンから削除される。 このロールオーバー手法のタイムラインを以下に示す。この図は、 セクション3.2.1で説明した慣例に従っている。 |1| |2| |3| |4| |5| | | | | | 鍵N |<-----------Lksk---------->|<---->| | | | | | | |<------Ipub----->| | | | | | | | |<-Dreg->|<-Iret->| | | | | | | 鍵N+1 | | |<----Lksk-------- - - | | | | | 鍵N Tact Tret Tdea Trem 鍵N+1 Tpub Tact ---- 時間 ----> 図5: 二重RRset法によるKSKのロールオーバーのタイムライン Morris, et al. Informational [Page 20] RFC 7583 Key Timing October 2015 イベント1: DSレコードとDNSKEYレコードがそれぞれのゾーンに現れ、後者 はDNSKEY RRsetに署名するために使用されている。鍵はPublishedでもあり、 Activeでもある。この時刻が鍵Nのアクティベーション時刻(Tact)となる。 イベント2: 現在の鍵(鍵N)の有効期間(Lksk)の終了が近づくと、後継の鍵 (鍵N+1)がゾーンに導入され、DNSKEY RRsetへの署名に使用される。同時に、 後継のDSレコードが親ゾーンに提出される。 この時刻が、後継の鍵の 公開時刻(Tpub)である。 Tpub(N+1) <= Tact(N) + Lksk - Ipub ここで、Ipubは後ほど定義される。 イベント3: 登録遅延(Dreg)の後、DSレコードが親ゾーンに現れる。DNSKEY レコードは既に子ゾーンに存在するので、新しい鍵と新しい鍵の関連データ の両方が見えるようになった。この時刻が鍵のアクティベーション時刻 (Tact)で、鍵はActiveと見なされる。 Tact(N+1) = Tpub(N+1) + Dreg イベント4: 鍵Nと鍵Nの関連データを削除できるようになるまでには、 署名を検証するリゾルバーのキャッシュ内にある全RRsetが、新しいDS、 新しいDNSKEYのどちらかあるいは両方を含む状態にならなければならない。 これが発生する時刻が鍵Nの機能終了時刻(Tdea)で、次式で与えられる。 Tdea(N) = Tpub(N+1) + Ipub Ipubは、以前にキャッシュされていたDNSKEYとDS RRsetに関する情報が 廃棄されていると保証されるまでに必要な期間である。DNSKEYの場合、 これは子の公開期間(IpubC)である。DSの場合、公開期間(IpubP) は、レコードが親ゾーンに現れてから始まるが、それはDSが提出されて からDreg後のことになる。したがって、以下が得られる。 Ipub = max(Dreg + IpubP, IpubC) 親ゾーンの公開期間は次式で与えられる。 IpubP = DprpP + TTLds ここで、DprpPは親ゾーンの伝播遅延で、TTLdsは親ゾーンのDSレコードの TTLである。 Morris, et al. Informational [Page 21] RFC 7583 Key Timing October 2015 子ゾーンの公開期間は、同様の次式で与えられる。 IpubC = DprpC + TTLkey ここで、DprpCは子ゾーンの伝播遅延で、TTLkeyはDNSKEYレコードのTTL である。 他のロールオーバー手法にあわせて、リタイア期間、すなわち鍵がActive になってから、その先任の鍵がDeadと見なされるまでの期間も定義できる。 この場合、Iretは次式で与えられる。 Iret = Ipub - Dreg 言い換えると、先任の鍵のリタイア期間は、親の公開期間と、子の公開期間 から登録遅延を引いた値のうち大きい方になる。 イベント5: 若干の期間が経過すると、鍵NのDSレコードとDNSKEYレコードが、 それぞれのゾーンから削除される。他のロールオーバー手法にあわせて、この 時刻を削除時刻(Trem)とする。削除時刻は次式で与えられる。 Trem(N) >= Tdea(N) 3.3.4. トラストアンカーが設定されている場合の相互作用 ここまでのセクションは、親ゾーンのDSレコードがトラストアンカーに なっているKSKのロールオーバーに関するものであったが、ゾーン管理者は、 一部の署名を検証するリゾルバーがトラストアンカーを直接設定している 可能性を考慮したいと思うかもしれない。 設定されているトラストアンカーのロールオーバーは、[RFC5011]で対処 されている。これを行う場合、トラストアンカーとして使用されているKSK は、使用の一定期間前にゾーンに導入される必要があり、また使用終了後 も一定期間は("失効"ビットを設定して)維持される必要がある。 3.3.4.1. KSKの追加 新しい鍵の導入に際して、二重KSK法および二重RRset法のDNSKEYの公開期間 (IpubC)は、以下のように変更される。 IpubC >= DprpC + max(Itrp, TTLkey) Morris, et al. Informational [Page 22] RFC 7583 Key Timing October 2015 ここで、式の右辺は"トラストポイント"期間(Itrp)を含んでいる。この 用語は、[RFC5011]に従って鍵の自動更新をするように設定されたリゾルバー が、新しい鍵を新しいトラストポイントとして受理していることを保証する ために必要な期間である。この期間は次式で与えられる。 Itrp >= queryInterval + AddHoldDownTime + queryInterval queryIntervalは、[RFC5011]のセクション2.3で定義されており、 AddHoldDownTimeは、同文書のセクション2.4.1で定義されている。 式の第1項(queryInterval)は、署名を検証するリゾルバー全てが新しい鍵 を含むDNSKEY RRsetのコピーを取得していることが保証されるまでの期間 を表現する。新しい鍵を取得した後、署名を検証するリゾルバーは、 AddHoldDownTimeの期間待機する必要がある。その期間内に、新しい鍵が 除外されており、かつ有効に署名されたDNSKEY RRsetが確認されなければ、 次にRRsetが取得された際に、新しい鍵がトラストアンカーとして使用 される。このプロセスは、もう1つのqueryInterval(第3項)の期間を要する 可能性がある。 しかし、[RFC5011]から得られるqueryIntervalの式は、DNSKEYのRRSIGの 残り有効期間を含んでおり、これは、署名を検証するリゾルバーだけが実際 に計算できるパラメーターである。実際には、TTLkeyのみに依存する修正 された問合わせ間隔を使用できる。 modifiedQueryInterval = MAX(1hr, MIN(15 days, TTLkey / 2)) (これは、[RFC5011]のqueryIntervalの式を取り、RRsigExpirationInterval が最悪の値になる場合を想定することで得られる。その値は、有効期間が どのような値でもqueryInterval以上になる)。上の式は、(項をまとめて) 次のようになる。 Itrp >= AddHoldDownTime + 2 * modifiedQueryInterval 二重DS法では、KSK RRを一手順で入れ替えずに、オーバーラップする期間 を設けなければならない。言い換えると、新しいKSKは、入れ替えを行う よりも少なくとも以下の時間前に、ゾーンに導入されていなければならない。 DprpC + max(Itrp, TTLkey) Morris, et al. Informational [Page 23] RFC 7583 Key Timing October 2015 3.3.4.2. KSKの削除 全ての手法について、新しい状態"Revoked"を導入することで、鍵の削除の タイムラインが修正される。鍵が機能終了時刻に到達すると、"Dead"と宣言 される代わりに、Revokedになる。公開されているDNSKEY RRには"失効" ビットが設定され、DNSKEY RRsetは、現在の鍵と失効した鍵の両方で再署名 される。鍵は、次式で与えられる失効期間Irevの間、この状態のまま維持 される。 Irev >= DprpC + modifiedQueryInterval 先と同様に、DprpCは、失効したDNSKEYがスレーブゾーン全てに伝播する までに要する時間で、modifiedQueryIntervalは、RFC 5011準拠の署名を検証 するリゾルバーが、失効した鍵を含むDNSKEY RRsetのコピーを取得している ことが保証されるまでの期間である。 この期間が経過すると、鍵はDeadとなり、ゾーンから削除できるようになる。 3.3.5. 最初の鍵の導入 ゾーンに初めて鍵を導入することに関して、ゾーンへの信頼の連鎖が構築 される前に、ゾーンに鍵が導入され有効に署名されていなければならない ことを除けば、タイミングに関する考慮点は特に存在しない。 親がDNSSEC対応の場合、署名を検証するリゾルバーがDSレコードは取得 できたが、対応するDNSKEYがまだ取得できないという状況になる可能性が なくなるまで、DSレコードは親ゾーンで公開されないと保証しなければ ならないことをことを意味する。親がDNSSEC非対応の場合、つまり信頼の 連鎖や"セキュリティの頂点"を初めて作成する場合、これを保証すること は不可能である。トラストアンカーを設定する前に、ゾーンの全サーバー に新しいKSKが現れるのを待つかは、署名を検証するリゾルバーの運用者 次第である。 4. スタンバイ鍵 鍵は通常、何らかの定期的スケジュールに応じてロールオーバーされるが、 緊急のロールオーバーが必要となる場合もある。例えば、Activeな鍵の漏洩 が疑われる場合などである。緊急ロールオーバーの目的は、可能な限り早く ゾーンを新しい鍵で再署名できるようにすることである。ゾーンに署名する ためには鍵がReady状態でなければならないため、少なくとも1つの追加の 鍵(スタンバイ鍵)を常にReadyにしておくことで、遅延を最小限にできる。 ZSKの場合、スタンバイ鍵が適合するのは事前公開法だけである。スタンバイ DNSKEY RRを恒久的にゾーンに含めておくか、鍵がActiveになった後は できるだけ早く後継の鍵を導入すべきである。 Morris, et al. Informational [Page 24] RFC 7583 Key Timing October 2015 どちらの方法でも、1つ以上の追加のZSKがDNSKEY RRsetに含まれるように なるので、現在の鍵が漏洩した際には、直ちにゾーン署名に使用できる。 (理論上、この方法は二重署名法や二重RRSIG法でも使用できるのだが、 署名を事前に公開する必要がある。スタンバイ鍵は、署名を更新するため に定期的に使用されなければならないため、本質的には恒久的にActive になる。ゾーンもまた、恒久的に2組の署名を必要とする)。 スタンバイKSKを持つことも可能である。二重KSK法では、スタンバイKSKを DNSKEY RRsetに含める必要がある。そうしておけば、鍵のロールオーバー は、親にDSレコードを導入するだけでよくなる。スタンバイKSKは、DNSKEY RRsetの署名に使用されるべきであることに注意せよ。RRsetとその署名は 一緒に伝送されるため、KSKをただ追加するだけでDNSKEY RRsetの署名に 使用しないと、期待される時間短縮は得られない。ロールオーバー後に使用 されるKSKの場合、DNSKEY RRsetはそのKSKで署名されていなければならない ため、(新しい鍵で署名されていない)古いRRsetがキャッシュから廃棄される までの遅延が生じる。 二重RRset法によるロールオーバーにおけるスタンバイKSKのアイディアは、 事実上、2つのActiveな鍵をもつことを意味する(スタンバイKSKと関連するDS レコードは、それぞれのゾーンで同時に公開されるため)。 最後に、二重DS法によるKSKのロールオーバーの場合、存在するものは スタンバイ鍵ではなく、親ゾーンのスタンバイDSレコードである。 どの手法が使用されるにせよ、スタンバイされるデータは、ゾーンに恒久的 に含まれるか、可能な限り早く後継が導入されるかのどちらかである。 5. アルゴリズムに関する考慮点 これまでのセクションは、全ての鍵と署名は単一のアルゴリズムで作成 されることを暗黙の前提としていた。しかし、[RFC4035]のセクション2.2 は、ゾーン頂点にあるDNSKEY RRsetに含まれる各アルゴリズムに関して、 少なくとも1つのDNSKEYを使用したRRSIGが各RRsetに対して存在すること を要求している。 アルゴリズムをロールオーバーする場合(署名の作成に使用される アルゴリズムが変更される場合)を除き、異なるアルゴリズムの鍵の間には、 何の関係もない。これは、これらの鍵を独立にロールオーバーできること を意味する。 Morris, et al. Informational [Page 25] RFC 7583 Key Timing October 2015 言い換えると、先に記述した鍵のロールオーバーロジックは、各アルゴリズム に対して個別に実行できるはずである。その結果を統合したものがゾーン に含まれ、各アルゴリズムのActiveな鍵を使用して署名されることになる。 6. 要旨 ZSKに関しては、事前公開法が一般に望ましい鍵のロールオーバー方法だと 考えられている。本文書に示されるように、ロールオーバーに要する時間 は、ゾーン管理者の制御下にあるパラメーターに完全に依存する。 対照的にKSKに関しては、新しいDSレコードとDNSKEY RRsetを並行に伝播 できるため、二重RRset法が最も効率的である。親ゾーンが署名されている 場合、KSKのロールオーバーに要する時間は、親ゾーンに関連する要因に 依存する可能性がある。ゾーンが[RFC5011]の推奨に準拠しているので あれば、多くの場合、ロールオーバー時間は、RFC 5011で定義される時間 によって決定される。この遅延はポリシー上の選択であって、タイミング 値の関数ではないこと、またトラストアンカーの失効を管理する必要が あることから、ロールオーバープロセスの変更が必要であることは強調 されるべきである。 最後に、緊急時の鍵のロールオーバー処理は、全てのタイプのロール オーバー期間中の標準的な慣行としてスタンバイ鍵を導入することにより 大幅に簡素化される。 7. セキュリティに関する考慮点 本文書は、[RFC4033]、[RFC4034]、[RFC4035]、RFC5011]ですでに議論されて いる以上の新しいセキュリティの問題を導入するものではない。 8. Normative References [RFC4033] Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose, "DNS Security Introduction and Requirements", RFC 4033, DOI 10.17487/RFC4033, March 2005, . [RFC4034] Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose, "Resource Records for the DNS Security Extensions", RFC 4034, DOI 10.17487/RFC4034, March 2005, . [RFC4035] Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose, "Protocol Modifications for the DNS Security Extensions", RFC 4035, DOI 10.17487/RFC4035, March 2005, . Morris, et al. Informational [Page 26] RFC 7583 Key Timing October 2015 [RFC5011] StJohns, M., "Automated Updates of DNS Security (DNSSEC) Trust Anchors", STD 74, RFC 5011, DOI 10.17487/RFC5011, September 2007, . [RFC6781] Kolkman, O., Mekking, W., and R. Gieben, "DNSSEC Operational Practices, Version 2", RFC 6781, DOI 10.17487/RFC6781, December 2012, . Morris, et al. Informational [Page 27] RFC 7583 Key Timing October 2015 付録A. 記号の一覧 本文書は多数の記号を定義している。その全てをここに列挙する。記号は 全て、以下の形式になっている。 ここで、 は、記号のタイプを示す大文字である。定義されているタイプは以下 のとおりである。 D 遅延: プロセスの特性的な期間 I 2つのイベントの間の期間 L ライフタイム: ゾーン管理者に設定された期間 T その時点の時刻 TTL レコードのTTL I、T、TTLは一目瞭然である。DとLは、どちらもIと同様に期間だが、Iの値 が2つのイベントの間の期間であるのに対し、"D"の期間(遅延)はプロセス の特性であり、おそらくはゾーン管理者の管理範囲外のものである。"L"期間 (ライフタイム)はゾーン管理者によって選択されるので、ポリシー上の特性 である。 は小文字で、変数がどのオブジェクトやイベントに関連しているかを 定義する。例えば、 act アクティベーション pub 公開 ret リタイア はオプションの大文字で、異なるゾーンに適用される同じ変数を区別 する。ゾーンは以下のどちらかである。 C 子ゾーン P 親ゾーン ロールオーバーの説明の中で、時刻は、記号の後にカッコにくくられた数値 を持つ場合がある。これは、その時刻が適用される鍵インスタンスを示す ものである。例えば、Tact(N)は、鍵Nのアクティベーション時刻で、 Tpub(N+1)は、鍵N+1の公開時刻である。 Morris, et al. Informational [Page 28] RFC 7583 Key Timing October 2015 本文中で使用した変数の一覧を以下に示す。 Dprp 伝播遅延。マスターネームサーバーで行われた変更が、全ての スレーブネームサーバーに伝播するまでの時間 DprpC 子ゾーン内での伝播遅延 DprpP 親ゾーン内での伝播遅延 Dreg 登録遅延。親ゾーンに提出されたDSレコードが親ゾーンに現れる までに要する時間。親ゾーンは、子ゾーンを管理する組織とは 異なる組織によって管理されることがしばしばあるため、組織間 でのデータ受け渡しに関連する遅延を、この用語によって取り こんでいる。 Dsgn 署名遅延。新しいZSKを導入した後に、ゾーン内の全てのRRが そのZSKで署名されるまでに要する時間。 Ipub 公開期間。DNSKEY、その関連データのどちらかあるいは両方が 公開された後に、関連するRRsetをキャッシュしているあらゆる リゾルバーが新しい情報のコピーを持っていると保証されるまで に経過しなければならない時間。 IpubC 子ゾーンにおける公開期間 IpubP 親ゾーンにおける公開期間 Iret リタイア期間。DNSKEY、その関連データのどちらかあるいは両方 がRetired状態になってから、それらに依存するあらゆる情報 (例えばZSKのRRSIG)が署名を検証するリゾルバーのキャッシュ から廃棄されたと保証されるまでに経過しなければならない時間。 Irev 失効期間。[RFC5011]の考慮事項を満たすために、KSKに"破棄" ビットが設定された状態での公開を維持し続けなければならない 期間。 Itrp トラストポイント期間。鍵を自動更新するように設定された リゾルバーが、新しい鍵を少なくとも2回は確認できることを 保証するため、トラストアンカーが公開されていなければ ならない時間。 Morris, et al. Informational [Page 29] RFC 7583 Key Timing October 2015 Lksk KSKのライフタイム。この特定のKSKがActiveなKSKと見なされる 実際の時間。鍵がいつロールオーバーされるかに応じて、実際の ライフタイムは、鍵管理ポリシーが提示する意図された鍵のライフ タイムより長くなったり短くなったりする可能性がある。 Lzsk ZSKのライフタイム。そのZSKがゾーンの署名に使用される実際 の時間。鍵がいつロールオーバーされるかに応じて、実際の ライフタイムは、鍵管理ポリシーが提示する意図された鍵のライフ タイムより長くなったり短くなったりする可能性がある。 Tact アクティベーション時刻。その鍵がゾーンの主要な鍵と見なされる ようになる時刻。 Tdea 機能終了時刻。署名を検証するリゾルバーのキャッシュに保持 される情報が、後継の鍵に関する情報を含むことが保証される 時刻。この時点で、現行の鍵と関連する情報は、署名検証 プロセスのために必要とされなくなる。 Tpub 公開時刻。鍵や関連データがゾーンに初めて現れる時刻。 Trem 削除時刻。鍵とその関連情報がそれぞれのゾーンから削除され 始める時刻。 Tret リタイア時刻。後継の情報が使用され始める時刻。 Trdy 準備完了時刻。鍵、関連データのどちらかあるいは両方に関する キャッシュを持つ署名を検証するリゾルバーが、新しい情報の キャッシュを持つと保証される時刻。 Tsbm 提出時刻。KSKのDSレコードが親ゾーンに提出される時刻。 TTLds DSレコードのTTL。 TTLkey DNSKEYレコードのTTL。(暗黙的に、これはDNSKEY RRsetの署名 のTTLでもある)。 TTLsig ゾーン内にある、ZSKで作成されたRRSIGレコードのTTLの最大値。 Morris, et al. Informational [Page 30] RFC 7583 Key Timing October 2015 Acknowledgements The authors gratefully acknowledge help and contributions from Roy Arends, Tim Wicinski, and Wouter Wijngaards. Authors' Addresses Stephen Morris Internet Systems Consortium 950 Charter Street Redwood City, CA 94063 United States Email: stephen@isc.org URI: http://www.isc.org Johan Ihren Netnod Franzengatan 5 Stockholm SE-112 51 Sweden Email: johani@netnod.se URI: http://www.netnod.se John Dickinson Sinodun Internet Technologies Ltd Magdalen Centre Oxford Science Park Robert Robertson Avenue Oxford, Oxfordshire OX4 4GA United Kingdom Email: jad@sinodun.com URI: http://www.sinodun.com W. (Matthijs) Mekking Dyn, Inc. 150 Dow St Manchester NH 03101 United States Email: mmekking@dyn.com URI: https://www.dyn.com Morris, et al. Informational [Page 31]