DNSOP O. Kolkman インターネットドラフト NLnet Labs 廃止(Obsolete): 2541 (承認後) 2010年8月1日 想定する状態: 情報提供(Informational) 有効期限: 2011年2月2日 DNSSEC運用ノウハウ (第2版) draft-ietf-dnsop-rfc4641bis-04 要旨 本文書はDNSセキュリティ拡張機能(DNSSEC)の運用ノウハウを記述する。 対象とする読者は、DNSSECを展開しているゾーン管理者である。 本文書は、運用の観点からDNSにおける鍵と署名の使用を論じる。 本文書は鍵の生成、鍵の保管、署名の生成、鍵のロールオーバー(更新)と 関連するポリシーについて記述する。 (承認された場合) 本文書は運用に関するより広範な領域をカバーし、また鍵長やDNSSEC運用に 関する最新の要件を提供するため、RFC 4641を廃止する。 Status of This Memo This Internet-Draft is submitted to IETF in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. This Internet-Draft will expire on February 2, 2011. Copyright Notice Kolkman Expires February 2, 2011 [Page 1] Internet-Draft DNSSEC Operational Practices, Version 2 August 2010 Copyright (c) 2010 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. This document may contain material from IETF Documents or IETF Contributions published or made publicly available before November 10, 2008. The person(s) controlling the copyright in some of this material may not have granted the IETF Trust the right to allow modifications of such material outside the IETF Standards Process. Without obtaining an adequate license from the person(s) controlling the copyright in such materials, this document may not be modified outside the IETF Standards Process, and derivative works of it may not be created outside the IETF Standards Process, except to format it for publication as an RFC or to translate it into languages other than English. 目次 1. はじめに . . . . . . . . . . . . . . . . . . . . . . . . . . . 5 1.1. "鍵"という用語の使用について . . . . . . . . . . . . . . . 6 1.2. 時間に関連する用語の定義 . . . . . . . . . . . . . . . . . 6 2. 信頼の連鎖の完全性維持 . . . . . . . . . . . . . . . . . . . . 7 3. 鍵の生成と保管 . . . . . . . . . . . . . . . . . . . . . . . . 8 3.1. KSKとZSKを区別する運用上の動機 . . . . . . . . . . . . . . 8 3.2. KSKとZSKを分離した場合の運用上の考慮点 . . . . . . . . . . 10 3.2.1. トラストアンカーでないKSKのロールオーバー . . . . . . 10 3.2.2. トラストアンカーとして使用されているKSKの ロールオーバー . . . . . . . . . . . . . . . . . . . . 11 3.2.3. SEPフラグの使用 . . . . . . . . . . . . . . . . . . . 12 3.3. 鍵有効期間 . . . . . . . . . . . . . . . . . . . . . . . . 12 3.4. 暗号に関する考慮点 . . . . . . . . . . . . . . . . . . . . 13 3.4.1. 鍵アルゴリズム . . . . . . . . . . . . . . . . . . . . 13 3.4.2. 鍵長 . . . . . . . . . . . . . . . . . . . . . . . . . 14 3.4.3. 秘密鍵の保管 . . . . . . . . . . . . . . . . . . . . . 15 3.4.4. 鍵の生成 . . . . . . . . . . . . . . . . . . . . . . . 16 3.4.5. "上位"ゾーンの扱いに差をつけるべきか . . . . . . . . . 16 4. 署名生成・鍵のロールオーバーと各処理に関連するポリシー . . . . 17 4.1. 鍵のロールオーバー . . . . . . . . . . . . . . . . . . . . 17 4.1.1. ZSKのロールオーバー . . . . . . . . . . . . . . . . . 17 Kolkman Expires February 2, 2011 [Page 2] Internet-Draft DNSSEC Operational Practices, Version 2 August 2010 4.1.1.1. 事前公開法によるロールオーバー . . . . . . . . . . 17 4.1.1.2. 二重署名法によるロールオーバー . . . . . . . . . . 20 4.1.1.3. 両方式の利点と欠点 . . . . . . . . . . . . . . . . 21 4.1.2. KSKのロールオーバー . . . . . . . . . . . . . . . . . 21 4.1.3. ZSKのロールオーバーとKSKのロールオーバーの違い . . . . 23 4.1.4. 単一鍵署名方式におけるロールオーバー . . . . . . . . . 24 4.1.5. 鍵アルゴリズムのロールオーバー . . . . . . . . . . . . 26 4.1.6. 鍵のロールオーバーの自動化 . . . . . . . . . . . . . . 28 4.2. 鍵の緊急ロールオーバー . . . . . . . . . . . . . . . . . . 29 4.2.1. KSKの漏洩 . . . . . . . . . . . . . . . . . . . . . . 29 4.2.1.1. 信頼の連鎖を維持する場合 . . . . . . . . . . . . . 30 4.2.1.2. 信頼の連鎖を壊す場合 . . . . . . . . . . . . . . . 31 4.2.2. ZSKの漏洩 . . . . . . . . . . . . . . . . . . . . . . 31 4.2.3. リゾルバでトラストアンカーとして使用されている鍵の漏洩 31 4.3. 親側のポリシー . . . . . . . . . . . . . . . . . . . . . . 32 4.3.1. 最初の鍵交換および親側のポリシーに関する考慮点 . . . . 32 4.3.2. 鍵を保存するか、ハッシュを保存するか . . . . . . . . . 32 4.3.3. DNSSEC Lame . . . . . . . . . . . . . . . . . . . . . 33 4.3.4. DSの署名有効期間 . . . . . . . . . . . . . . . . . . . 33 4.3.5. DNS運用者の変更 . . . . . . . . . . . . . . . . . . . 34 4.3.5.1. 移転元DNS運用者が協力的な場合 . . . . . . . . . . 34 4.3.5.2. 移転元DNS運用者が非協力的な場合 . . . . . . . . . 36 4.4. DNSSECにおける時間 . . . . . . . . . . . . . . . . . . . . 37 4.4.1. 時間に関する考慮点 . . . . . . . . . . . . . . . . . . 37 4.4.2. 署名有効期間 . . . . . . . . . . . . . . . . . . . . . 40 4.4.2.1. 最大値 . . . . . . . . . . . . . . . . . . . . . . 40 4.4.2.2. 最小値 . . . . . . . . . . . . . . . . . . . . . . 40 4.4.2.3. RRset間における差異 . . . . . . . . . . . . . . . 41 4.4.2.4. その他のタイミングパラメータ . . . . . . . . . . . 42 5. 不在証明レコードタイプ . . . . . . . . . . . . . . . . . . . . 42 5.1. NSECとNSEC3の違い . . . . . . . . . . . . . . . . . . . . 43 5.2. 使用すべきはNSECかNSEC3か . . . . . . . . . . . . . . . . 44 5.3. NSEC3のパラメータ . . . . . . . . . . . . . . . . . . . . 44 5.3.1. ハッシュアルゴリズム . . . . . . . . . . . . . . . . . 44 5.3.2. 繰り返し回数 . . . . . . . . . . . . . . . . . . . . . 44 5.3.3. ソルト . . . . . . . . . . . . . . . . . . . . . . . . 45 5.3.4. Opt-out . . . . . . . . . . . . . . . . . . . . . . . 45 6. セキュリティに関する考慮点 . . . . . . . . . . . . . . . . . . 46 7. IANAに関する考慮点 . . . . . . . . . . . . . . . . . . . . . 46 8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 46 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 47 9.1. Normative References . . . . . . . . . . . . . . . . . . . 47 9.2. Informative References . . . . . . . . . . . . . . . . . . 47 付録A. 専門用語 . . . . . . . . . . . . . . . . . . . . . . . . . 49 付録B. 表記上の慣例 . . . . . . . . . . . . . . . . . . . . . . . 50 Appendix C. Document Editing History . . . . . . . . . . . . . . 53 C.1. draft-ietf-dnsop-rfc4641-00 . . . . . . . . . . . . . . . 53 Kolkman Expires February 2, 2011 [Page 3] Internet-Draft DNSSEC Operational Practices, Version 2 August 2010 C.2. version 0->1 . . . . . . . . . . . . . . . . . . . . . . . 53 C.3. version 1->2 . . . . . . . . . . . . . . . . . . . . . . . 54 C.4. version 2->3 . . . . . . . . . . . . . . . . . . . . . . . 54 C.5. version 3->4 . . . . . . . . . . . . . . . . . . . . . . . 55 C.6. Subversion infromation . . . . . . . . . . . . . . . . . . 55 Kolkman Expires February 2, 2011 [Page 4] Internet-Draft DNSSEC Operational Practices, Version 2 August 2010 1. はじめに 本文書はDNSセキュリティ拡張(DNSSEC)が使用可能な環境の運用ノウハウを 記述する。DNS(RFC 1034[1]およびRFC 1035[2]参照)の知識があり、DNSSEC (RFC 4033[4]、RFC 4033[4]およびRFC 4034[5])を展開したい運用者向けに 書かれている。本文書の焦点は、ゾーン管理者、ネームサーバ管理者、 レジストリ、レジストラ、ドメイン名登録者等が、権威DNS情報を提供する部分に あてられている。これらの組織と、署名検証を行う再帰ネームサーバ (バリデータ)の運用者の間に直接の関係は想定しない。 ワークショップや初期段階におけるDNSSECの運用展開を通じて、運用者や システム管理者はDNSSEC機能を有効にした運用の経験を積んだ。本文書は、 これらの経験をゾーン管理者向けの運用ノウハウとしてまとめ直したものである。 本稿執筆時点で、ルートゾーンが署名され、初めて"Secure"な委任が展開 されているが、実環境におけるDNSSECの運用経験は比較的少ない状況にある。 したがって、本文書を"現時点における最良の方法(Best Current Practice)"と みなすべきではないのは明らかである。それよりはむしろ、本文書はDNSSECを 展開する際に決定すべきことを記述し、それらに対する選択肢を与え、幾つかの 運用ガイドラインを示すものである。本文書は何かを強く推奨するものではない。 それは本文書が将来において扱うテーマである。 [OK: この部分はIETF 77ミーティングのWGで指示されたと私が理解している 論調と行き違いになっている。特定の推奨を行えば、本文書を大幅に短くできた だろうか?現時点で特定の推奨を行ってはならないという共通のコンセンサスが どこかにあるだろうか?] 本稿で紹介する手続きは、署名ゾーンの維持管理(権威サーバ上におけるゾーンの 署名と公開)に焦点を当てている。再署名や鍵のロールオーバーといったゾーンの 維持は、署名検証を行うクライアント(以下"検証クライアント")からは透過的 であるように意図している。 本文書の構成は以下のとおりである。セクション2では"信頼の連鎖"を 損なわずに維持することの重要性を論じる。鍵生成の諸相および鍵の セキュリティについてはセクション3で論じる。ここでは主に秘密鍵部分に 焦点を当てる。セクション4では公開鍵部分に関する考慮点を記述する。 DNSでこれらの公開鍵を公開するため、様々なタイミングについての問題を 考慮する必要が出てくる。これらの問題についてはセクション4.4で 論じる。セクション4.1とセクション4.2では、鍵のロールオーバーに関する 話題を扱う。最後にセクション4.3では、信頼の連鎖を維持するために親が子の 公開鍵を処理する際の考慮点を論じる。 Kolkman Expires February 2, 2011 [Page 5] Internet-Draft DNSSEC Operational Practices, Version 2 August 2010 本文書で使用する表記上の慣例については付録Bで説明する。 本稿は運用上の提案を含む文書であり、プロトコル仕様の記述は含まない ことから、RFC 2119[6]の用語(訳注: MUST, SHOULD, MAY等)は使用しない。 [OK:承認された場合]本文書はRFC 4641[14]を廃止する。 [OK:編集上のコメント・質問は角カッコ内に編集者のイニシャル付きで示す]。 1.1. "鍵"という用語の使用について 読者はDNSSECが基盤とする非対称暗号鍵(公開鍵暗号:RFC 4949[15])の概念を 理解しているものとする。したがって、本文書では"鍵"という用語を多少 大まかに使用する。"鍵を使用してデータに署名する"と記述する場合、読者は 鍵ペアの秘密鍵部分を使用して署名処理を行うということを理解している ものとする。また、読者は鍵ペアの公開鍵部分はDNSKEYリソースレコードに 格納されて公開されており、鍵交換に使用されるのはこの公開鍵部分である ことを理解しているものとする。 1.2. 時間に関連する用語の定義 本文書では、時間に関連する用語を多用する。それぞれについて、以下の定義を 適用する。 ・"署名有効期間" (signature validity period) 署名が有効な期間。RRSIG RRの署名有効期間開始フィールドで指定される 時刻に始まり、RRSIG RRの署名有効期間終了フィールドで指定される 時刻に終了する。 ・ "署名公開期間"(signature publication period) (特定の鍵で生成された)署名が(同じ鍵で生成された)新しい署名に 置き換わった、または削除された後の時間。署名の置き換えは、 マスターゾーンファイル内の適切なRRSIGを公開することによって行われる。 ゾーンのRRSIG公開を停止した後に、キャッシュサーバのキャッシュから RRSIGのキャッシュが破棄されるまで、すなわちDNSから事実上消去される まで多少時間がかかることがある。 ・"鍵有効期間" (key effectivity period) 鍵ペアが有効であると期待される期間。ある鍵から生成された全署名の中で 最も早いタイムスタンプから、一番最後に期限満了した時刻までの期間 として定義される。その間にその鍵を使用していない期間があっても 構わない。鍵有効期間は、複数の署名有効期間に渡ることもあり得る。 Kolkman Expires February 2, 2011 [Page 6] Internet-Draft DNSSEC Operational Practices, Version 2 August 2010 ・"最大/最小ゾーンTTL" (Maximum/Minimum Zone TTL) ゾーン内の全てのRRの最大または最小TTL値。最小TTLはSOA RR の最小TTL値フィールド(MINIMUM field)とは違うので注意。 詳細についてはRFC 2308[9]を参照のこと。 2. 信頼の連鎖の完全性維持 有効な信頼の連鎖を維持することは重要である。なぜなら、信頼の連鎖が 途切れていると、(RFC 4033[3]のセクション5で定義されているとおり)データが "Bogus(検証失敗:信頼禁止)"と判定されるからである。その結果、 検証クライアントから(サブ)ドメイン全体が見えなくなるかもしれない。 DNSSEC対応ゾーンの管理者は、検証クライアントから見ればそのゾーンは 信頼の連鎖の一部であることを理解する必要がある。 "はじめに" のセクションで記述したように、本文書で示す手続きは、 再署名や鍵の変更といったゾーンの維持がインターネット上の 検証クライアントから透過的になることを保証するように意図している。 DNSSEC対応ゾーンの管理者は、権威を持つプライマリサーバ上で公開した データが直ちに検証クライアントから見えるようにはならないことを心に 留めておく必要がある。データが他の権威を持つ(セカンダリ)ネームサーバに 転送されるまで多少の時間を要することがあるし、またクライアントも 権威を持たない再帰検索サーバ(キャッシュサーバ)からデータを取得する 場合がある。この点について、以下のことを心に留めておくとよいだろう。 マスターからスレーブへのゾーン転送時間は、NOTIFY[8]や差分ゾーン転送 (IXFR)[7]を使用する場合、ごくわずかなものである。ゾーンの全転送(AXFR) とNOTIFYを組み合わせて使用する場合、ゾーン転送時間は増加する。SOAの ゾーンリフレッシュに関するタイミングパラメータに依存してゾーンの全転送を 行う場合には、ゾーン転送時間は更に増加する。 検証クライアントにとって、DNSSEC対応ゾーンからデータを得る際に、 データを得た相手が権威を持つサーバであろうが、キャッシュサーバ または中継を行う何らかの機器であろうが、それらに関係なく取得した データを使用して信頼の連鎖を構築できるということが重要である。 利用可能なタイミングパラメータを注意深く使用することによってのみ、 ゾーン管理者は署名検証に必要なデータが取得可能なことを保証できる。 信頼の連鎖を維持する責任は、信頼の連鎖を構成するDNSSEC対応ゾーンそれぞれの 管理者が分担する。この事実は "鍵の漏洩" 時に信頼の連鎖を維持することと、 漏洩した鍵を可能な限り早く置き換えるかのトレードオフを検討しなければ ならない際に最も明らかになる。各DNSSEC対応ゾーンの管理者は、この トレードオフ、すなわち信頼の連鎖を損なわずに維持する代わりに漏洩した鍵に よる攻撃を許容するか、あるいは意図的に信頼の連鎖を壊し、DNSSEC対応した サブドメインをDNSSEC対応リゾルバから見えなくするかを選択しなければ ならない。(セクション4.2も参照のこと) Kolkman Expires February 2, 2011 [Page 7] Internet-Draft DNSSEC Operational Practices, Version 2 August 2010 3. 鍵の生成と保管 本セクションは鍵の使用に関する数多くの検討事項を記述する。鍵の生成と 保管について運用手順を設計するためには、以下に示すような多くの事柄に ついて意志決定が求められる。 ・ ZSKとKSKを区別するか、1種類の鍵のみで十分か? ・ KSKをトラストアンカーとするか(されそうか)? ・ 運用要件に従うタイミングパラメータはどのようになるか? ・ 運用要求を満たす暗号パラメータはどのようになるか? 以下のセクションでは、上記の事柄について意志決定を行う際に検討されるべき 考慮点について議論する。 3.1. KSKとZSKを区別する運用上の動機 DNSSECの検証プロトコルは、DNSKEYのタイプの違いを区別しない。鍵の区別を 行う動機は純粋に運用上のものであり、バリデータはそれらを区別しない。 後述するような運用上の理由から、1つ以上のKSK(鍵署名鍵)を設定することが できる。KSKはゾーン頂点のDNSKEY RRsetのみを署名する。KSKでない鍵は、 署名が必要なゾーンのRRset全てに署名するために使用できる。これをZSK (ゾーン署名鍵)と呼ぶ。KSKとZSKの区別を行わない場合を、単一署名鍵方式 (Single Type signing scheme)と呼ぶことにする。 2つの鍵が区別される場合、ほとんど全ての鍵管理・ゾーン管理方式において、 KSKの使用頻度はZSKよりも少なくなる。鍵セットを一旦KSKで署名してしまえば、 その鍵セットの鍵はすべてZSKとして使用できるようになる。ZSKの漏洩リスクを 増大させるイベントが発生した場合は、当該ZSKを鍵セットから外し、その後、 KSKで新しい鍵セットに署名を行うだけでよい。 ゾーンのセキュアエントリーポイント(SEP)の鍵を変更することは、第三者との やりとりを必要とするため、作業コストがやや高くなる。鍵が親ゾーンの DSレコードから参照されているだけであれば、レジストリとやりとりを行い、 更新されたDSレコードがDNSに反映されるのを待つ必要があるだけである。 一方で、鍵がトラストアンカーとして設定されている場合、全ての (訳注:バリデータに設定された)トラストアンカーが更新されたという確信が 十分に得られるまで待たなければならない。しかし現実問題として、ユーザの トラストアンカー更新に関する完全な情報を取得することは不可能だろう。 Kolkman Expires February 2, 2011 [Page 8] Internet-Draft DNSSEC Operational Practices, Version 2 August 2010 盗難や紛失による鍵の漏洩リスクも存在する。ネットワークに接続されたネーム サーバのファイルシステム上に導入されている鍵(例えばダイナミックアップ デートを行うため)については、そのようなリスクが比較的高くなる。 一方、ハードウェアセキュリティモジュール(HSM)やオフラインに保管されている 鍵は、そのようなリスクが比較的低くなる。KSKとZSKを機能的に分離することで、 コストとのトレードオフになるが、これらのリスクを管理することが可能となる。 例えば、ゾーンデータの追加・削除など、運用上の目的から容易に読み出せる ことが必要なZSKに比べると、KSKはオフラインもしくはより限定されたアクセス 制限をかけて保管することができる。例えば、KSKはスマートカードに保存して 安全な場所で保管し、一方でZSKはファイルシステムに保存し、運用者が日常的な ルーチン作業でアクセス出来るようにしておくことで、HSMに(KSKとZSKの 機能を併せ持たせた)単一鍵を保存する場合に比べ、運用の柔軟性と高い計算 パフォーマンスを実現できる。 最後に、鍵情報(key material)の暗号解析リスクが挙げられる。暗号解析 コストは、鍵長と相関する。しかし、暗号解析リスクに関する議論がKSKと ZSKの分離に強い動機を与えるわけではない。KSKとZSKを分離し、KSKの鍵有効 期間をZSKの鍵有効期間のX倍に設定したと仮定する。その場合、KSKとZSKの 暗号解析耐性が等価になるためには、KSKはZSKのX倍の強度を持つ必要がある。 実際に、Xはおよそ10から100のオーダーとなるであろうから、対称鍵の場合、 鍵長はせいぜい1バイト違う程度にとどまる。非対称鍵の場合であっても、 鍵の分離を正当化するには鍵長の違いはごくわずかで、パケットサイズと 署名速度にかろうじて差が出る程度である。 以下のような場合には、ZSKとKSKを分離する論拠が最も薄弱となる。 ・ 鍵の漏洩のリスクが低い(例えば、鍵がHSMに保存されている場合など)。 ・ 鍵がトラストアンカーとして使用されていないことが確実である。 ・ 自動化ツールを用いた鍵管理を行うことができない(ヒューマンエラーが 起きやすい)。 ・ レジストラとレジストラ間の鍵登録のやりとり、具体的に、緊急事態時に 親ゾーンに新しいDSレコードがタイムリーに反映される処理が予測できる。 上記の条件を満たすような場合、KSKとZSKを分離する結果増大する運用の複雑さは (訳注:得られる)運用の柔軟性に比べてコストが見合わないだろうから、 単一署名鍵方式を選択するのが妥当な選択肢となる。それ以外の場合は、 KSKとZSKを分離したうえで、KSKにSEPフラグを設定することを勧める。 Kolkman Expires February 2, 2011 [Page 9] Internet-Draft DNSSEC Operational Practices, Version 2 August 2010 3.2. KSKとZSKを分離した場合の運用上の考慮点 KSKにSEPフラグが設定されていると仮定すると、DNSKEY RRのフラグフィールドを 確認することで、KSKとZSKを見分けることができる。フラグフィールドが奇数で あればそのRRはKSKであり、そうでなければZSKである。 ZSKは、日常的に行われるゾーン内の全データへの署名で使用できる。ZSKを ロールオーバーする場合、親ゾーンとのやりとりは不要である。(訳注: ZSKの ロールオーバーはZSK公開ゾーンだけで完結して行えるので短時間で済むことから) ZSKの鍵有効期間を日単位とすることも可能である。 KSKはゾーンのDNSKEY RRに署名するためだけに使用される。KSKをロールオーバー する場合、KSK公開ゾーンの管理者以外の相手とやりとりが発生する。 親ゾーンが存在する場合、それらの相手は親ゾーンを管理するレジストリで あったり、当該鍵をセキュアエントリーポイントに設定している署名を検証する リゾルバの管理者であったりする。後者の場合、当該鍵をトラストアンカーとして 信頼する全ユーザは、新しい鍵へのロールオーバー処理を行わなければならない。 トラストアンカーの自動更新の仕組み(例えばRFC 5011[16]記載のような)を使用 していなければ、この処理はサービス安定性を維持するためのコスト (stability cost)となる。したがって、KSKの鍵有効期間はずっと長くなる だろうし、そうすべきである。 3.2.1. トラストアンカーでないKSKのロールオーバー トラストアンカーでないKSKのロールオーバーの実施には次の3通りの考え方 がある。 ・ 運用ルーチンにしてしまえるように、頻繁かつ定期的(2~3ヶ月毎)に 実施すべきである。 ・ 頻繁に、ただし不定期に実施すべきである。"頻繁に"とは2~3ヶ月毎を意味する。 これは上記と同様にロールオーバーを習熟した共通の運用ルーチンにするという 考えに基づく。一方で"不定期に"とは、第三者が鍵(の定期更新)を当てにして トラストアンカーとして設定することがないように、大きなゆらぎを導入する という意味である。 ・ KSKが漏洩したと判明したか、または漏洩した可能性が強く疑われる場合に 限り実施すべきである。 DNSSECの展開状況がそれぞれ異なる中で、これら3通りの考え方のいずれが 良いかという幅広い合意は存在しない。トラストアンカーでないKSKのロール オーバーを行う度に、サービス安定性を維持するためのコストが生じるが、 親ゾーンと子ゾーン間の連携が良好であれば、そのコストはおそらく小さな ものになる。一方、連携が良好であることを知る完全に有効な唯一の方法は、 定期的な検証である。したがって、親ゾーンと連携しつつKSKをロールオーバー する理由は以下の2つだけである。1つめは緊急事態に備えるためにロール オーバーシステムの機能を検証すること、もう1つは実際の緊急事態の発生に 対応する(発生を防ぐ)ことである。 Kolkman Expires February 2, 2011 [Page 10] Internet-Draft DNSSEC Operational Practices, Version 2 August 2010 最後に、当該ゾーンのKSKがどこかでトラストアンカーとして使用されていないかに ついて、ゾーン管理者はほとんどの場合確実に知ることができない。トラスト アンカーの設定はゾーン管理者の責任範囲ではないが、ゾーン管理者がKSKの ロールオーバーを実施すると、(無断で)当該KSKをトラストアンカーとして 設定したバリデータ管理者にとってサービス安定性を維持するためのコストが 発生するだろう。 3.2.2. トラストアンカーとして使用されているKSKのロールオーバー トラストアンカーとして使用されているKSKをロールオーバーする場合、 先に述べたような、KSKを無断でトラストアンカーとして使用されている事例と 同じ運用上の懸念が生じる。トラストアンカーの置き換えが正しく 行われなければ、当該トラストアンカーがカバーする全てのドメイン名は、 トラストアンカーが正しく設定されるまでは"Bogus"となる。 多くの場合は、KSKはトラストアンカーとして使用されていないという前提で 鍵を操作しても問題ない。ゾーン管理者が"DNSSEC Signing Policy and Practice Statement"[25]を公開している場合、その文書において、トラストアンカーの 存在を何らかの形で考慮するか否かについての事実を明示すべきである。 ローカルポリシーにより、ミッションクリティカルなゾーンについてはトラスト アンカーを設定することが強制される事例もあるかもしれない(例えば、ある 企業ドメインのトラストアンカーがその企業のバリデータに設定されている場合)。 ゾーン管理者は、このような事情を把握していることが期待される。 全ての利用者に旧いトラストアンカーを新しいものに置き換えさせることは 困難であるから、トラストアンカーとして使用されているKSKは、その鍵が 漏洩したと判明したか、または漏洩した可能性が強く疑われる場合を除いては 決してロールオーバーすべきでないという議論もあり得るだろう。 言い換えれば、KSKのロールオーバーコストは、KSK更新の情報が伝わらない 利用者がいるために、法外に高いものになるということである。 しかし、"KSKのロールオーバーは定常的な運用ルーチンに含めるべき"という 議論は、バリデータにおけるトラストアンカーの再設定にも当てはまる。 短い鍵有効期間が使用され、トラストアンカーを定期的に再設定しなければ ならない場合、設定忘れの可能性は低くなる。実際には、トラストアンカーの 自動更新(RFC 5011[16])によりユーザの負担するコストは最小化可能であるし、 定期的な鍵のロールオーバーの実施(およびその事実の広報)を行うことにより、 再帰ネームサーバ管理者はこれらの定常コストを処理する適切な仕組みを導入する だろう。言い換えれば、不意に生じるコストをどうするか検討する替わりに、 サービス安定性を維持するためのコストとして予算を計上できるだろう。 Kolkman Expires February 2, 2011 [Page 11] Internet-Draft DNSSEC Operational Practices, Version 2 August 2010 したがって、(RFC 5011のような)標準化された仕組みを用いることで、 ロールオーバーを追跡できる場合に限り、トラストアンカーとして使用されている 可能性のあるKSKのロールオーバーを推奨する。 3.2.3. SEPフラグの使用 いわゆるセキュアエントリーポイント(SEP)[5]フラグを使用することで、 ゾーンへの信頼の連鎖を構築するためのセキュアエントリーポイントとして 意図されている鍵を区別できる。これらの鍵は、親ゾーンのDS RRから参照 されるか、トラストアンカーとして設定される(はずである)。 実際問題として、SEPフラグはRFC 5011[16]に記述されるロールオーバーの 仕組みで使用するといった、運用上の目的で設定されるものである。 (障害発生時に何か役立つというわけではないのだが)。一般的な慣習として、 親ゾーンと交換する鍵、またはトラストアンカーとして利用される可能性がある 鍵全てにSEPフラグを設定する。したがって、SEPフラグはKSKに設定し、ZSKには 設定しないことを推奨する。KSKとZSKを区別しない(すなわち単一鍵署名方式の) 場合には、全ての鍵にSEPフラグを設定することを推奨する。 KSK/ZSKが分離されていると想定し、SEPフラグの存在(不在)を元にゾーンデータに 署名する鍵を特定する署名ツールがあることに注意してもらいたい。 単一鍵署名方式を使用する環境でこのようなツールを使用すると、おかしなことに なるかもしれない。 3.3. 鍵有効期間 一般に、使用する鍵長により鍵有効期間の上限が規定される。実際には、 純粋に運用上の要求に基づいて鍵有効期間をまず決定し、それにあわせて 鍵長を決めれば充分である。運用の観点を無視すれば、対応するDSレコードが 親ゾーンで公開されているKSKの妥当な鍵有効期間は20年以上である。つまり、 ロールオーバー手順を確認しようとしないのであれば、KSKは実質的に永久に 有効であり、緊急事態の場合に限りロールオーバーすべきものである。 定期的なロールオーバー実施を選択するのであれば、対応するDSレコードが 親ゾーンで公開されているKSKの妥当な鍵有効期間は13ヶ月である。これはロール オーバーが終了してから12ヶ月後に次のロールオーバーを行うことを意図したもの である。上で議論したように、1年毎にロールオーバーを行うことで、ゾーン 管理者とバリデータ管理者の双方に対し、ロールオーバーの運用経験を積ませる ことができる。加えて、ほとんどの状況において、1年という期間は計画立案や 連携が行いやすい。 Kolkman Expires February 2, 2011 [Page 12] Internet-Draft DNSSEC Operational Practices, Version 2 August 2010 鍵がオンラインシステムに保管されている場合は漏洩につながる様々な脅威 に晒されるので、ZSKの妥当な鍵有効期間は1ヶ月である。 鍵有効期間は、数分単位程度にまで、非常に短くすることもできる。しかし、 鍵を変更する際には、セクション4.4およびセクション4.1の考慮点に配慮 しなければならない。 ZSKの鍵有効期間をKSKの鍵有効期間より短くする動機は、運用者はKSKより 頻繁にZSKに対して読み取りアクセスを行うだろうという運用上の考慮に基 づいている。ZSKが暗号機能付ハードウェアセキュリティモジュール(HSM)に 保管されている場合は、KSKに比べ鍵有効期間を短くすることへの動機付けは 弱くなる。 実際、ZSKとKSKで紛失・盗難などの漏洩リスクが同じならば、それらの鍵有効 期間を差別化する理由はほとんどない。ZSKとKSKを分離していないのであれば、 この議論自体が不要である。 単一鍵署名方式を用いて長期間の鍵有効期間を選択することが正解である場合も 存在する(鍵の漏洩リスク、漏洩時の損害、緊急ロールオーバーのコスト及び リスクがいずれも少ない場合など)。 3.4. 暗号に関する考慮点 3.4.1. 鍵アルゴリズム DNSSECで使用可能なアルゴリズムとして、現在2種類、すなわちRSAとDSAが 存在する。双方とも自由に閲覧可能な数多くの文書によって完全に規定されて おり、特許の制約を受けない(patent-free)ことが広く認められている。 RSAとDSAの署名生成時間はほぼ同じだが、DSAの署名検証時間はRSAに比べて 約10倍遅くなる。 使用する署名アルゴリズムとして望ましいものはRSA/SHA-256であり、代替と してRSA/SHA-1を使用することを推奨する。どちらも一長一短である。 RSA/SHA-1は長年に渡って普及しているが、RSA/SHA-256は普及が始まったばかり である。一方で、どちらかのアルゴリズムに対して有効な攻撃手法が仮に発見 されるとすれば、RSA/SHA-1が先だろうと予想されている。RSA/MD5は、広く使用 されている一般的な署名アルゴリズムの中で、有効な攻撃手法が見つかっている おそらく最初のものなので、使用すべきでないと考えられる。 本文書の発行時点において、SHA-1ハッシュの暗号解読に関する問題が指摘 されており、この問題に対応するための作業が進められている。 本稿では、SHA-1よりも強いハッシュ(例えばSHA-256)に基づく公開鍵 アルゴリズムが実装されたならば(RFC 5702[23]とRFC 4509[20]参照)、直ちに それらの強いアルゴリズムを使用することを推奨する。 Kolkman Expires February 2, 2011 [Page 13] Internet-Draft DNSSEC Operational Practices, Version 2 August 2010 3.4.2. 鍵長 DNSSECの署名鍵は、鍵有効期間中に既知の暗号攻撃全てを防御するのに 充分な長さの鍵長にすべきである。これまでに多大な労力が費やされたが、 標準的な1024ビットの鍵は未だ破られていない。実際、最も完成された攻撃でも 700ビット相当の鍵を破る程度だと見積もられている。1024ビットの署名鍵を 破ろうとする攻撃者は、たった一つの鍵を破るために、大変な数のネットワーク 接続されたコンピュータ資源を、検知されることなく利用できる必要がある。 以上の理由により、少なくとも今後10年間は、ほとんどのゾーンで1024ビット鍵を 安全に使用できると見積もられている。(1024ビットの非対称鍵は概ね80ビットの 対称鍵と同等の暗号強度を持つ)。 極めて重要なトラストアンカー鍵や、トラストアンカーではないがロールオーバー が困難な鍵の管理者は、1024ビットより長い鍵を使用したいかもしれない。 一般的に、1024ビットの次の長さとして使用される鍵長は2048ビットであり、 これは概ね112ビットの対称鍵と同等の暗号強度を持つ(RFC 3766[12])。 標準的なCPUでは、2048ビット鍵の署名・検証は、1024ビット鍵の場合に比べて 4倍程度の時間を必要とする。 使用する鍵長を決定する別の方法として、1024ビット鍵を破ろうとする 攻撃者が必要な労力は、鍵の使われ方によらず同じであることを念頭に置く というものがある。攻撃者が1024ビットのDNSSEC鍵を破る能力があるならば、 TLSのトラストアンカーとして現時点でWebブラウザに数多くインストール されている1024ビット鍵も破ることができる。DNSSEC鍵を破って得られる成果は TLSトラストアンカーを破って得られる成果よりも少ないので、攻撃者は後者への 攻撃に注力するだろう。 鍵を破る攻撃手法に予期せぬ"改善"があり、2048ビット鍵は簡単に破れないが 1024ビット鍵は可能となるような事態もあり得る。仮にそのような"改善"が あれば、主要なWebブラウザには多数の1024ビットのトラストアンカーが 組み込まれているので、膨大な量の報道がなされるだろう。 それほどの状況になってしまえば、1024ビットのDNSSEC鍵(親ゾーンから参照されて いる鍵とトラストアンカーとして使用されている鍵の両方)をロールオーバーし、 より長い鍵長のものに置き換えることもできるだろう。 これまでに公開された文書(本文書の前バージョンを含む)では、特定の鍵が "高い使用頻度である"場合には鍵長を長くすることを推奨していた。 15年前であればその勧告は正しかったかもしれないが、RSAまたはDSA アルゴリズムで1024ビット以上の鍵を使用する今日においては、その勧告は もはや適切とは言えない。 Kolkman Expires February 2, 2011 [Page 14] Internet-Draft DNSSEC Operational Practices, Version 2 August 2010 3.4.3. 秘密鍵の保管 可能であれば、ゾーンの秘密鍵および署名されるゾーンファイルのマスター コピーは、オフラインのネットワークに接続されていない、物理的な安全を確保 した機器上にだけ保存し、またその機器上でだけ使用することを推奨する。 RRSIGおよびNSEC/NSEC3 RRを認証情報としてゾーンに追加するために、定期的に アプリケーションプログラムを動作させてもよい。その後、これらの認証情報を 追加したゾーンファイルを転送すればよい。 署名ゾーンの管理をダイナミックアップデート[10]に依存する場合、ゾーンの 秘密鍵を最低1つはマスターサーバ(かサーバがアクセス可能なHSM)上に 置かなければならないことに注意してもらいたい。この鍵は、サーバが 未知のクライアントから受ける脅威の量と、ホストのセキュリティから考え られる程度にしか安全ではない。必須ではないが、"非公開マスター (hidden master)"方式を利用すれば、ゾーン管理におけるリスクを最小化できる だろう。この方式では、ダイナミックアップデートを処理するマスターを、 インターネット上の一般的ホストから利用できなくする。具体的に、マスターの ホスト名をSOA RRのMNAMEフィールドでは示すが、NS RRset内には列挙しない ようにする。また、NS RRset内のネームサーバは、おそらくはNOTIFYや他の 仕組みと組み合わせて、IXFR、AXFRもしくはDNSプロトコル外の仕組みを使用した ゾーン更新を受理できるようにする。 理想的な状況は、ネットワーク経由の改ざんの可能性を避けるため、ネット ワークへの一方向の情報の流れしか持たないことである。しかし、ゾーンの マスター情報をネットワーク上のオンラインで維持し、オフラインの署名ツール (signer)を経て循環させるという形態ではこのようにはいかない。 マスター情報を持つホストがセキュリティ侵害を受ければ、そこにある オンライン版の情報は依然として改ざんされる可能性がある。 最大限のセキュリティを確保するために、ゾーンファイルのマスターコピーは オフラインで維持すべきであり、安全が確保されないネットワークを経た 通信経路を使用した更新をすべきではない。 この理想的状況は、リスクとコストの経済的なトレードオフを考えると達成 できないかもしれない。具体的に、ゾーンファイルをオフラインで維持する ことは DNSゾーンの運用コストを増やすだけで現実的でなく、実際にはゾーン ファイルを持つ機器はネットワークに接続されるだろう。DNSデータが署名前に 改変されることを防ぐために、運用者は、マスターコピーへの認証を経ない アクセスを遮断するためのセキュリティ基準を設定し、その基準に従った運用を することが推奨される。 同様に、秘密鍵をHSMに保管する選択肢も、以下に示すような懸念についての トレードオフとなる。 ・ 認証を経ない個人が誰にも気づかれずに秘密鍵を読み取るリスク ・ 攻撃者に残されている攻撃機会 Kolkman Expires February 2, 2011 [Page 15] Internet-Draft DNSSEC Operational Practices, Version 2 August 2010 ・ 考えられる攻撃が引き起こす経済的影響(一般的には個人ユーザよりTLD の方が影響が大きくなるだろう) ・ (漏洩した)鍵をロールオーバーするコスト。(ZSKのロールオーバーコストは 最小だが、トラストアンカーとして広く利用されるKSKのロールオーバー コストは最大となる)。 ・ HSMを購入し、維持するコスト ダイナミックアップデート[10]を使用するDNSSEC対応ゾーンでは、マスター コピーとRR更新時に署名更新に使用する秘密鍵の両方をオンラインで維持す る必要がある。 3.4.4. 鍵の生成 全ての鍵を注意深く生成するということは時に見落とされがちになるが、 暗号を使用して安全を確保するあらゆるシステムにおいて絶対に不可欠である。 敵対者が網羅的な探索が可能な程度に鍵空間の可能性を限定できるのであれば、 最も強力なアルゴリズムを非常に長い鍵長で使用したとしても無意味 である。乱数鍵の生成に関する技術的な勧告がRFC 4086[13]およびNIST SP 800-900[19]に記述されている。特に、鍵生成時に使用する乱数生成器が この勧告に準拠したものかどうかを慎重に見極めるべきである。 長い有効期間を持つ鍵は特に慎重を要する。有効期間の長い鍵は、攻撃する 価値が高い目標であることを意味し、また有効期間の短い鍵よりも長い間 攻撃にさらされる可能性が高い。有効期間の長い鍵を生成する際には、物理的 にネットワークから隔離されたオフライン環境で行うか、最低でも高い水準で セキュリティを確保するハードウェア上で行うことを強く推奨する。 3.4.5. "上位"ゾーンの扱いに差をつけるべきか 本文書の前バージョン(RFC 4641[14])では、DNS階層における上位ゾーンで 使用するKSKと、下位で使用するKSKで差をつけ、上位ゾーンにより強い鍵を 使うべきであるとした。 今日において、この扱いに差をつける行為はもはや適切とは言えない。 "誰も破れない鍵を万人が使用すべきである"というのが暗号上の推奨事項なので、 上位の階層ほど鍵長を長くすることは有用ではない。また、攻撃者にとって 価値のあるゾーン、価値の少ないゾーンを判定することは不可能である。 攻撃は、鍵の漏洩が気づかれない状況で、かつ攻撃者が中間者(man-in-the-middle: MITM)として振る舞える場合だけしか発生しない。例えば、example.com の鍵が 漏洩し、攻撃者が somebank.example.com に関する回答を偽装し、MITMによって 回答を送信する場合を考える。攻撃が発見されると、その時点でexample.com の 鍵が漏洩したと判断できるので、KSKがロールオーバーされることになる。 したがって、DNSのどの階層であっても、鍵の漏洩に基いて長期に成功する攻撃を 計画することは困難である。 Kolkman Expires February 2, 2011 [Page 16] Internet-Draft DNSSEC Operational Practices, Version 2 August 2010 4. 署名生成・鍵のロールオーバーと各処理に関連するポリシー 4.1. 鍵のロールオーバー ゾーンにおける鍵のロールオーバーを緊急事態への備えとして定期的に行うか、 緊急事態発生時のみに行うかはともかくとして、鍵のロールオーバーそのものは DNSSECを使用する限り避けて通れない宿命である。鍵のロールオーバーを実行中の ゾーン管理者は、前のバージョンで公開されたゾーン情報が依然として キャッシュ内に存在していることを考慮しなければならない。DNSSECを展開する 際に、これは重要な考慮点になる。キャッシュ内に存在するかもしれないデータを 無視すると、クライアント向けサービスの損失につながる可能性がある。 ゾーンの内容が旧い鍵で署名されており、それを検証しようとしている リゾルバがその旧い鍵をキャッシュしていなかった場合に、最も緊急の事例が 生じる。旧い鍵が現在のゾーン内に存在しない場合、検証は失敗し、データは "Bogus" と判定される。一方で、ローカルキャッシュに残っている 旧い鍵ではなく、新しい鍵で署名されたデータを検証する試みもデータに "Bogus" と判定される結果となる。 4.1.1. ZSKのロールオーバー ZSKとKSKを分離する選択をしたならば、それら2タイプの鍵は独立にロール オーバー可能である。特に、ZSKは親ゾーンのDSからの参照や、当該鍵がトラスト アンカーとして設定されている可能性などは考慮せずにロールオーバーしてよい。 ZSKのロールオーバーに関して、鍵のロールオーバー中にキャッシュ内に残された データを新しい鍵セットで検証可能であるか、あるいは新しく生成された署名を キャッシュ内に残された旧い鍵で検証可能であることを保証する二つの方法が 存在する。セクション4.1.1.2に記述したものは、二重署名を使用する。 もう一つの方法は、事前に鍵を公開する方法である(セクション4.1.1.1)。 両手法に関する利点、欠点、推奨はセクション4.1.1.3に記述する。 4.1.1.1. 事前公開法によるロールオーバー 本セクションでは、ゾーン内の全データに署名を二度行う必要なくZSKをロール オーバーする、"事前公開法"を提示する。本手法は、鍵が漏洩した場合に有効 である。旧い鍵が漏洩したとしても、新しい鍵は既にDNSで配布されている。 ゾーン管理者は、速やかに新しい鍵へと切り替え、漏洩した旧い鍵をゾーンから 削除できる。もう1つの大きな長所は、"二重署名法"のように、ゾーンサイズが 2倍にはならないことである。 Kolkman Expires February 2, 2011 [Page 17] Internet-Draft DNSSEC Operational Practices, Version 2 August 2010 事前公開法によるロールーバーでは、以下に示す4つの段階を経る。 ---------------------------------------------------------- 初期状態 新DNSKEY導入 新RRSIG導入 ---------------------------------------------------------- SOA0 SOA1 SOA2 RRSIG_Z_10(SOA) RRSIG_Z_10(SOA) RRSIG_Z_11(SOA) DNSKEY_K_1 DNSKEY_K_1 DNSKEY_K_1 DNSKEY_Z_10 DNSKEY_Z_10 DNSKEY_Z_10 DNSKEY_Z_11 DNSKEY_Z_11 RRSIG_K_1(DNSKEY) RRSIG_K_1(DNSKEY) RRSIG_K_1(DNSKEY) RRSIG_Z_10(DNSKEY) RRSIG_Z_10(DNSKEY) RRSIG_Z_11(DNSKEY) ------------------------------------------------------------ ------------------------------------------------------------ 旧DNSKEY削除 ------------------------------------------------------------ SOA3 RRSIG_Z_11(SOA) DNSKEY_K_1 DNSKEY_Z_11 RRSIG_K_1(DNSKEY) RRSIG_Z_11(DNSKEY) ------------------------------------------------------------ 事前公開法によるロールオーバー経過 初期状態: ゾーンの初期状態。DNSKEY 1はKSKである。DNSKEY 10はゾーンの 全データに署名するために使用されるZSKである。 新DNSKEY導入: DNSKEY 11を鍵セットに導入する。この鍵を使用した署名は 生成されていないが、これは新しい公開鍵への総当たり攻撃(brute force attack)に対して安全であることを意味しないので注意してもらいたい。 ロールオーバー前のこの段階に要する最短期間は、データが権威サーバに 伝搬する時間に新しい鍵セットのTTLを加えた時間である。 新RRSIG導入: "新RRSIG導入"段階(SOAシリアル番号2)では、DNSKEY 11を使用して ゾーン内のデータに排他的に署名する(つまりDNSKEY 10の署名はゾーンから 削除される)。ただしDNSKEY 10は鍵セット内で公開され続ける。 この状態では、ゾーンのバージョン1からキャッシュされたデータをゾーンの バージョン2から得た鍵セットでまだ検証することができる。鍵セットが DNSKEY 10を含んで公開される最短時間は、前のバージョンのゾーンから キャッシュされたゾーンデータがキャッシュから消去されるまでの時間である。 すなわち、新しいゾーンが全ての権威サーバに伝搬する時間に、ゾーンの 前バージョンの任意のデータの最大ゾーンTTL値を加えた時間となる。 Kolkman Expires February 2, 2011 [Page 18] Internet-Draft DNSSEC Operational Practices, Version 2 August 2010 旧DNSKEY削除: DNSKEY 10はゾーンから削除される。この段階の鍵セットは、 現時点でDNSKEY 1とDNSKEY 11だけを含んでおり、DNSKEY 1に再署名される。 上記の方式は、鍵のロールオーバー後直ちに"将来使用する"鍵を公開することに よって簡素化することができる。その方式を以下に示す(ロールオーバー2回分を 示す)。将来使用する鍵は"新DNSKEY導入"段階でDNSKEY 12として導入され、 次に鍵13が"新DNEKEY導入(II)"で導入される。 ----------------------------------------------------------------- 初期状態 新RRSIG導入 新DNSKEY導入 ----------------------------------------------------------------- SOA0 SOA1 SOA2 RRSIG_Z_10(SOA) RRSIG_Z_11(SOA) RRSIG_Z_11(SOA) DNSKEY_K_1 DNSKEY_K_1 DNSKEY_K_1 DNSKEY_Z_10 DNSKEY_Z_10 DNSKEY_Z_11 DNSKEY_Z_11 DNSKEY_Z_11 DNSKEY_Z_12 RRSIG_K_1(DNSKEY) RRSIG_K_1 (DNSKEY) RRSIG_K_1(DNSKEY) RRSIG_Z_10(DNSKEY) RRSIG_Z_11(DNSKEY) RRSIG_Z_11(DNSKEY) ---------------------------------------------------------------- ---------------------------------------------------------------- 新RRSIG導入(II) 新DNSKEY導入(II) ---------------------------------------------------------------- SOA3 SOA4 RRSIG_Z_12(SOA) RRSIG_Z_12(SOA) DNSKEY_K_1 DNSKEY_K_1 DNSKEY_Z_11 DNSKEY_Z_12 DNSKEY_Z_12 DNSKEY_Z_13 RRSIG_K_1(DNSKEY) RRSIG_K_1(DNSKEY) RRSIG_Z_12(DNSKEY) RRSIG_Z_12(DNSKEY) ---------------------------------------------------------------- 事前公開法によるロールオーバー経過: ロールオーバー2回分 Kolkman Expires February 2, 2011 [Page 19] Internet-Draft DNSSEC Operational Practices, Version 2 August 2010 "新DNSKEY導入"段階で導入される鍵は、すぐに実運用で使用されるわけでは ないことに注意してもらいたい。したがって、秘密鍵は物理的に安全を確保した 形で保存が可能であり、ゾーンに署名が必要になる度に毎回"取得"が必要に なることもない。 4.1.1.2. 二重署名法によるロールオーバー 本セクションでは、二つの署名を使用してZSKロールオーバーを実行する方法、 "二重署名法"を提示する。 "新DNSKEY導入"段階の間に、ゾーンファイルが権威サーバ全てに伝搬する必要が あり、また(遠隔の)キャッシュ内にあるデータが消去される必要があるので、 最低でも最大ゾーンTTLの時間を必要とする。 二重署名法によるロールオーバーでは、以下に示す3つの段階を経る。 ---------------------------------------------------------------- 初期状態 新DNSKEY導入 旧DNSKEY削除 ---------------------------------------------------------------- SOA0 SOA1 SOA2 RRSIG_Z_10(SOA) RRSIG_Z_10(SOA) RRSIG_Z_11(SOA) RRSIG_Z_11(SOA) DNSKEY_K_1 DNSKEY_K_1 DNSKEY_K_1 DNSKEY_Z_10 DNSKEY_Z_10 DNSKEY_Z_11 DNSKEY_Z_11 RRSIG_K_1(DNSKEY) RRSIG_K_1(DNSKEY) RRSIG_K_1(DNSKEY) RRSIG_Z_10(DNSKEY) RRSIG_Z_10(DNSKEY) RRSIG_Z_11(DNSKEY) RRSIG_Z_11(DNSKEY) ---------------------------------------------------------------- 二重署名法によるロールオーバー経過 初期状態: ゾーンの初期状態。DNSKEY 1はKSKである。DNSKEY 10はゾーンの 全データに署名するために使用されるZSKである。 新DNSKEY導入: "新DNSKEY導入"段階(SOAシリアル1)では、DNSKEY 11を鍵セットに 導入し、ゾーン内の全データをDNSKEY 10およびDNSKEY 11の両方で署名する。 ロールオーバー期間(両方の鍵が存在する期間)は、(シリアル)バージョン0の ゾーンから得た全データがリモートキャッシュから消去されるまでよりも長い 必要がある。この時間は、最低でもバージョン0のゾーンの最大ゾーンTTLの 時間を要する。 Kolkman Expires February 2, 2011 [Page 20] Internet-Draft DNSSEC Operational Practices, Version 2 August 2010 旧DNSKEY削除: DNSKEY 10をゾーンから削除する。DNSKEY 10による全署名は ゾーンから削除される。この段階の鍵セットは、現時点でDNSKEY 11だけを 含んでおり、DNSKEY 1(KSK)で再署名される。 各段階において、ゾーンの前のバージョンから得たRRSIGは、現時点のバージョン から得たDNSKEY RRsetで検証可能であり、逆もまた可能である。現時点の バージョンから得たデータは、ゾーンの前のバージョンから得たデータで検証可能 である。"新DNSKEY導入"段階および鍵のロールオーバーの期間は、少なくとも 最大ゾーンTTLの時間とすべきである。 ゾーンの初期バージョンに含まれるデータの署名有効期間終了時刻まで "新DNSKEY導入"段階の継続を保証することを推奨する。このようにする ことで、旧い署名がキャッシュから消去されることが保証される。 しかし、この期間は最大ゾーンTTLよりも大幅に長くなることがあり、結果として 鍵のロールオーバーが非常に長い時間を要する手続きになることがある。 この例では、鍵のロールオーバー中にゾーンは変更されないものとしている ことに注意してもらいたい。両方の鍵で署名される限り、新しいデータを ゾーンに導入可能である。 4.1.1.3. 両方式の利点と欠点 事前公開法によるロールオーバー このロールオーバー法はゾーンデータへの署名を二度行う必要がない。 その代わり、鍵のロールオーバーを実際に行う前に新しい鍵が鍵セットで 公開されるので、暗号解読攻撃の対象となる。些細な欠点として、 この処理は4つの段階を必要とすることが挙げられる。 また本ロールオーバー法をKSKに適用する場合、セクション4.1.3で説明 するように、親側の作業を必要とする。 二重署名法によるロールオーバー このロールオーバー法の欠点は、鍵のロールオーバー中はゾーン内の署名数が 2倍に増えることである。非常に大きなゾーンの場合、この欠点により 導入の敷居が高くなるかもしれない。利点は 3つの段階しか必要としない ことである。 4.1.2. KSKのロールオーバー KSKのロールオーバーに関してもZSKのロールオーバーと同じ考慮点が当てはまる。 しかし二重署名法によるロールオーバーを使用することで、キャッシュ内に ある旧いデータ(頂点の鍵セットのみ)を新しい鍵セットで検証したり、その逆を 可能とすることを保証できる。KSKは鍵セットだけにしか署名しないので、ゾーン サイズに関する考慮点は当てはまらない。 Kolkman Expires February 2, 2011 [Page 21] Internet-Draft DNSSEC Operational Practices, Version 2 August 2010 -------------------------------------------------------------------- 初期状態 新DNSKEY導入 DS変更 旧DNSKEY削除 -------------------------------------------------------------------- 親側: SOA0 --------> SOA1 --------> RRSIG_par(SOA) --------> RRSIG_par(SOA) --------> DS_K_1 --------> DS_K_2 --------> RRSIG_par(DS) --------> RRSIG_par(DS) --------> 子側: SOA0 SOA1 --------> SOA2 RRSIG_Z_10(SOA) RRSIG_Z_10(SOA) --------> RRSIG_Z_10(SOA) --------> DNSKEY_K_1 DNSKEY_K_1 --------> DNSKEY_K_2 DNSKEY_K_2 --------> DNSKEY_Z_10 DNSKEY_Z_10 --------> DNSKEY_Z_10 RRSIG_K_1(DNSKEY) RRSIG_K_1 (DNSKEY) --------> RRSIG_K_2(DNSKEY) RRSIG_K_2 (DNSKEY) --------> RRSIG_Z_10(DNSKEY) RRSIG_Z_10(DNSKEY) --------> RRSIG_Z_10(DNSKEY) -------------------------------------------------------------------- 二重署名法によるKSKのロールオーバー経過 初期状態: ゾーンの初期状態。親側のDSはDNSKEY 1を指している。鍵のロール オーバーを開始する前に、子はDNSKEY 1を参照しているDS RRのTTL 値を 検証しなければならない。これは鍵のロールオーバーの際に必要なもので、 この値をTTL_DSと呼ぶ。 新DNSKEY導入: "新DNSKEY導入"段階の間に、ゾーン管理者は次のKSKである DNSKEY 2を生成する。この鍵は親側に提供され、子側は親側でDNSKEY 2 を参照する新しいDS RRが生成されるまで待たなければならない。DS RR が親側ゾーンの全権威サーバで公開された後、旧いDS RRがキャッシュから 消去されるのを保証するために、ゾーン管理者はなお少なくとも TTL_DSの間待つ必要がある。 DS変更: 親はDS 1をDS 2に置き換える。 旧DNSKEY削除: DNSKEY 1が削除される。 上に示したシナリオでは、有効な信頼の連鎖を維持する責任を子側に託して いる。また、親はゾーン毎に(1つのアルゴリズムで)1つのDS RRしか保持しない ことを前提としている。これとは別の仕組みも検討されている。信頼の関係を 利用すればやりとりをネットワーク経由で行えるし、子側の鍵削除を親からの 通知によって実行することも可能かもしれない。この仕組みでは、親側に2つの DS RRが存在する期間がある。現時点ではこれらのやりとりに関するプロトコルは 開発されていないため、これ以上の議論は本文書の対象範囲外とする。 Kolkman Expires February 2, 2011 [Page 22] Internet-Draft DNSSEC Operational Practices, Version 2 August 2010 また、上に示したシナリオは、KSKがトラストアンカーとして利用されて いないことを前提としている。トラストアンカーとして利用されている場合、 特別な配慮が払われる必要がある。例えば、RFC 5011を実装したリゾルバが 使用されている場合、上述のDNSKEY 1を削除する段階は、"REVOKE"フラグを 設定した瞬間だが、少なくともRFC 5011記載の保留期間中はDNSKEY 1は依然として 公開され続ける。DNSKEY 1を削除できるのは保留期間終了後だけである。 4.1.3. ZSKのロールオーバーとKSKのロールオーバーの違い KSKのロールオーバーは親とのやりとりが必要であり(またトラストアンカーの 置換が必要な場合がある)、それらの待ち時間に相当する遅延が存在すると いう点で、ZSKのロールオーバーは異なることに注意してもらいたい。 署名鍵のロールオーバーは2つの手法を採ることができる。一つは 事前公開法によるロールオーバー(セクション4.1.1.1)で、もう1つは 二重署名法によるロールオーバー(セクション4.1.1.2)である。 KSKは鍵セットの検証に使用される。KSKはZSKのロールオーバー中には 変更されないので、キャッシュに保存されたKSKを使用してゾーンの新しい 鍵セットを検証することができる。事前公開法によるロールーバーは KSKのロールオーバーでも有効だろう。事前公開されるべきレコードは、親側の DS RRである。当該ロールオーバー法は、KSKの場合に若干問題がある。 以下、当該ロールオーバー法を使用した場合の処理経過についてまず説明し、 その後問題点を提示する。 Kolkman Expires February 2, 2011 [Page 23] Internet-Draft DNSSEC Operational Practices, Version 2 August 2010 -------------------------------------------------------------------- 初期状態 新DS導入 新DNSKEY導入 旧DS/DNSKEY削除 -------------------------------------------------------------------- 親側: SOA0 SOA1 --------> SOA2 RRSIG_par(SOA) RRSIG_par(SOA) --------> RRSIG_par(SOA) DS_K_1 DS_K_1 --------> DS_K_2 DS_K_2 --------> RRSIGpar(DS) RRSIG_par(DS) --------> RRSIG_par(DS) 子側: SOA0 --------> SOA1 SOA1 RRSIG_Z_10(SOA) --------> RRSIG_Z_10(SOA) RRSIG_Z_10(SOA) --------> DNSKEY_K_1 --------> DNSKEY_K_2 DNSKEY_K_2 --------> DNSKEY_Z_10 --------> DNSKEY_Z_10 DNSKEY_Z_10 RRSIG_K_1 (DNSKEY) --------> RRSIG_K_2(DNSKEY) RRSIG2 (DNSKEY) RRSIG_Z_10(DNSKEY) --------> RRSIG_Z_10(DNSKEY) RRSIG10(DNSKEY) -------------------------------------------------------------------- 事前公開法によるKSKのロールオーバー経過 子側が鍵のロールオーバーを行いたい場合、"新DS導入"段階で親に通知し、 新しい鍵(または対応するDS)を親に提示する。親はDNSKEY 1、DNSKEY 2をそれ ぞれ参照するDS 1、DS 2を公開する。鍵のロールオーバー期間中("新DNSKEY導入" 段階の間)、すなわち新しいDSセットがDNSを経て伝搬された後すぐに、子は DNSKEY 1をDNSKEY 2に置き換える。その直後("旧DS/DNSKEY削除"段階で)、 子は親に旧いDSレコードを削除可能であると通知することができる。 このロールオーバー法の問題は、"新DS導入"段階の間はDNSKEY 2が公開されて いないため、親がDNSを使用してDS 2が正しくDNSKEY 2を参照しているかを 検証できないことである。なお、本文書において"DNSSEC Lame"な鍵という概念を 導入する(セクション4.3.3参照)。さらに、子と親のやりとりが2段階必要 というのも問題である。"二重署名法"は一度のやりとりしか必要としない。 4.1.4. 単一鍵署名方式におけるロールオーバー 単一鍵署名方式使用時におけるDNSKEYのロールオーバーには、KSKやZSKのロール オーバーと同様に次に示す要求の制約がある。すなわち、ゾーンデータと遠隔の キャッシュに保存されたデータのあらゆる組合せが検証できるように、ロール オーバーのいずれに時点においても、信頼の連鎖が保たれている必要がある。 Kolkman Expires February 2, 2011 [Page 24] Internet-Draft DNSSEC Operational Practices, Version 2 August 2010 このロールオーバーには2種類の派生型がある。単一鍵署名方式を選択する 動機は運用が単純であることだから、初めに最も単純なロールオーバー法 を記述する。 ---------------------------------------------------------------- 初期状態 新DNSKEY導入 DS変更 旧DNSKEY削除 ---------------------------------------------------------------- 親側: SOA0 --------> SOA1 --------> RRSIG_par(SOA) --------> RRSIG_par(SOA) --------> DS1 --------> DS2 --------> RRSIG_par(DS) --------> RRSIG_par(DS) --------> 子側: SOA0 SOA1 ------------> SOA2 RRSIG_S_1(SOA) RRSIG_S_1(SOA) ------------> RRSIG_S_2(SOA) RRSIG_S_2(SOA1) ------------> DNSKEY_S_1 DNSKEY_S_1 ------------> DNSKEY_S_2 DNSKEY_S_2 ------------> RRSIG_S_1(DNSKEY) RRSIG_S_1(DNSKEY) ------------> RRSIG_S_2(DNSKEY) RRSIG_S_2(DNSKEY) ------------> ----------------------------------------------------------------- 単一鍵署名方式使用時における単純なロールオーバー法の経過 初期状態: 親ゾーンのDSは子ゾーンのDNSKEY 1を参照している。ゾーンの全ての RRsetはDNSKEY 1で署名されている。 新DNSKEY導入: 新しい鍵(DNSKEY 2)を導入し、全てのRRsetをDNSKEY 1および DNSKEY 2で署名する。 DS変更: 2つの鍵を含むDNSKEY RRsetが遠隔のキャッシュに伝搬するために充分な 時間が経過した(つまりDNSKEY 1のみが含まれるDNSKEY RRsetがキャッシュから 消去された)後に、DSレコードの変更を行うことができる。 旧DNSKEY削除: DS 1を含むDS RRsetが遠隔のキャッシュから消去された後に、 DNSKEY 1をDNSKEY RRsetから削除できる。 単一鍵署名方式使用時におけるDNSKEYのロールオーバーの2つめの派生型は、 新DNSKEYをDNSKEY RRsetに加えて新旧の鍵でDNSKEY RRsetに署名を行い、 ゾーンデータはDNSKEY 1だけで署名するというものである。DNSKEY 1を削除する 際に、DNSKEY 1による署名をDNSKEY 2による署名に置き換える。 Kolkman Expires February 2, 2011 [Page 25] Internet-Draft DNSSEC Operational Practices, Version 2 August 2010 この2つめの派生型は、ゾーン規模を考慮するとゾーンデータ全体への二重 署名は困難であるような場合に検討され得るが、そのような際はKSKとZSKを 分離するほうが良い選択だろう。 二重DS法によるロールオーバー(訳注: 新旧DSを共存させる方法)は単一鍵署名 方式使用時でも有効である。ただし、信頼の連鎖を有効に保つためには、 ゾーンデータを二重署名するか新旧の鍵を含むDNSKEY RRsetを公開する必要がある。 これは親子ゾーンにおいてゾーン及びパケットのサイズを増加させることになる ので、単一鍵署名法使用時にこのロールオーバー法を使うメリットはほとんどない。 4.1.5. 鍵アルゴリズムのロールオーバー 鍵アルゴリズムの変更には特殊なロールオーバーが必要となる(新アルゴリズムの 追加、旧アルゴリズムの削除とも)。この際には、ロールオーバー中の (訳注: 信頼の連鎖の)完全性を保つために追加の手順を必要とする。 RFC 4035のセクション2.2記載のアルゴリズムのダウングレードに対する防御と して、署名を行わないアルゴリズムの鍵を保持しない場合や、ゾーン頂点に 対応するアルゴリズムの鍵が存在しないDSレコードを親ゾーンに登録しない 場合もあるだろう。 新アルゴリズムの追加時には、署名を初めに追加すべきである。RRSIGの TTL時間が経過し、旧い署名によりカバーされたデータがキャッシュから 消去された後に、新アルゴリズムのDNSKEYを追加することが可能となる。 新アルゴリズム追加後、二重署名法によるロールオーバーを使用して DSレコードを更新することができる。鍵アルゴリズムのロールオーバーの場合、 事前公開法によるロールオーバーは使用できない。 旧アルゴリズムを削除する際はDNSKEYを初めに削除すべきだが、 旧アルゴリズムのDSレコードが親ゾーンから削除された後にしか行えない。 以下の図に経過を示す。ここで、アンダースコア付きの数字はアルゴリズムを 示し、ZSK及びKSKは鍵の使途の区別を明示している。例えば、DNSKEY_KSK_1は アルゴリズム1の旧KSKの公開鍵を表すDNSKEY RRであり、RRSIG_ZSK_2(SOA3)は アルゴリズム2の新ZSKの秘密鍵によってSOA RR(シリアル番号3)に署名を行った際に 生成されるRRSIG RRである。SOA RRに署名する鍵はDNSKEY RRset以外の全ての RRsetに署名を行うものと想定している。 Kolkman Expires February 2, 2011 [Page 26] Internet-Draft DNSSEC Operational Practices, Version 2 August 2010 ---------------------------------------------------------------- 1 初期状態 2 新RRSIG追加 3 新DNSKEY導入 ---------------------------------------------------------------- 親側: SOA0 -------------- ( SOA ) --------------> RRSIG_par(SOA) -------------------------------------> DS_K_1 -------------------------------------> RRSIG_par(DS_K_1) -------------------------------------> 子側: SOA0 SOA1 SOA2 RRSIG_Z_1(SOA) RRSIG_Z_1(SOA) RRSIG_Z_1(SOA) RRSIG_Z_2(SOA) RRSIG_Z_2(SOA) DNSKEY_K_1 DNSKEY_K_1 DNSKEY_K_1 DNSKEY_Z_1 DNSKEY_Z_1 DNSKEY_Z_1 RRSIG_K_1(DNSKEY) RRSIG_K_1(DNSKEY) DNSKEY_K_2 RRSIG_K_2(DNSKEY) DNSKEY_Z_2 RRSIG_K_1(DNSKEY) RRSIG_K_2(DNSKEY) ---------------------------------------------------------------- 4 DS変更 5 旧DNSKEY削除 6 旧RRSIG削除 ---------------------------------------------------------------- 親側: SOA1 -------------( SOA )----------------> RRSIG_par(SOA) -------------------------------------> DS_K_2 -------------------------------------> RRSIG_par(DS_K_2) -------------------------------------> 子側: ---- (SOA2 ) ---> SOA3 SOA4 ----------------> RRSIG_Z_1(SOA3) RRSIG_Z_2(SOA4) ----------------> RRSIG_Z_2(SOA3) ----------------> DNSKEY_K_2 DNSKEY_K_2 ----------------> DNSKEY_Z_2 DNSKEY_Z_2 ----------------> RRSIG_K_1(DNSKEY) RRSIG_K_2(DNSKEY) ----------------> RRSIG_K_2(DNSKEY) ---------------------------------------------------------------- 鍵アルゴリズムのロールオーバー経過 ステップ1: 移行前のゾーン状態を示す。鍵数に変動幅はあり得るが、 鍵アルゴリズムはゾーンの全DNSKEYレコードで共通であるものとする。 Kolkman Expires February 2, 2011 [Page 27] Internet-Draft DNSSEC Operational Practices, Version 2 August 2010 ステップ2: ゾーンの全レコードに対して新しい鍵で生成した署名を追加する。 この段階では鍵そのものはまだ追加しない。署名はDNSKEY RRsetに対するものも 含む。理論上は鍵セットと鍵セットの署名は常に同期しているべきであるが、 RRSIGのみを個別に登録することも可能である。DNSKEY RRsetに新アルゴリズムの 署名を行っておくことは周到なやり方である。 ステップ3: キャッシュのデータが消去された後、新しい鍵をゾーンに追加する ことができる。 ステップ4: 旧DNSKEYのキャッシュデータが消去された後、新しい鍵を参照する DSレコードを親ゾーンに登録し、同時に旧い鍵を参照するDSレコードを削除する ことができる。 ステップ5: 旧DSレコードのキャッシュデータが消去された後、旧アルゴリズムを 削除することができる。この際、署名の削除に先立ち、鍵を削除する必要がある。 このステップにおいて鍵を削除し、DNSKEYのキャッシュデータが消去された後、 署名を削除することができる。 特殊な事例として、署名ゾーンにおいてNSECからNSEC3にロールオーバーする場合 が挙げられる。この際、アルゴリズム番号はNSEC3対応の通知に用いるが、NSEC3の 使用は必須ではない。したがって、新アルゴリズムへのロールオーバーが完了し、 新DNSKEY RRsetが遠隔のキャッシュに伝搬するまでは(ステップ4であれば 最低1TTL経過後、ステップ5であれば随時)、NSECレコードをゾーンに残存させる べきである。この際、NSEC3に対応していないバリデータは、信頼の連鎖を 新アルゴリズムのDNSKEYに対応するDSまで辿った時点でゾーンを"Secure"ではない とみなす。一方、NSEC3に対応したバリデータは、NSECを使用して検証をうまく 行うことができる。次に、ゾーンのシリアル番号を更新し、ゾーンの再署名を 行う際に、NSEC3PARAMレコードを導入して権威サーバにNSEC3による不在証明の 対応開始を通知すると、NSEC3が有効になる。 4.1.6. 鍵のロールオーバーの自動化 鍵は定期的に更新しなければならないので、ロールオーバーを自動化したい という動機は少なからず存在する。これには以下のような考慮点がある。 ・ ZSKのロールオーバーは子ゾーンのみで実施できるため、自動化は容易 である。 ・ KSKのロールオーバーには親子ゾーンの連携が必要となる。新しい鍵を 親ゾーンに提供するためにデータのやりとりが必要である。結果として、 ロールオーバーにおける攻撃を回避するため、このデータの認証と完全性の 保証を行わなければならない。 Kolkman Expires February 2, 2011 [Page 28] Internet-Draft DNSSEC Operational Practices, Version 2 August 2010 4.2. 鍵の緊急ロールオーバー 本セクションは、鍵の漏洩に対する準備を扱う。鍵の漏洩が疑われる、または 確認された場合に備えて、文書化された手続きを準備しておくことを推奨する。 ある鍵の秘密鍵部分が漏洩した場合でも、有効な信頼の連鎖が存在している限りは 使用することができる。信頼の連鎖は、以下の条件が満たされている間は、 損なわれずに維持される。 ・信頼の連鎖に含まれる、漏洩した鍵の署名が有効である。 ・親ゾーンのDS RRが漏洩した鍵を参照している。 ・漏洩した鍵がリゾルバでトラストアンカーとなっており、検証の起点 として使用されている(一般に、更新が最も困難となる)。 漏洩した鍵までの信頼の連鎖が存在する場合、不当にその鍵の所有権を得た 何者かがその機能を濫用することにより、名前空間は脆弱になる。 ゾーン管理者は、漏洩した鍵の濫用か、キャッシュに残されたデータが検証 できなくなるか、どちらがより望ましくないかというトレードオフの判断を しなければならない。ゾーン管理者が漏洩した鍵に対応するために信頼の連鎖を 壊すという選択をした場合、 キャッシュに残された漏洩した鍵で署名された データは検証できなくなる。しかし、ゾーン管理者が標準的な鍵のロール オーバー手順を選択した場合、悪意を持った鍵の保有者はロールオーバー期間中は データを改ざんできるため、不正なデータであっても一見有効に見えることに なるだろう。 4.2.1. KSKの漏洩 漏洩したKSKを含むDNSKEY RRsetを持つゾーンは、漏洩したKSKがトラストアンカー として設定されているか、または親ゾーンのDSレコードが当該KSKを参照している 限り脆弱である。 攻撃者は、漏洩したKSKを使用して攻撃者が用意したゾーンの鍵セットに署名する ことができる。そのゾーンを使用してDNSを汚染(偽造情報を挿入する)できて しまう可能性がある。 したがって、KSKが漏洩した場合、トラストアンカーまたは親のDSレコードを 可能な限り早く置き換えるべきである。緊急時に行う鍵のロールオーバー期間中に 信頼の連鎖を壊すかどうかはローカルポリシーに依存する。親のDSレコードが 依然として漏洩したKSKを参照していても、子ゾーンから漏洩したKSKが削除される 際に、信頼の連鎖は壊れるだろう。(これは親にはDSレコードが1つしか無い場合 である。複数のDSレコードが存在する場合はこの限りではないが、漏洩した 特定の鍵に関する信頼の連鎖はやはり壊れることになる)。 Kolkman Expires February 2, 2011 [Page 29] Internet-Draft DNSSEC Operational Practices, Version 2 August 2010 攻撃者が用意したゾーンが依然として漏洩したKSKを使用しており、親側に 対応するDSが存在している場合、そのゾーンのデータは有効であるように見える ことに注意してもらいたい。漏洩した鍵を削除すると、攻撃者のゾーンは 有効だが、その子ゾーンは"Bogus"に見えるようになる。したがって、親側で 新しいKSKを参照するDSレコードが公開される前に漏洩したKSKを削除しないよう 勧告する。 4.2.1.1. 信頼の連鎖を維持する場合 先に述べた勧告に従う場合、KSK置き換えのタイミングが重要になる。目標は、 親側で新しいDS RRが公開されたら直ちに漏洩したKSKを削除することである。 つまり、漏洩したKSKを含む鍵セットへの新しいKSKによる署名の有効期間が、 親側で新しいDSが公開された直後に終了することを保証しなければならない。 漏洩したKSKを含む鍵セットの署名有効期間が終了すると、キャッシュから その鍵セットが消去される 手続きは以下のとおりである。 1. 新しいKSKを鍵セットに導入する。この段階では漏洩したKSKはまだ 鍵セット内で保持される。 2. 鍵セットに署名する。この際短い有効期間を指定する。この有効期間は、 親側で新しいDSが公開され、旧いDSがキャッシュから消去されるまでの 期間よりも少しだけ長めに設定すべきである。 3. 新しい鍵を参照するDSを親に送付する。 4. 標準的なKSKのロールオーバーを行う。すなわち、権威サーバでDSが公開 されるまで待ち、その後旧いDS RRのTTLが終了するまで待つ。必要であれば、 DNSKEY RRsetに再署名し、有効期間終了時刻を修正/延長する。 5. 漏洩したDNSKEY RRをゾーンから削除し、"通常の"有効期間で鍵セットに 再署名する。 鍵の漏洩に関する付加的な脅威として、正規のDNSKEY/DSの変更や親側における ネームサーバの変更等の処理の際に漏洩した鍵が使用されるかもしれないことが 挙げられる。このような事態が生じると、そのドメインは混乱に陥る。 こうなると、親と連絡を取るために、ネットワーク以外の認証手段と、安全な 通知の仕組みが必要となる。 これはDNSKEYまたはDSレコードが親側で認証に使用されている場合にだけ 問題になることに注意してもらいたい。 Kolkman Expires February 2, 2011 [Page 30] Internet-Draft DNSSEC Operational Practices, Version 2 August 2010 4.2.1.2. 信頼の連鎖を壊す場合 信頼の連鎖を壊すには二つの方法がある。最初の方法は、署名を検証するリゾルバ からは子ゾーンが"Bogus"に見えるものである。もう一つの方法は、 子ゾーンが"Insecure(未署名状況検出:信頼度低)"と見えるものである。 それぞれについて以下に記述する。 署名を検証するリゾルバから子ゾーンが"Bogus"に見えることになる方法は、 子ゾーンが現在のKSKを新しいものに置き換え、それで鍵セットに署名するという ものである。次に子は新しい鍵に対応したDSを親に送信する。親がゾーン内に 新しいDSを公開した後に、信頼の連鎖は修復される。 信頼の連鎖を壊す別の方法は、親ゾーンのDS RRも同時に削除するというもの である。結果として、子ゾーンは"Insecure"となる。 4.2.2. ZSKの漏洩 ZSKが漏洩した場合、親とのやりとりは必要ないため、事態はKSKの漏洩ほど 深刻ではない。それでもなお、ゾーンは可能な限り早く新しいZSKで再署名する 必要がある。これはローカルな処理であり、親子間で通信を必要としないため、 かなり迅速に処理できる。しかし、通常の鍵のロールオーバーと同様に、 漏洩した旧い鍵を直ちに削除してしまうと、検証に問題が発生する場合がある ことを考慮しなければならない。また、漏洩したZSKによるRRSIGがキャッシュから 消去されるまでは、ゾーンは依然として危険であることにも注意してもらいたい。 4.2.3. リゾルバでトラストアンカーとして使用されている鍵の漏洩 鍵はリゾルバにあらかじめ設定されることがあり得る。例えば、DNSSECがうまく 展開した場合、ルート(root)の鍵はほとんどのセキュリティ対応リゾルバに あらかじめ設定されることになるだろう。 トラストアンカーとして使用される鍵が漏洩した場合、その鍵を使用する リゾルバ管理者には漏洩の事実が通知されるべきである。ゾーン管理者は、 SEP鍵をロールオーバーしようとしているという事実を連絡するために、 メーリングリストの構築を検討してもよいだろう。この連絡は、もちろん デジタル署名のような何らかの認証手段を必要とする。 トラストアンカーとして使用する鍵の更新作業に直面したエンドユーザは、 常に新しい鍵を検証すべきである。新しい鍵は、DNS以外の手段、例えばTLS[22]に よって安全を確保した告知Webサイトを参照するなどして認証されるべきである。 Kolkman Expires February 2, 2011 [Page 31] Internet-Draft DNSSEC Operational Practices, Version 2 August 2010 4.3. 親側のポリシー 4.3.1. 最初の鍵交換および親側のポリシーに関する考慮点 最初の鍵交換は常に親が設定するポリシーの制約を受ける。この事実は レジストリ-レジストラモデルでは極めて重要である。当該モデルにおいては、 鍵情報はDNS運用者からレジストラを経由して(親の)レジストリに転送され、 またDNS運用者とレジストラは共にドメイン名登録者によって選択されるので それぞれが別組織の場合もあるからである。鍵交換のポリシーを設計する際には、 鍵交換時に使用される認証・認可の仕組みは、親子間で委任情報を交換する際に 使用する認証・認可の仕組みと同程度に強くすべきだということを考慮すべき である。すなわち、DNSSECの認証処理を通常のDNSの認証処理よりも強くしなければ ならないという暗黙の要請は存在しない。 実際のDNSKEY鍵情報の入手先としてDNSそれ自体を使用し、DNS以外の手段で そのDNSKEYの有効性を検査すると、ユーザーの間違いを低減させる効果がある。 DNSKEY検索ツールは、SEPビット[5]を利用してDNSSEC鍵セットから適切な鍵を 選択できるので、誤ったDNSKEYが送信されてしまう機会を減らすことができる。 当該ツールは鍵の自己署名も検証できるので、秘密鍵の鍵情報の所有者を検証 することができる。DNSからDNSKEYを取得できるということは、親が子を "Secure"だと示すDS RRを公開して以後信頼の連鎖が完全に維持されていることを 保証している。 注: 鍵情報をDNS経由で取得する場合、依然としてDNS以外の手段による 検証が必要である。親はDNSKEY RRが偽造されていないことを保証できない。 4.3.2. 鍵を保存するか、ハッシュを保存するか レジストリシステムを設計する際には、DNSKEYと対応するDSのうち、どちらを 保存するかを考慮すべきである。子ゾーンはレジストリがまだ対応していない メッセージダイジェストアルゴリズムを使用するDSの公開を希望するかも しれないので、レジストリが素(raw)のDNSKEYからDSレコードを生成することは あてにできない。したがって、レジストリシステムは少なくともDSレコードの 保存をサポートすることを推奨する(draft-ietf-dnsop-dnssec-trust-anchor [26]も参照のこと)。 DNSKEYを保存しておくことも有用である。DNSKEYを保存しておけばトラブル シューティングの助けになるし、子が選択したメッセージダイジェストを レジストリがサポートしている限りにおいては、DNSKEYからDSレコードを 生成するオーバーヘッドを最小にすることができる。レジストリディレクトリ (例えばWhois)のようなDNS以外の仕組みを用意しておけば、特定の所有者または ゾーンがDSリソースレコードを生成する際に使用した鍵を発見できるため、 トラブルシューティングの助けとなるだろう。 Kolkman Expires February 2, 2011 [Page 32] Internet-Draft DNSSEC Operational Practices, Version 2 August 2010 顧客向けインターフェースの設計やレジストリ-レジストラ間のデータ転送方式も 何を保存すべきかという考慮点に関係する。子ゾーンの管理者は、未知のハッシュ アルゴリズムで生成されたDS RRをアップロードできるだろうか?またDNSKEYしか 受け付けないインタフェースなのだろうか?レジストリが拡張可能な資源登録 プロトコル(EPP)[17]に対応しているならば、EPPプロトコルはDSとDNSKEY RR (任意)の両方の転送に対応しているので、レジストリ-レジストラ間の インターフェースとして利用可能である。顧客とレジストラの間のデータ転送に 関して標準化された方法は存在しない。Webインターフェースから種々のAPI といったように、レジストラが異なれば方法も異なる。EPPのDNSSEC拡張が 利用可能なこともある。 4.3.3. DNSSEC Lame DNSSEC Lameとは、親側のDS RRが存在しないDNSKEY RRを参照している状態 として定義される。 DSを2つ公開するロールオーバー法を使用する場合、 DNSSEC Lameが一時的に発生することがある。しかし、子ゾーンが署名検証を行う DNSクライアントに"Bogus"と判定されてしまわないよう、DS RRの全てが DNSSEC Lameとならないよう注意を払うべきである。 包括的な委任検査の一環として、親は鍵交換時に子の鍵がDNS内に実際に設定 されているかどうかを確認できるだろう。しかし、親が子の使用するハッシュ アルゴリズムに対応していなければ、親の検査は鍵IDの比較だけに限定される。 子ゾーンがDNSKEYの鍵情報を削除する際、特にDS RRが存在するSEP鍵を 削除する際は、非常に慎重に行うべきである。 一旦ゾーンが"DNSSEC Lame"になると、その修正(つまりDS RRの削除)がDNSに 行き渡るまで時間を要する。 4.3.4. DSの署名有効期間 DSは有効な署名が存在する限り再利用できてしまうが、DSのRRSIGの 有効期間を短くすることで、子ゾーンのKSKが漏洩した場合に子ゾーンが 脆弱である時間を最短にすることができる。極端に短い署名有効期間にすると、 署名ツールが設定エラーを起こした場合にゾーンが"Bogus"と判定される可能性が 生じる。署名有効期間が終了するまでの時間は、問題解決に要する時間に対して 充分ではないかもしれない(この一般論についてはセクション4.4.2を参照)。 週末に運用者と連絡がつかないことはよくあると考えられることから、 DSの署名有効期間は2日よりも長くする必要があるだろう。DSの署名有効期間の 絶対的な最小値を2~3日とすることを推奨する。 Kolkman Expires February 2, 2011 [Page 33] Internet-Draft DNSSEC Operational Practices, Version 2 August 2010 DSレコードの最大署名有効期間は、鍵の漏洩後、子ゾーンがどの程度の期間 脆弱であることを許容するかに依存する。一方で、DSの署名有効期間を短く すると、親側の運用に関するリスクが増大する。したがって、親は子が希望する よりも充分に長い署名有効期間を使用するというポリシーを設定してもよい。 親の運用上の制約と、子のダメージを最小にするという希望の妥協により、 DSの署名有効期間が1週間~数ヶ月となる場合もある。 署名有効期間は、ゾーン所有者がゾーンデータに署名をしなければならない 回数の下限を与え、また鍵の漏洩後に子ゾーンが脆弱である期間の上限を 与えるが、それに加えてDS RRのTTL値が存在する。TTLを短くするということは、 権威サーバがより多くの問合わせを受けることを意味する。しかし一方で、 TTLを短くするとキャッシュ内のDS RRの保持期間が短くなるので、 更新したDS RRsetがDNSを伝搬する速度が速くなる。 4.3.5. DNS運用者の変更 親子ゾーンの関係は、しばしば(関係の希薄な("thin"))レジストリモデルの観点で 記述される。このモデルでは、レジストリが親ゾーンを維持し、登録者(子ゾーンの ドメイン名所有者)は、レジストラと呼ばれる仲介者を介してレジストリと やりとりを行う(完全な記述については[11]を参照のこと)。登録者は、DNSSECの 鍵情報の維持管理を含むDNSシステムの管理をレジストラや他の第三者組織に 委託する場合がある。これを"DNS運用者"と呼ぶことにする。この際、DNS運用者は 登録者のDNSゾーンを掌握しており、登録者がタイムリーに他のDNS運用者に 移転することを妨げる場合がある。 様々な理由により、登録者がDNS運用者を移転したくなることがある。この 移転が容易であるかどうかは、原理的に登録者の移転元DNS運用者(移転元運用者と 呼ぶ)に依存する。なぜなら、移転元運用者がDNSゾーンとその鍵を掌握している からである。以下のセクションでは、移転元運用者が新規の運用者(移転先運用者と 呼ぶ)に対して協力的な場合と非協力的な場合の2通りを示すことにする。 4.3.5.1. 移転元DNS運用者が協力的な場合 このシナリオでは、移転元運用者は秘密鍵情報を移転先運用者に渡さないが (これが一般的な事例だろう)、その他においては完全に協力的である場合を 想定している。 Kolkman Expires February 2, 2011 [Page 34] Internet-Draft DNSSEC Operational Practices, Version 2 August 2010 この状況下では、移転元運用者が移転先運用者のZSKを用いて事前公開法による ロールオーバーと、二重署名法によるKSKのロールオーバーを組み合わせて移転を 進めることができる。KSKのロールオーバーは、双方の運用者が互いのKSK公開鍵を 交換し、それぞれの鍵セットに加える(訳注: 移転元運用者のDNSKEY(KSK)と 移転先運用者のDNSKEY(KSK)を両方含むDNSKEY RRsetになる)。その上で、 組み合わせた鍵セットに対してお互いに署名を生成し、それら(鍵セットと署名)を それぞれのゾーンで公開するという手順で行われる。一旦これが行われれば、 移転期間を通じて、それぞれのゾーン情報に対してそれぞれの秘密鍵による 署名を行うことができる。 ------------------------------------------------------------ 初期状態 | 事前公開 | ------------------------------------------------------------ 親側: NS_A NS_A DS_A DS_A ------------------------------------------------------------ 子側(運用者A管理): 子側(運用者A管理): 子側(運用者B管理): SOA_A0 SOA_A1 SOA_B0 RRSIG_Z_A(SOA) RRSIG_Z_A(SOA) RRSIG_Z_B(SOA) NS_A NS_A NS_B RRSIG_Z_A(NS) NS_B RRSIG_Z_B(NS) RRSIG_Z_A(NS) DNSKEY_Z_A DNSKEY_Z_A DNSKEY_Z_A DNSKEY_K_A DNSKEY_Z_B DNSKEY_K_B RRSIG_Z_A(DNSKEY) DNSKEY_K_A DNSKEY_K_A RRSIG_K_A(DNSKEY) DNSKEY_K_B DNSKEY_K_B RRSIG_Z_B(DNSKEY) RRSIG_Z_B(DNSKEY) RRSIG_K_B(DNSKEY) RRSIG_K_B(DNSKEY) RRSIG_Z_A(DNSKEY) RRSIG_Z_A(DNSKEY) RRSIG_K_A(DNSKEY) RRSIG_K_A(DNSKEY) ------------------------------------------------------------ ------------------------------------------------------------ 再委任 | 移転完了 | ------------------------------------------------------------ 親側: NS_B NS_B DS_B DS_B ------------------------------------------------------------ 子側(運用者A管理): 子側(運用者B管理): 子側(運用者B管理): SOA_A2 SOA_B1 SOA_B2 RRSIG_Z_A(SOA) RRSIG_Z_B(SOA) RRSIG_Z_B(SOA) NS_A NS_B NS_B NS_B RRSIG_Z_B(NS) RRSIG_Z_B(NS) Kolkman Expires February 2, 2011 [Page 35] Internet-Draft DNSSEC Operational Practices, Version 2 August 2010 RRSIG_Z_A(NS) DNSKEY_Z_A DNSKEY_Z_A DNSKEY_Z_B DNSKEY_Z_B DNSKEY_Z_B DNSKEY_K_B DNSKEY_K_A DNSKEY_K_A RRSIG_Z_B(DNSKEY) DNSKEY_K_B DNSKEY_K_B RRSIG_K_B(DNSKEY) RRSIG_Z_B(DNSKEY) RRSIG_Z_B(DNSKEY) RRSIG_K_B(DNSKEY) RRSIG_K_B(DNSKEY) RRSIG_Z_A(DNSKEY) RRSIG_Z_A(DNSKEY) RRSIG_K_A(DNSKEY) RRSIG_K_A(DNSKEY) ------------------------------------------------------------ 移転元運用者が協力的な場合のロールオーバー経過 本図において、Aは移転元運用者、Bは移転先運用者を示す。RRSIG_ZはZSKによる RRSIG、RRSIG_KはKSKによるRRSIG、添字_A、_Bは鍵ペアの生成者を示す。 "子側(運用者A管理)"という表記は、移転元運用者がどのようにゾーン情報を保持 するかを、また"子側(運用者B管理)"は移転先運用者がどのようにゾーン情報を 保持するかを示している。 4.3.5.2. 移転元DNS運用者が非協力的な場合 移転元DNS運用者が非協力的な場合、問題はより複雑になる。移転元運用者は 移転に協力せず、DNSデータをそのまま放置するかもしれない。極端な場合には、 移転元運用者が移転妨害者となり、極めて長いTTLと署名有効期間を設定する ことで、運用者AのDNSKEYが(少なくとも理論上は)数十年に渡ってキャッシュに 残り続けるよう設定したDNSKEYを公開する可能性がある。 移転元運用者から移転先運用者への再委任が終了した後に、バリデータが委任元 運用者の鍵を用いて検証を試みる場合、移転元運用者の鍵による署名が委任経路に 存在しないと問題が生じる。移転先運用者が移転元運用者の生成した全ての RRSIGを入手し、それらの署名を自身のもの(移転先運用者が生成した署名)と併せて 公開するというロールオーバーシナリオを考えることもできる。しかしこの場合、 ゾーン情報には如何なる変更も行えなくなる。定義により、再委任を行うと NS RRsetが変更されるので、このロールオーバーシナリオはうまく行かない。 加えて、移転元運用者がゾーン転送を禁止しており、また当該ゾーンにおいて NSEC3を使用している場合、移転先運用者は移転元運用者のRRSIGをゾーンに全て 移行したという確証を得ることはできないだろう。 登録者が実行可能な唯一の選択肢は、移転元運用者のDNSKEYもしくは何らかの 署名がキャッシュに残っていると思われる間(前述の通り理論上数十年と なり得る)はゾーンの署名を止め、委任元運用者のDNSKEYを参照するDS RRの 削除をレジストリに依頼するということくらいである。 Kolkman Expires February 2, 2011 [Page 36] Internet-Draft DNSSEC Operational Practices, Version 2 August 2010 実装によっては[OK: ほとんどまたは全て?]署名を検証できないと思われる DNSKEYのキャッシュ時間を制限し、そのDNSKEYによる署名検証が不能な状況からの 回復を試みるものがあることに注意してもらいたい。これはプロトコル要件では ないが、このような処理は非協力的なDNS運用者の問題による影響を軽減できると 思われる。 しかし、このビジネス上の問題に対処するための運用方式は存在しないので、 関係者全ての間で適切な契約関係を結んでおくことが本問題に対処する唯一の 解決策と思われる。すでに多くの事例で、ゾーンのDNS運用者を移転する際に、 委任が一時的に壊れることが発生していることに留意すべきである。加えて、 DNS運用者が変更される場合、ぞのゾーンに関わるサービスの運用者も変更される こともあり、おそらくは多少のサービス不能状態が発生しているだろう。 いずれにせよ、この問題の影響を最小化するための昔ながらの推奨事項は、 関係する全てのリソースレコードのTTLを短めにしておく、ということである。 これにより、DNSSECを使用しているかどうかによらず、ゾーンの変更に関わる 多くの問題が解決するだろう。 4.4. DNSSECにおける時間 DNSSECを使用しない場合、DNSにおける時間は全て相対的である。SOAフィールドの REFRESH、RETRYおよびEXPIRATIONは、スレーブサーバがマスターサーバと同期した 後の経過時間を決定するために使用するタイマーである。またTTL値およびSOA RRの 最小TTLパラメータ[9]は、フォワーダ(forwarder)が権威サーバより データを 取得した後に、どの程度の期間キャッシュすべきかを決定するために使用する。 DNSSECはDNSに絶対時間の概念を導入し、署名有効期間で使用している。 DNSSECで使用される署名には期限終了日があり、それ以後署名は無効と判定され、 署名データは"Bogus"と見なされる。 本セクションにおける考慮点は全て定性的なものであり、運用・管理上の問題に 焦点を当てたものである。ロールオーバーのタイミングパラメータに関するより 詳細で定量的な分析は draft-ietf-dnsop-dnssec-key-timing [24]に記載がある。 4.4.1. 時間に関する考慮点 署名に有効期限が設定されるため、以下の点を考慮すべきである。 Kolkman Expires February 2, 2011 [Page 37] Internet-Draft DNSSEC Operational Practices, Version 2 August 2010 ・ゾーンデータの最大ゾーンTTLを署名有効期間に対してごく小さな割合にする ことを推奨する。 TTLが署名有効期間とほぼ同じ長さである場合、署名有効期間中に キャッシュサーバに取得されたRRsetは、全て署名有効期間終了まで キャッシュされるだろう。RFC 4033[3]のセクション8.1では、"署名 付きRRsetの署名有効期限までの残り時間を、キャッシュ内にあるその RRsetと関連するRRSIG RRのTTLの上限値として使用することはできる"と 示唆している。結果として、権威サーバの問合わせ負荷は署名有効期間 終了時に最大になる。この際、同時にレコードがキャッシュから消去 されるからである。 問合わせ負荷の急増を避けるため、ゾーン内にある全RRのTTLを 少なくとも署名有効期間の数分の一にすることを推奨する。 ・署名公開期間は、署名有効期限から少なくとも最大ゾーンTTL期間遡った 時点より前に終了させることを推奨する。 署名有効期間終了直前にゾーンに再署名すると、(訳注: 新しい署名が キャッシュされる機会がないまま)キャッシュからデータおよび署名が同時に 消去される可能性がある。その結果、権威サーバの負荷がピークになる 状態が生じるかもしれない。これを避けるため、ゾーンデータの再署名が 必要かどうかを定期的に確認し、署名有効期間終了までの残り時間が いわゆるリフレッシュ期間以内の署名については再生成するという方式が 展開されている。後述のセクション4.4.2も参照のこと。 ・最小ゾーンTTLを、信頼の連鎖内の全RRを取得し、検証する時間に対して 充分長いものにすることを推奨する。ワークショップ環境において、小さい TTL(5分ないし10分未満)を設定すると、以下の2つの問題により破綻することが 実証されている[18]。 1. 検証の際に、幾つかのデータが検証完了前に消去されてしまう場合が ある。バリデータは検証が完了するまで全データを維持できるように すべきである。これは信頼の連鎖をひととおり構築するために必要な 全てのRR、すなわちDS、DNSKEY、RRSIG、および最終的な回答 (最初の問い合わせに対して返されるRRset)の全てに対して適用される。 2. 頻繁な署名検証は再帰ネームサーバに負荷をかける。委任点にある データ、DS、DNSKEYおよびRRSIGはキャッシュの恩恵を受けるので、 これらのTTLは相対的に長くすべきである。 Kolkman Expires February 2, 2011 [Page 38] Internet-Draft DNSSEC Operational Practices, Version 2 August 2010 ・スレーブサーバは、提供するゾーン内のRRSIGが署名有効期間終了時刻を 過ぎる十分前に、新しい署名ゾーンを取得できる必要があるだろう。 スレーブサーバとマスターサーバの同期がずれており、ゾーン内のデータの 署名が有効期限を過ぎている場合、スレーブサーバは応答を返さない方が よいだろう。 通常、長期間マスターサーバと通信できないスレーブサーバはゾーン を消去する。このような事態が発生すると、そのゾーンへの問合わせ に対して、スレーブサーバは異なる応答を返すだろう。あるサーバは SERVFAILを返すし、別のものは回答の"AA"ビットをクリアする。 ゾーンを消去する時間はSOAレコードに設定されており、マスターサーバと スレーブサーバの間で最後にリフレッシュに成功した時刻からの相対的な 時間である。ゾーン内のRRSIGの署名有効期間とSOAのゾーン消去パラメータ には何も関係はない。 サーバがDNSSECゾーンを提供している場合、SOAのゾーン消去タイマーが ゼロにカウントダウンされる遥か以前に署名有効期間が終了することは 充分にあり得る。SOAパラメータを調整してこれを完全に防ぐことは不可能 である。 しかし、SOAのゾーン消去時間を署名有効期間と同じか短く設定すれ ば、影響を最小化することができる。 権威サーバが長期間ゾーンを更新できなければ、結果として署名が キャッシュから消去される。この場合、DNSSEC非対応のリゾルバは特定の スレーブサーバから取得したデータを使用して名前解決が可能であり続ける のに対し、DNSSEC対応リゾルバでは回答を"Bogus"と判定するという問題が 生じる。 本文書では、SOAのゾーン消去タイマーの値を署名有効期間の約1/3または 1/4に設定することを推奨する。これにより、使用中の署名が有効期間を 終了する前に、マスターサーバからの転送に問題が発生していることを 通知できるようになる。 また、セカンダリサービスを提供するネームサーバ運用者は、スレーブ サーバとして提供するゾーンにおいて近々に有効期間が終了する署名を 検出するプログラムを開発し、そのような署名を検出した際に適切な対応を 取ることを推奨する。 ゾーン消去パラメータを決定する際に、以下のような内容を考慮しなければ ならない。すなわち、セカンダリゾーンが全て消去される可能性は どの程度か、有効なゾーンをロードさせるためにセカンダリサーバ管理者と やりとりするのに必要な時間はどの程度か等である。これらの考慮点は DNSSECに特有のものではないが、署名有効期間の選択に影響を与えるもの だろう。 Kolkman Expires February 2, 2011 [Page 39] Internet-Draft DNSSEC Operational Practices, Version 2 August 2010 4.4.2. 署名有効期間 [OK: 本セクションは新規追加されており、文書の既筆部分と矛盾が無いか チェックする必要がある] 4.4.2.1. 最大値 署名有効期間の最大値を選択する際にまず考慮することは、再生攻撃 (replay attack)のリスクである。価値が低く、長期に渡って変更されないリソース レコードならば、リスクは最小であるから署名有効期間は数ヶ月でもよいだろう。 数年に渡る署名有効期間を選択することも可能だが、セクション3.2.2における 議論と同様、"再署名を定常的なルーチン化すべきだ"という議論があるだろう。 つまり、ゾーンを定期的に再署名することにすれば、運用者は再署名の運用上 の必要性を忘れずに済むということである。 4.4.2.2. 最小値 署名有効期間の最小値は、運用における設定エラーに対してどの程度の時間で 対応を完了したいかに応じて設定される。つまり、エラーを検知するまでに どの程度の時間がかかるか、また対応にどれだけの時間がかかりそうか ということである。これらの問いに解答することで、運用者の(長い)週末の都合や バックアップメディアにアクセスできるまでの時間などを検討できるだろう。 その結果、最小の署名有効期間として単純に2~3日が示唆される可能性もある。 しかし、上記の議論は、問題発生時にゾーンデータは既に署名されて公開されて いるという状態を想定していることに注意してもらいたい。実際には、ゾーンは 再署名期間で定められた頻度で再署名されるかもしれない。再署名期間とは、 署名ツールがゾーン内容を確認する間隔を与えるもので、有効期限が迫っている 署名、つまり署名の有効期間の残り時間がリフレッシュ期間以内の署名のみを 再署名(リフレッシュ)する。ゾーンデータのタイムリーな再署名を行うために、 再署名期間はリフレッシュ期間より短くなければならない。 再署名処理中に運用上の問題が発生した場合、ゾーンで最初に有効期限が終了する 署名は最も以前に生成されたものである。最悪の場合、これらの署名は有効期限 切れまでに(リフレッシュ期間-再署名期間)しか時間が残されていない。 言い換えると、署名有効期間の最小値は、まずリフレッシュ期間を選択し (通常2~3日)、次に (リフレッシュ期間-再署名期間)で算出される時間で 運用上の大問題を解決できるように再署名時間を定義することで設定される。 Kolkman Expires February 2, 2011 [Page 40] Internet-Draft DNSSEC Operational Practices, Version 2 August 2010 問題をやや複雑にするものとして、幾つかの署名ツールでは、署名有効期間を 小さい範囲(ゆらぎ時間:the jitter interval)でばらつかせ、全ての署名が同時に 有効期限切れにならないようにしている。ゆらぎ時間がリフレッシュ期間より 短く、再署名期間がリフレッシュ期間の半分以上ある限りにおいては、署名有効 期間の最小値の計算には影響しないはずである。[OK: この記述は注意深く検証 する必要がある]。 署名有効期間 署名 署名有効期間 開始時刻   時刻 終了時刻 | | | | | |---------------------|---------------------------|.......|.......| | | | | | +/- ゆらぎ時間 | 開始時刻オフセット | | |<------------------->| 署名有効期間 | |<------------------------------------------------------->| 署名有効期間 署名 署名 署名 署名 再署名  署名有効期間 開始時刻 時刻 再利用 再利用 再利用 実施 終了時刻 | | | | | | | |------------------|-----------------------------------------| | | | | | | | <----> <----> <----> <----> 再署名期間 | | |<-リフレッシュ->| | 期間 | 図において、署名有効期間開始時刻が署名時刻の少し前から始まっているこ とに注意してほしい。これは、やや時刻にずれがあるバリデータを許容する ためである。 4.4.2.3. RRset間における差異 ゾーン内の異なるRRsetへの署名の有効期間をRRsetに応じて変化させることも 可能である。(ダイナミックアップデートを使用する場合のように)ゾーンが 極めて変更の多いデータを含んでいる場合、実際にこの状況が発生することが ある。しかし、データ自身のTTLが依然としてキャッシュデータの消去に関する 最重要パラメータであるから、(同期できていないセカンダリネームサーバによる) 再生攻撃のリスクは、署名有効期間を決定する際に優先すべき事項であることに 注意してもらいたい。[OK: 再生攻撃のリスク以外に署名有効期間に差異を設ける ことへの重要な論点は残っているか] Kolkman Expires February 2, 2011 [Page 41] Internet-Draft DNSSEC Operational Practices, Version 2 August 2010 既存データに対する再生攻撃のリスクが、不在データに対する再生攻撃の リスクとは異なる場合がある。そのような場合、NSEC・NSEC3レコードの 署名有効期間が適宜調整されることになるかもしれない。 ゾーンが"Secure"な委任を含む場合、相対的に短い署名有効期間にしておくことで 子ゾーンの鍵が漏洩した場合に、子ゾーンを再生攻撃から保護することが できる(セクション4.3.4参照)。親ゾーンのレジストリは短い署名有効期間に するほど運用リスクが高まり、子ゾーンは長い署名有効期間にするほど 運用リスクが高まるので、1つのゾーンにおいて、個別のDS RRごとに署名有効 期間に(登録に要する金額も含めて)差異が生じるかもしれない。 署名有効期間の差異に関して、これ以外の議論は存在しないように思われる。 4.4.2.4. その他のタイミングパラメータ [OK: 以下、曖昧すぎないか? これで十分か?] 署名有効期間の最小値の調整に関する議論は、SOAのゾーン消去タイマーの設定に おいて行われた議論と極めて似ている。この値(署名有効期間)をSOAのゾーン消去 タイマーよりも長い値とすることを推奨する(※)。 ※訳注: 最後の文は原文では "このSOAのゾーン消去タイマーを署名有効期間よりも長い値とすることを推奨" となっており、セクション4.4.1の 本文書では、SOAのゾーン消去タイマーの値を署名有効期間の約1/3または 1/4に設定することを推奨する。 という記述と整合しない。文脈的にはゾーン同期に失敗し続けているスレーブが その間に署名の有効期限切れを起こすことを防ごうとしていることから、4.4.1の 記述が正しく、ここは主語を署名有効期間に代えて言い直そうとしたと判断した。 5. 不在証明レコードタイプ DNSSECの設計におけるトレードオフの1つに、DNS検索機能を提供している最中に 暗号化処理を行うことがないように、署名と名前解決を分離したことがある。 このことから、実際に存在する名前の間に位置づけられる膨大な数の 不在名をカバーするレコードを作成する必要がある。 DNSSECには、ドメイン名の不在証明を提供する方式が2つある。1つは平文を 使用するものであり、もう1つは解読困難なデータを使用するものである。 どちらの方式も以下のような特徴を持つ。 ・ ある名前に対して存在する全てのRRタイプの一覧を持ち、それを使用して RRタイプの不在証明を行う。 ・ ゾーンが権威を持つ名前のみを対象とする(つまり、ゾーン内のグルー レコードは対象外となる)。 Kolkman Expires February 2, 2011 [Page 42] Internet-Draft DNSSEC Operational Practices, Version 2 August 2010 ・ ある名前に対して存在するRRタイプの情報を格納するために、専用の RRタイプを使用する。平文を使用する方式はNSEC RRを使用し、解読困難な データを使用する方式はNSEC3 RRを使用する。 5.1. NSECとNSEC3の違い 平文方式(NSEC)は、ゾーンの名前を整列した連結リストを用いて実装される。 解読困難データ方式(NSEC3)もこれに似ているが、初めに名前に対して一方向 ハッシュ関数を適用し、得られた(ハッシュ)文字列を整列した連結リストを 生成する。 NSECレコードは、関連する署名レコードの検証以外には暗号化処理を必要と しない。NSECレコードは人間が判読できるものであり、これを使用して人手 による問合わせを行い、処理が正確に行われているかを判定することができる。 NSECレコードの難点は、"次ドメイン名(Next Domain Name)"フィールドを通じて NSEC RRの連結リストを辿っていくことで、ゾーンの全エントリーを参照可能な "ゾーンウォーキング(zone walking)"ができてしまうことである。 問合わせによってDNSデータにアクセスできることには誰もが合意しているが、 NSECの副作用は問い合わせを順に行うことでゾーンファイルの内容を完全に 列挙することが可能になるという点である。この挙動を許容し、望ましいとさえ する運用者もいるが、他方ではポリシー、規制、その他の理由から望ましくないと する運用者もいる。これがNSECとNSEC3の1つめの違いである。 NSECとNSEC3の2つめの違いは、NSECはゾーンファイルの全RRに対して署名を 要求するので、全ての不在証明が暗号技術で署名されることが保証されること である。しかし、多くの委任を含む大規模なゾーンファイルにおいて非常に少数の 委任先のみが署名ゾーンであるような場合、特に"Insecure"な委任が頻繁に更新 されるような場合に、この仕様は許容しがたい追加オーバーヘッドを発生する (典型例として、少数の登録者のみが"Secure"な委任を行っているようなTLDの 運用者が挙げられる)。NSEC3では、1つ以上の"Insecure"な委任を、2つの "Secure"な委任の間の"Opt-Out"範囲に含めることができる。このようにする ことで、この間に含まれる名前の暗号的な不在証明はできなくなるが、ゾーンの サイズと暗号化処理の複雑さを軽減することができる。 NSEC3レコードは、問合わされたRRのラベルに対してハッシュ方式を使用する。 ゾーンエントリーの推測に要する負荷を高めるために、ハッシュの繰り返し 回数をNSEC3レコードに指定することができる。更にハッシュを変化させる (訳注: これにより推測を更に困難にする)ため、ソルトを指定することもできる。 ただし、NSEC3はゾーン情報の漏洩に関して完全な保護を与えるわけではない ことに注意してもらいたい。 Kolkman Expires February 2, 2011 [Page 43] Internet-Draft DNSSEC Operational Practices, Version 2 August 2010 5.2. 使用すべきはNSECかNSEC3か NSEC3展開の主な動機である"ゾーン列挙の防御"が意味を持つのは、ゾーン情報が 整然と定型化されておらず、簡単には内容が推測できない場合だけである。 in-addr.arpa、ip6.arpa、e164.arpaのように高度に定型化されたゾーンは 一般的なDNSの機能を使用して簡単に内容を列挙できる。またゾーン頂点にしか レコードを持たず、"www"や"mail"のような一般的なRRラベルしか使用していない 場合、NSEC3を用いたとしても、ゾーン情報の推測と、推測の検証は簡単に行える。 このような場合には、署名ツールや検証リゾルバに要求される作業を単純化 するため、NSECを使用することを推奨する。 "簡単に推測不能な"RRラベルを含む大規模なゾーン、例えば、ラベルを得る 際に守秘義務契約に同意しなければならないようなゾーンに対しては、 NSEC3を推奨する。 NSEC3展開の2つめの理由についての考慮点を下記(セクション5.3.4)に記述 する。 5.3. NSEC3のパラメータ NSEC3のハッシュアルゴリズムはDNS名前圧縮されないFQDN形式に対して適用 される。これにより、あるFQDNのRRラベルに対して攻撃者が行った総当たり攻撃の 成果を他の(FQDNの)RRラベルに対して再利用できないことが保証される。これらの エントリーは定義によりそれぞれ一意となるためである。 5.3.1. ハッシュアルゴリズム 執筆時点では、NSEC3のハッシュアルゴリズムは1つしか定義されていない。 NSEC3で使用する新しいハッシュアルゴリズムを定義する際には、移行方式 も定義しなければならない(MUST)という注記が[21]に記述されている。 したがって、本文書ではNSEC3のハッシュアルゴリズムの移行方式については 検討しない。 5.3.2. 繰り返し回数 NSEC3に関する懸念点の1つに、特定のドメイン名がゾーンに存在するか否かを 判断するため、予め計算された辞書による攻撃が行われるかもしれないというもの がある。このような辞書攻撃のコストを引き上げるため、NSEC3仕様では、 繰り返し回数とソルトという2つの仕組みが導入された。 RFC 5155[21]のセクション10.3において、署名の生成および検証ネームサーバ に課すコストと辞書攻撃への適切な防御を提供することのトレードオフに関 する考察が行われている。そこでは、RSAの鍵長に応じた繰り返し回数の有用な 上限値が与えられている。1024ビット鍵では150回、2048ビット鍵では500回、 4096ビット鍵では2500回である。この最大値の2/3の値は十分な負荷を与えられ、 しかも行き過ぎではない選択と考えられる。 Kolkman Expires February 2, 2011 [Page 44] Internet-Draft DNSSEC Operational Practices, Version 2 August 2010 5.3.3. ソルト NSEC3の繰り返し回数はハッシュ辞書作成のコストを高める一方で、NSEC3の ソルトは計算されたハッシュ辞書の寿命を短縮する。ゾーン管理者がソルト値を 変更すると、攻撃者がそのゾーンに対して事前に計算した全ての結果は無効な ものとなる。 FQDNのRRラベルはハッシュされる値の一部であるが、その一意性から、ある RRラベルについて攻撃者が行った総当たり攻撃の成果が他のRRラベル(つまり 他のドメイン)に対して再利用できないことが、すでに保証されている。 ゾーン内の全てのNSEC3レコードのソルト値は同じである必要がある。 ソルトを変更すると全てのNSEC3レコードの再生成が必要となり、したがって これらのNSEC3レコードに対するRRSIGの再生成が必要となる。このため、ソルトの 変更は、ZSKの更新処理と併せて行うことを推奨する。ZSKの更新には全RRSIGの 再生成が必要だからである。差分署名に深刻に依存することなく全ゾーンを少ない 負荷で署名することができる場合にはZSK更新処理にあわせる必要はない。 しかし、ZSKの更新と違い、NSEC3のソルト変更には特別なロールオーバー手続きは 必要ない。ゾーン更新の度にソルトを変更することも可能である。 5.3.4. Opt-Out Opt-Outの仕組みは、大半が委任レコードであるようなゾーンにおいて、署名付き レコードを徐々に増やしていけるようにするため導入されたものである。 Opt-Outフラグを使用すると、NSEC3の意味が、NSEC3がカバーする範囲に特定の 名前が存在しないという不在証明から、NSEC3がカバーする範囲に存在する委任は DNSSEC非対応であるという証明に変更される。[エディタ注:ハッシュ名と ハッシュ名の間隔に言及することで、この概念を更に正確に記述することができる かもしれないが、それはやりすぎだろう]。このフラグを使用すれば、NSEC3 RRの 連鎖の再計算や再署名を行うことなく、NSEC3にカバーされる委任を追加・削除する ことが可能となる。 Opt-Outは委任点に対してのみ指定されるので、数多くのゾーン委任を有するが "Secure"な委任の数は少ないようなゾーンでのみ役立つものである。 この考慮点は、典型的には大規模なトップレベルドメインや類似のゾーンに適用 されるものである。それ以外の状況ではOpt-Outを展開すべきでない。 より詳細な考慮点についてはRFC 5155 [21]のセクション12.2に記載がある。 Kolkman Expires February 2, 2011 [Page 45] Internet-Draft DNSSEC Operational Practices, Version 2 August 2010 6. セキュリティに関する考慮点 DNSSECはDNSにデータの完全性を追加する。本文書は、安定かつ安全な DNSSECサービス運用の維持に関する運用上の考慮点を評価することを試みた ものである。DNSの"データが伝搬する"という特性を考慮しないと、検証の 失敗が発生し、"Secure"なゾーンがDNSSEC対応リゾルバから利用できなくなる かもしれない。 7. IANAに関する考慮点 本文書についてはIANAに関する考慮点は存在しない。 8. Acknowledgments Most of the text of this document is copied from RFC4641 [14]. That document was edited by Olaf Kolkman and Miek Gieben. Other people that contributed or where otherwise involved in that work were in random order: Rip Loomis, Olafur Gudmundsson, Wesley Griffin, Michael Richardson, Scott Rose, Rick van Rein, Tim McGinnis, Gilles Guette Olivier Courtay, Sam Weiler, Jelte Jansen, Niall O'Reilly, Holger Zuleger, Ed Lewis, Hilarie Orman, Marcos Sanz, Peter Koch, Mike StJohns, Emma Bretherick, Adrian Bedford, and Lindy Foster, G. Guette, and O. Courtay. For this version of the document we would like to acknowldge a few people for significant contributions: Paul Hoffman for his contribution on the choice of cryptographic paramenters and addressing some of the trust anchor issues; Jelte Jansen who provided the text in Section 4.1.5; Paul Wouters who provided the initial text for Section 5 and Alex Bligh who improved it; Erik Rescorla's whos blogpost on "the Security of ZSK rollovers" inspired text in Section 3.1; Stephen Morris who made a pass on English style and grammar; Olafur Gudmundsson and Onrej Sury who provided input on Section 4.1.5 based on actual operational experience; The figure in Section 4.4.2 was adapted from the OpenDNSSEC user documentation. In addition valuable contributions in the form of text, comments, or review where provided by Mark Andrews, Patrik Faltstrom, Tony Finch, Alfred Hines, Bill Manning, Scott Rose. [EDITOR NOTE: please let me know if there is an oversight here] 9. References Kolkman Expires February 2, 2011 [Page 46] Internet-Draft DNSSEC Operational Practices, Version 2 August 2010 9.1. Normative References [1] Mockapetris, P., "Domain names - concepts and facilities", STD 13, RFC 1034, November 1987. [2] Mockapetris, P., "Domain names - implementation and specification", STD 13, RFC 1035, November 1987. [3] Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose, "DNS Security Introduction and Requirements", RFC 4033, March 2005. [4] Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose, "Resource Records for the DNS Security Extensions", RFC 4034, March 2005. [5] Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose, "Protocol Modifications for the DNS Security Extensions", RFC 4035, March 2005. 9.2. Informative References [6] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [7] Ohta, M., "Incremental Zone Transfer in DNS", RFC 1995, August 1996. [8] Vixie, P., "A Mechanism for Prompt Notification of Zone Changes (DNS NOTIFY)", RFC 1996, August 1996. [9] Andrews, M., "Negative Caching of DNS Queries (DNS NCACHE)", RFC 2308, March 1998. [10] Wellington, B., "Secure Domain Name System (DNS) Dynamic Update", RFC 3007, November 2000. [11] Hollenbeck, S., "Generic Registry-Registrar Protocol Requirements", RFC 3375, September 2002. [12] Orman, H. and P. Hoffman, "Determining Strengths For Public Keys Used For Exchanging Symmetric Keys", BCP 86, RFC 3766, April 2004. [13] Eastlake, D., Schiller, J., and S. Crocker, "Randomness Requirements for Security", BCP 106, RFC 4086, June 2005. [14] Kolkman, O. and R. Gieben, "DNSSEC Operational Practices", Kolkman Expires February 2, 2011 [Page 47] Internet-Draft DNSSEC Operational Practices, Version 2 August 2010 RFC 4641, September 2006. [15] Shirey, R., "Internet Security Glossary, Version 2", RFC 4949, August 2007. [16] StJohns, M., "Automated Updates of DNS Security (DNSSEC) Trust Anchors", RFC 5011, September 2007. [17] Gould, J. and S. Hollenbeck, "Domain Name System (DNS) Security Extensions Mapping for the Extensible Provisioning Protocol (EPP)", RFC 5910, May 2010. [18] Rose, S., "NIST DNSSEC workshop notes", , June 2001. [19] Barker, E. and J. Kelsey, "Recommendation for Random Number Generation Using Deterministic Random Bit Generators (Revised)", Nist Special Publication 800-90, March 2007. [20] Hardaker, W., "Use of SHA-256 in DNSSEC Delegation Signer (DS) Resource Records (RRs)", RFC 4509, May 2006. [21] Laurie, B., Sisson, G., Arends, R., and D. Blacka, "DNS Security (DNSSEC) Hashed Authenticated Denial of Existence", RFC 5155, March 2008. [22] Dierks, T. and E. Rescorla, "The Transport Layer Security (TLS) Protocol Version 1.2", RFC 5246, August 2008. [23] Jansen, J., "Use of SHA-2 Algorithms with RSA in DNSKEY and RRSIG Resource Records for DNSSEC", RFC 5702, October 2009. [24] Morris, S., Ihren, J., and J. Dickinson, "DNSSEC Key Timing Considerations", draft-ietf-dnsop-dnssec-key-timing-00 (work in progress), July 2010. [25] Ljunggren, F., Eklund-Lowinder, A., and T. Okubo, "DNSSEC Policy & Practice Statement Framework", draft-ietf-dnsop-dnssec-dps-framework-02 (work in progress), July 2010. [26] Larson, M. and O. Gudmundsson, "DNSSEC Trust Anchor Configuration and Maintenance", draft-ietf-dnsop-dnssec-trust-anchor-03 (work in progress), March 2009. Kolkman Expires February 2, 2011 [Page 48] Internet-Draft DNSSEC Operational Practices, Version 2 August 2010 付録A. 専門用語 本文書では、他の文書で定義された幾つかの専門用語を使用している。 ほとんどの場合、その用語を定義する文書の説明を単にコピーするに とどまらず、その意味についてより詳しい説明を提供している。 これらの説明は権威を持つべきものではないことに注意してもらいたい。 アンカー鍵(Anchored Key): 世界中のリゾルバでトラストアンカーとして 設定されているDNSKEY。この鍵を更新することは困難なので、"アンカー" と名付けられた。 Bogus: RFC 4033[3]のセクション5も参照のこと。あるRRsetの署名がDNSKEYで検証 できない場合、そのRRsetはDNSSECでは"Bogus(検証失敗:信頼禁止)"と判定 される。 KSK(Key Signing Key: 鍵署名鍵): KSKはゾーン頂点にある鍵セットに署名する ためだけに使用される鍵である。ある鍵がKSKであるという事実は、 署名ツールにだけ意味がある。 鍵長(Key size): 本文書を通して、"鍵長"という用語は、"公開鍵のモジュラスの サイズ"と言い換えることができる。モジュラスのサイズという方が数学的には より正確だが、本文書はオペレータ向けに書かれているので、鍵長という 用語の方が気軽に感じられる。 秘密鍵と公開鍵(Private and Public Keys): DNSSECは、公開鍵暗号を使用して DNSの安全を確保する。公開鍵暗号は、2つの(数学的に関連した)鍵、すなわち 公開鍵と秘密鍵の存在に基づいている。公開鍵は、DNSKEYリソースレコード (DNSKEY RR)を使用してDNSで公開される。秘密鍵は秘密の状態に保つべき である。 鍵のロールオーバー(Key Rollover): 鍵のロールオーバーは、ある鍵ペアの 鍵有効期間終了時に別の鍵ペアに置き換える処理である。 リフレッシュ期間(Refresh Period): 署名有効期間終了までの間に設定される 時間で、この期間内に署名がリフレッシュ(再署名)される。 再署名頻度(Re-Singing frequency): ゾーンの周期的な署名確認を行う頻度。 "再署名期間"ということもある。署名ツールがいつゾーンを確認するかを 定義する。再署名(署名のリフレッシュ)はリフレッシュ期間に依存するので、 ある署名確認においてゾーンの全署名がリフレッシュされるわけではない。 セキュアエントリーポイントの鍵(SEP鍵)(Secure Entry Point key or SEP Key): 親ゾーンのDSレコードが指し示すKSKまたはトラストアンカーとして設定された KSK。プロトコルでは要求しないが、これらの鍵にはSEPフラグ[5]を設定 することを推奨する。 Kolkman Expires February 2, 2011 [Page 49] Internet-Draft DNSSEC Operational Practices, Version 2 August 2010 自己署名(Self-signature): この概念は、DNSKEYに対する署名にのみ適用される。 DNSKEY xで生成した署名がDNSKEY xを対象とする場合、それを自己署名と呼ぶ。 注: これ以外の情報が無い場合には、自己署名は何ら信頼を示すものでは ないが、DNSKEYの信頼性を検査するには便利である。すなわち、自己署名は ハッシュとして使用することができる。 署名のゆらぎ(Signing Jitter): 署名有効期間に適用するゆらぎ時間 署名ツール(Signer): 秘密鍵情報へのアクセス手段を持ち、ゾーンのRRsetに 署名するシステム。署名ツールがゾーンの一部にだけ、例えば間もなく 有効期間が終了する署名を持つRRsetにだけ署名を行うように設定してもよい。 単一鍵署名方式(Single Type Signing Scheme): ZSKとKSKを区別しない署名方式。 ZSK(ゾーン署名鍵): ゾーン内の全データ(DNSKEY RRsetは除かれるかもしれない) に署名するために使用する鍵。ある鍵がZSKであるという事実は、署名ツールに だけ意味がある。 ゾーンファイルへの署名(Singing the Zone File): ゾーン管理者が軽やかな 音楽パターンを響かせながら、楽しくゾーンに署名をするような場合に この用語が使用される。 ゾーン管理者(Zone Administrator): 権威を持つプライマリサーバにおいて、 ゾーンに署名し、公開する責任を持つ"役割"。 付録B. 表記上の慣例 本文書では、以下の表記上の慣例を使用している。 鍵の表記: 鍵はDNSKEY_x_yと表記される。ここでyは鍵タイプを示すIDである。 KはKSK、ZはZSK、SはKSKとZSKを区別しない場合のSEP鍵を示す。xは番号 またはIDであり、鍵IDと考えることもできる。 RRsetの表記: RRはタイプだけが表記される。他の情報、例えば所有者や クラス、rdata、TTLといった情報は省略される。したがって、 "example.com 3600 IN A 192.0.2.1"は"A"と簡略化される。 RRsetはRRのリストである。例えば"A1, A2"のようなもので、 この例では2つの"A"レコードを含むRRsetを示している。繰り返すが、 これは単に"A"と簡略化されることがある。 Kolkman Expires February 2, 2011 [Page 50] Internet-Draft DNSSEC Operational Practices, Version 2 August 2010 署名の表記: 署名はRRSIG_x_y(RRset)と表記される。これはRRsetが DNSKEY_x_yで署名されていることを意味する。 ゾーンの表現: 上記の表記法を使用し、不必要な詳細情報を省略する、 例えば全てのデータを単に"SOAx"と表記することより、署名ゾーンを 簡略化して表現する。 SOAの表現: SOAはSOAxと表現される。ここでxはシリアル番号である。 無視するRRset: DNSKEY RRset以外の署名がSOAと同じパラメータである場合、 それらのRRsetは記述されない。下記の例では、SOAとfoo.example.comの A RRsetは同じパラメータで署名されているので、後者は簡略化表現では 無視される。 この表記法を以下の署名ゾーンに使用する。 example.com. 3600 IN SOA ns1.example.com. olaf.example.net. ( 2005092303 ; serial 450 ; refresh (7 minutes 30 seconds) 600 ; retry (10 minutes) 345600 ; expire (4 days) 300 ; minimum (5 minutes) ) 3600 RRSIG SOA 5 2 3600 20120824013000 ( 20100424013000 14 example.com. NMafnzmmZ8wevpCOI+/JxqWBzPxrnzPnSXfo ... OMY3rTMA2qorupQXjQ== ) 3600 NS ns1.example.com. 3600 NS ns2.example.com. 3600 NS ns3.example.com. 3600 RRSIG NS 5 2 3600 20120824013000 ( 20100424013000 14 example.com. p0Cj3wzGoPFftFZjj3jeKGK6wGWLwY6mCBEz ... +SqZIoVHpvE7YBeH46wuyF8w4XknA4Oeimc4 zAgaJM/MeG08KpeHhg== ) 3600 TXT "Net::DNS domain" 3600 RRSIG TXT 5 2 3600 20120824013000 ( 20100424013000 14 example.com. o7eP8LISK2TEutFQRvK/+U3wq7t4X+PQaQkp ... BcQ1o99vwn+IS4+J1g== ) 300 NSEC foo.example.com. NS SOA TXT RRSIG NSEC DNSKEY 300 RRSIG NSEC 5 2 300 20120824013000 ( 20100424013000 14 example.com. Kolkman Expires February 2, 2011 [Page 51] Internet-Draft DNSSEC Operational Practices, Version 2 August 2010 JtHm8ta0diCWYGu/TdrE1O1sYSHblN2i/IX+ ... PkXNI/Vgf4t3xZaIyw== ) 3600 DNSKEY 256 3 5 ( AQPaoHW/nC0fj9HuCW3hACSGiP0AkPS3dQFX ... sAuryjQ/HFa5r4mrbhkJ ) ; key id = 14 3600 DNSKEY 257 3 5 ( AQPUiszMMAi36agx/V+7Tw95l8PYmoVjHWvO ... oy88Nh+u2c9HF1tw0naH ) ; key id = 15 3600 RRSIG DNSKEY 5 2 3600 20120824013000 ( 20100424013000 14 example.com. HWj/VEr6p/FiUUiL70QQWtk+NBIlsJ9mdj5U ... QhhmMwV3tIxJk2eDRQ== ) 3600 RRSIG DNSKEY 5 2 3600 20120824013000 ( 20100424013000 15 example.com. P47CUy/xPV8qIEuua4tMKG6ei3LQ8RYv3TwE ... JWL70YiUnUG3m9OL9w== ) foo.example.com. 3600 IN A 192.0.2.2 3600 RRSIG A 5 3 3600 20120824013000 ( 20100424013000 14 example.com. xHr023P79YrSHHMtSL0a1nlfUt4ywn/vWqsO ... JPV/SA4BkoFxIcPrDQ== ) 300 NSEC example.com. A RRSIG NSEC 300 RRSIG NSEC 5 3 300 20120824013000 ( 20100424013000 14 example.com. Aaa4kgKhqY7Lzjq3rlPlFidymOeBEK1T6vUF ... Qe000JyzObxx27pY8A== ) その結果、以下に示すような簡略化した表記となる。 SOA2005092303 RRSIG_Z_14(SOA2005092303) DNSKEY_K_14 DNSKEY_Z_15 RRSIG_K_14(DNSKEY) RRSIG_Z_15(DNSKEY) 残りのゾーンデータは、SOAレコードと同じ署名を持つ。すなわち、DNSKEY 14で 生成されたRRSIGを持つ。 Kolkman Expires February 2, 2011 [Page 52] Internet-Draft DNSSEC Operational Practices, Version 2 August 2010 Appendix C. Document Editing History [To be removed prior to publication as an RFC] C.1. draft-ietf-dnsop-rfc4641-00 Version 0 was differs from RFC4641 in the following ways. o Status of this memo appropriate for I-D o TOC formatting differs. o Whitespaces, linebreaks, and pagebreaks may be slightly different because of xml2rfc generation. o References slightly reordered. o Applied the errata from http://www.rfc-editor.org/errata_search.php?rfc=4641 o Inserted trivial "IANA considertations" section. In other words it should not contain substantive changes in content as intended by the workinggroup for the original RFC4641. C.2. version 0->1 Cryptography details rewritten. (See http://www.nlnetlabs.nl/svn/ rfc4641bis/trunk/open-issues/cryptography_flawed) o Reference to NIST 800-90 added o RSA/SHA256 is being recommended in addition to RSA/SHA1. o Complete rewrite of Section 3.4.2 removing the table and suggesting a keysize of 1024 for keys in use for less than 8 years, issued up to at least 2015. o Replaced the reference to Schneiers' applied cryptograpy with a reference to RFC4949. o Removed the KSK for high level zones consideration Applied some differentiation with respect of the use of a KSK for parent or trust-anchor relation http://www.nlnetlabs.nl/svn/ rfc4641bis/trunk/open-issues/differentiation_trustanchor_parent http://www.nlnetlabs.nl/svn/rfc4641bis/trunk/open-issues/ Kolkman Expires February 2, 2011 [Page 53] Internet-Draft DNSSEC Operational Practices, Version 2 August 2010 rollover_assumptions Added Section 4.1.5 as suggested by Jelte Jansen in http:// www.nlnetlabs.nl/svn/rfc4641bis/trunk/open-issues/Key_algorithm_roll Added Section 4.3.5.1 Issue identified by Antoin Verschuur http:// www.nlnetlabs.nl/svn/rfc4641bis/trunk/open-issues/ non-cooperative-registrars In Appendix A: ZSK does not nescessarily sign the DNSKEY RRset. C.3. version 1->2 o Significant rewrite of Section 3 whereby the argument is made that the timescakes for rollovers are made purely on operational arguments hopefully resolving http://www.nlnetlabs.nl/svn/ rfc4641bis/trunk/open-issues/discussion_of_timescales o Added Section 5 based on http://www.nlnetlabs.nl/svn/rfc4641bis/ trunk/open-issues/NSEC-NSEC3 o Added a reference to draft-morris-dnsop-dnssec-key-timing [24] for the quantitative analysis on keyrolls o Updated Section 4.3.5 to reflect that the problem occurs when changing DNS operators, and not DNS registrars, also added the table indicating the redelegation procedure. Added text about the fact that implementations will dismiss keys that fail to validate at some point. o Updated a number of references. C.4. version 2->3 o Added bulleted list to serve as an introduction on the decision tree in Section 3. o In section Section 3.1: * tried to motivate that keylength is not a strong motivation for KSK ZSK split (based on http://www.educatedguesswork.org/2009/ 10/on_the_security_of_zsk_rollove.html) * Introduced Common Signing Key terminology and made the arguments for the choice of a Common Signing Key more explicit. * Moved the SEP flag considerations to its own paragraph Kolkman Expires February 2, 2011 [Page 54] Internet-Draft DNSSEC Operational Practices, Version 2 August 2010 o In a few places in the document, but section Section 4 in particular the comments from Patrik Faltstrom (On Mar 24, 2010) on the clarity on the roles of the registrant, dns operator, registrar and registry was addressed. o Added some terms based on http://www.nlnetlabs.nl/svn/rfc4641bis/ trunk/open-issues/timing_terminology o Added paragrap 2 and clarified the second but last paragraph of Section 3.2.2. o Clarified the table and some text in Section 4.1.5. Also added some text on what happens when the algorithm rollover also involves a roll from NSEC to NSEC3. o Added a paragraph about rolling KSKs that are also configured as trust-anchors in Section 4.1.2 o Added Section 4.1.4. o Added Section 4.4.2 to address issue "Signature_validity" C.5. version 3->4 o Stephen Morris submitted a large number of language, style and editorial nits. o Section 4.1.5 improved based on comments from Olafur Gudmundsson and Onrej Sury. o Tried to improve consistency of notation in the various rollover figures C.6. Subversion infromation www.nlnetlabs.nl/svn/rfc4641bis/ $Id: draft-ietf-dnsop-rfc4641bis-04-ja.txt,v 1.56 2023/06/13 05:35:43 portal0 Exp $ Kolkman Expires February 2, 2011 [Page 55] Internet-Draft DNSSEC Operational Practices, Version 2 August 2010 Author's Address Olaf M. Kolkman NLnet Labs Kruislaan 419 Amsterdam 1098 VA The Netherlands EMail: olaf@nlnetlabs.nl URI: http://www.nlnetlabs.nl Kolkman Expires February 2, 2011 [Page 56]