Internet Engineering Task Force (IETF) S. Weiler, Ed. RFC: 6840 SPARTA, Inc. 更新(Updates): 4033, 4034, 4035, 5155 D. Blacka, Ed. 分類: 標準化過程(Standards Track) Verisign, Inc. ISSN: 2070-1721 2013年2月 DNSセキュリティ拡張(DNSSEC)の明確化と実装に関する注記 要旨 本文書は、DNSセキュリティ拡張(DNSSEC)に関する一連の文書について、 技術的仕様を明確化した記述をまとめたものである。実装者への情報源で あると同時に、本文書執筆時点におけるDNSSECの正誤表を集積したものと しても機能することを意図している。 本文書は、中心的なDNSSEC文書(RFC 4033, RFC 4034, RFC 4035)に加えて、 NSEC3仕様(RFC 5155)の更新を行う。また、NSEC3及びSHA-2(RFC 4509と RFC 5702)をDNSSEC仕様の中心的な要素として定義する。 Status of This Memo This is an Internet Standards Track document. 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). Further information on Internet Standards is available in 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/rfc6840. Weiler & Blacka Standards Track [Page 1] RFC 6840 DNSSEC Implementation Notes February 2013 Copyright Notice Copyright (c) 2013 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. Weiler & Blacka Standards Track [Page 2] RFC 6840 DNSSEC Implementation Notes February 2013 目次 1. はじめに ........................................................4 1.1. 本文書の構成 ...............................................4 1.2. 用語 .......................................................4 2. DNSSECプロトコルへの重要な仕様追加 ..............................4 2.1. NSEC3のサポート ............................................4 2.2. SHA-2のサポート ............................................5 3. スケーラビリティに関する懸念事項 ................................5 3.1. BADキャッシュの実装 ........................................5 4. セキュリティに関する懸念事項 ....................................5 4.1. 不在証明の明確化 ...........................................5 4.2. タイプANYの問い合わせに対する応答の署名検証 ................6 4.3. CNAMEの検査 ................................................6 4.4. 署名付き委任の検証 .........................................7 5. 相互運用性に関する懸念事項 ......................................7 5.1. 正規化を要するタイプコードリストの誤り .....................7 5.2. 未知のDSメッセージダイジェストアルゴリズム .................7 5.3. プライベートアルゴリズム ...................................8 5.4. ローカルポリシー及び複数のRRSIGに関する注意喚起 ............9 5.5. 鍵タグの計算 ...............................................9 5.6. 応答におけるDOビットの設定 .................................9 5.7. 問い合わせにおけるADビットの設定 ..........................10 5.8. 応答におけるADビットの設定 ................................10 5.9. 問い合わせにおけるCDビットの設定 ..........................10 5.10. ネストされたトラストアンカー .............................11 5.11. 必須のアルゴリズムルール .................................11 5.12. 未知の鍵による余分な署名の無視 ...........................12 6. 軽微な誤り訂正と仕様の明確化 ...................................12 6.1. ゾーンカットの発見 ........................................12 6.2. DNSKEYの使用法の明確化 ....................................12 6.3. 例示における誤り ..........................................13 6.4. RFC 5155における誤り ......................................13 7. セキュリティに関する考慮点 .....................................13 8. References .....................................................14 8.1. Normative References ......................................14 8.2. Informative References ....................................15 Appendix A. Acknowledgments .......................................16 付録B. CDビットの設定に関する議論 .................................16 付録C. トラストアンカーの優先オプションに関する議論 ...............19 C.1. 最近接名(Closest Encloser)ポリシー ........................19 C.2. 全トラストアンカー試行(Accept Any Success)ポリシー ........20 C.3. 出自に基づく優先付け(Preference Based on Source)ポリシー ..20 Weiler & Blacka Standards Track [Page 3] RFC 6840 DNSSEC Implementation Notes February 2013 1. はじめに 本文書は、DNSSEC仕様の中心部分、具体的に、当初[RFC4033]、[RFC4034]、 [RFC4035]で記述され、後に[RFC5155]で修正されたものについて、幾つかの 仕様の追加・明確化・修正等を列挙するものである。(中心的な一連の文書に 追加された仕様についてはセクション2を参照のこと)。 実装者に情報を提供するとともに、本文書執筆時点で確認されている、DNSSEC 文書が標準化過程(Standards Track)で先に進む際に検討が必要な項目を集積 することを意図している。 1.1. 本文書の構成 DNSSEC仕様の明確化及び変更は、その重要度順に並べられている。具体的に、 見落としてしまうとセキュリティ上の問題を生じさせる可能性があるものから 始まり、運用上の影響は軽微と予想されるものへと重要度が順次下がっていく。 1.2. 用語 本文書におけるキーワード"しなければならない(MUST)"、"してはならない (MUST NOT)"、"要求される(REQUIRED)"、"するものとする(SHALL)"、 "しないものとする(SHALL NOT)"、"すべきである(SHOULD)"、 "すべきでない(SHOULD NOT)"、"推奨される(RECOMMENDED)"、 "推奨されない(NOT RECOMMENDED)"、"してもよい/することができる(MAY)"、 "任意である(OPTIONAL)"等は、[RFC2119]の記述どおりに解釈されるものとする。 2. DNSSECプロトコルへの重要な仕様追加 本セクションでは、当初[RFC4033]のセクション10で指定された中心的なDNSSEC プロトコル文書に加えて、現在では同様に中心的と見なされている幾つかの 文書を列挙する。 2.1. NSEC3のサポート [RFC5155]は、ハッシュを使用した不在証明を行うためのNSEC3 RR及び NSEC3PARAM RRの使用法と、その動作について記述している。バリデーター実装は、 NSEC3をサポートに含めることが強く推奨される。多くの著名なゾーンがNSEC3を 使用しているからである。NSEC3を使用した応答の署名検証(validation)を サポートしないバリデーターは、DNS空間の大部分の署名検証に失敗することに なるだろう。 [RFC5155]は、[RFC4033]のセクション10に記載されている "DNSSECの 関連文書" の一部であると現在では見なされている。 Weiler & Blacka Standards Track [Page 4] RFC 6840 DNSSEC Implementation Notes February 2013 ゾーンで使用されるアルゴリズムIDが[RFC5155]定義のもの(DSA-NSEC3-SHA1 及びRSASHA1-NSEC3-SHA1)や[RFC5702]定義のもの(RSASHA256及びRSASHA512) である場合、当該ゾーンがNSECではなくNSEC3を使用している可能性を通知する ことに注意せよ。ゾーンはどちらを使用してもよいので、これらのアルゴリズムを サポートするバリデーターはNSEC3・NSEC両方の応答をサポートしなければ ならない(MUST)。 2.2. SHA-2のサポート [RFC4509]は、DS(Delegation Signer) RRにおいてダイジェストアルゴリズムに SHA-256を使用する方式を記述している。[RFC5702]は、DNSKEY RR及びRRSIG RRで RSASHA256及びRSASHA512を使用する方式を記述している。バリデーター実装は、 DS、DNSKEY、RRSIG RRにおいて、これらのアルゴリズムをサポートに含めることが 強く推奨される。 [RFC4509]及び[RFC5702]は、ともに[RFC4033]のセクション10に記載されて いる "DNSSECの関連文書"の一部であると現在では見なされている。 3. スケーラビリティに関する懸念事項 3.1. BADキャッシュの実装 [RFC4035]のセクション4.7において、DNSSEC対応リゾルバーがBADキャッシュ (検証失敗キャッシュ)を実装することを許可している。この指示を次のように 変更する。DNSSEC対応リゾルバーは、[RFC4035]の記載に従うBADキャッシュを 実装すべき(SHOULD)である。 この指示の変更は、管理上の誤りはDNSトラフィックの著しい増大を引き起こす という運用上の経験と、それに付随した、そのようなイベントは当初想定されて いたよりも発生する可能性が高くまた有害であるとの理解に基づくものである。 そのようなイベントの例が "DNSSEC鍵のロールオーバー(Rolling Over DNSSEC Keys)" [Huston]で文書化されている。 4. セキュリティに関する懸念事項 本セクションは、見落とした場合にセキュリティ上の問題を生じさせる可能性が ある事柄を明確化する。 4.1. 不在証明の明確化 [RFC4035]のセクション5.4記載の不在証明検査アルゴリズムはあいまいである。 具体的に、記述されたアルゴリズムでは、先祖(訳注: 親、親の親等)ゾーン側の NSECまたはNSEC3 RRが子ゾーンのRRの不在を証明しているとバリデーターが 解釈できてしまう可能性がある。 "先祖側の委任(ancestor delegation)"のNSEC RR(またはNSEC3 RR)とは、 以下の条件を満たすものである。 ・ NSビットが設定されている。 ・ SOA(Start of Authority)ビットが設定されていない。 Weiler & Blacka Standards Track [Page 5] RFC 6840 DNSSEC Implementation Notes February 2013 ・ 対応するRRSIG RRの署名者名フィールドがNSEC RRの所有者名または NSEC3 RRのオリジナル所有者名よりも短い。 ゾーンカット子側のいかなるRRに対しても、その不在を想定するために先祖側の 委任のNSEC RRまたはNSEC3 RRが使用されてはならない(MUST NOT)。具体的に、 委任元の(オリジナル)所有者名においては、DS RRを除く全RRが対象であり、 当該所有者名よりも下位においては、タイプに関わらず全RRがその対象となる。 同様に、先のアルゴリズムはDNAME RRと同じ所有者名を持つNSEC RRまたは DNAME RRと同じオリジナル所有者名を持つNSEC3 RRによって、DNAMEより下位に ある名前の不在証明ができてしまう。DNAMEビットが設定されたNSEC RRまたは NSEC3 RRが存在する場合、当該NSEC/NSEC3 RRの(オリジナル)所有者名のあらゆる サブドメインにおいて、不在を想定するために当該NSEC/NSEC3 RRが使用されては ならない(MUST NOT)。 4.2. タイプANYの問い合わせに対する応答の署名検証 [RFC4035]には、QTYPE=*の場合にどのように応答を署名検証するかの記述がない。 [RFC1035]のセクション6.2.2に記述されているように、QTYPE=*に対する適切な 応答は、問い合わせ名のサブセットを含んでいてもよい。つまり、QNAMEを所有者名 とする全RRsetを応答する必要はない。 QTYPE=*の応答を署名検証する場合、受信した応答に含まれる、QNAMEとQCLASSに 一致する全RRsetを署名検証しなければならない(MUST)。どれか一つでも署名検証に 失敗した場合、その応答は"Bogus(検証失敗:信頼禁止)"と見なされる。 QNAMEとQCLASSに一致するRRsetが存在しない場合、[RFC4035]のセクション5.4に 記載されたルールに(本文書で明確化された事項も含めて)従い、一致するRRsetが 存在しなかったという事実が署名検証されなければならない(MUST)。明確化の ために記述すると、バリデーターはQTYPE=*の応答において、QNAMEを所有者名と する全レコードの受信を期待してはならない。 4.3. CNAMEの検査 [RFC4035]のセクション5は、CNAMEに基づく(または基づくべき)応答の署名検証 に関して何も記述していない。NOERROR/NODATA応答を署名検証する場合、 バリデーターは、QNAMEに一致するNSEC RRまたはNSEC3 RRのタイプビットマップ において、問い合わされたタイプのビットに加えて、CNAMEビットも検査しなければ ならない(MUST)。 この検査をしない場合、攻撃者は、CNAMEの存在を示す応答に対して、(例えば) 単純にCNAME RRsetを応答から取り除くことで、NOERROR/NODATA応答に変換 できてしまう可能性がある。すると、思慮の浅いバリデーターは、一致する NSEC/NSEC3 RRにQTYPEが存在しないことには気づくが、CNAMEビットが設定 されている、つまりこの応答はCNAMEの存在を示す応答であるべきだったことに 気づかないかもしれない。 Weiler & Blacka Standards Track [Page 6] RFC 6840 DNSSEC Implementation Notes February 2013 4.4. 署名付き委任の検証 [RFC4035]のセクション5.2において、委任が"Secure(検証成功:信頼度高)" ではないことをバリデーターが証明する際に、NSEC(またはNSEC3)のタイプ ビットマップにDSビットとSOAビットが設定されていない事を検査する必要が あると規定している。同様に、バリデーターは、一致するNSEC(またはNSEC3) RRに (委任が実際に存在することを証明する)NSビットが存在するかも検査しなければ ならない(MUST)。あるいは、委任がOpt-Outフラグの設定されたNSEC3 RRで カバーされていることを確認しなければならない(MUST)。 この検査を行わない場合、攻撃者は、委任をしていない(non-delegation)名前に 一致するNSEC RRまたはNSEC3 RRを再利用して、その名前における未署名委任を 偽造できてしまう可能性がある。その場合、現存する署名RRset(または署名RRsetの 集合)は未署名委任の下位に位置しているので、未署名であり更なる攻撃に対して 脆弱であると主張できるだろう。 5. 相互運用性に関する懸念事項 5.1. 正規化を要するタイプコードリストの誤り DNS名を(順序づけ・署名のどちらにおいても)正規化する場合、NSEC RRの RDATA部に保存されるDNS名は小文字に変換されない。RRSIG RRのRDATA部に 保存されるDNS名は小文字に変換される。 上の段落の指示は公開されてきたものとは異なるが、現時点における標準的な 取組とは整合する。[RFC4034]のセクション6.2項番3は、どちらのRRタイプに 保存される名前も小文字に変換されるべきであると記述している。それ以前に 公開された[RFC3755]は、変換すべきでないと記述している。現行の実装は、 どちらの文書にも完全には従っていない。 [RFC4034]のセクション6.2は、小文字への変換が必要なレコードとしてHINFOを 誤って列挙している上、同レコードが2回現れている。HINFOレコードは ドメイン名を含まないので、小文字に変換する処理の対象ではない。 5.2. 未知のDSメッセージダイジェストアルゴリズム [RFC4035]のセクション5.2には、委任が署名されているが、委任先ゾーンの DS RRsetが提示する公開鍵アルゴリズムを全くサポートしていない場合に、 当該委任をどう扱うかに関するルールが含まれる。しかし、未サポートの メッセージダイジェストアルゴリズムを使用するDSレコードをどう扱うかに ついては明確な記述がない。手短にまとめると、未知または未サポートの メッセージダイジェストアルゴリズムを使用するDSレコードは、未知または 未サポートのアルゴリズムを提示するDNSKEY RRを参照するDSレコードと 同じ方法で処理されなければならない(MUST)。 Weiler & Blacka Standards Track [Page 7] RFC 6840 DNSSEC Implementation Notes February 2013 [RFC4035]は以下のように記述している。 バリデーターが認証済みのDS RRsetに列挙されたアルゴリズムをどれも サポートしていない場合、リゾルバーは親から子に至るサポートされた 認証パスを持たない。このような場合、リゾルバーは、先に説明したような DS RRsetの不在証明をするNSEC RRsetを認証した場合と同様に処理すべき である。 言い換えると、ゾーンのセキュリティ状況を判定する場合、バリデーターは、 未知または未サポートのアルゴリズムを提示する認証済みDSレコードは どのようなものであれ無視する。その結果何も残らなければ、当該ゾーンは 未署名であった場合のように扱われる。 本文書は、更に未知または未サポートのメッセージダイジェストアルゴリズムを 使用する認証済みDSレコードも無視するように上記の記述を修正する。 5.3. プライベートアルゴリズム 先に議論したように、[RFC4035]のセクション5.2では、バリデーターがゾーンの DSレコードで提示された公開鍵アルゴリズムに基づいてゾーンのセキュリティ 状況を判断するように要求している。しかし、[RFC4034]の付録A.1.1記載の プライベートアルゴリズムを使用する場合、DS RRの8ビットのアルゴリズム フィールドは、実際に使用されているアルゴリズムが何であるかを確定する ものではない。 DS RRsetに提示されるアルゴリズム内にプライベートアルゴリズムが存在 しない場合、あるいは提示されるアルゴリズム内にサポートするアルゴリズムが 何か存在している場合、特別な処理は何も必要とされない。 更に、バリデーター実装がプライベートアルゴリズムを全くサポートしない 場合、またはDS RRsetに提示される中に存在しないアルゴリズム番号を使用する プライベートアルゴリズムしかサポートしていない場合、同様に特別な処理は 何も必要とされない。 それ以外の場合、ゾーンのセキュリティ状態は、使用中のプライベートアルゴリズム の内どれか一つでもリゾルバーがサポートしているかどうかに依存する。(ただし、 本文書のセクション5.2で議論したように、ゾーンのDSレコードがリゾルバーの サポートするメッセージダイジェストアルゴリズムを使用していることが条件 である)。このような場合、リゾルバーは、プライベートアルゴリズムを使用する DSごとに対応するDNSKEYを取得し、使用中のアルゴリズムを判定するために公開鍵 フィールドを検査しなければならない(MUST)。DNSSEC対応リゾルバーは、[RFC4035] のセクション5.2に記述されたDNSKEYの認証のように、DNSKEY RRの所有者名と RDATAを連結させたもののハッシュ値がDS RRのダイジェストフィールド値と一致 することを確認しなければならない(MUST)。取得・認証を終えたすべてのDNSKEY RRが 未知または未サポートのプライベートアルゴリズムを使用している場合、 当該ゾーンは未署名であった場合のように扱われる。 Weiler & Blacka Standards Track [Page 8] RFC 6840 DNSSEC Implementation Notes February 2013 プライベートアルゴリズムを使用するDS RRが、どれも先に述べた手順に従った 検査でDNSKEYに一致せず、当該ゾーンが"Secure"であると主張するDSが他に存在 しない場合、[RFC4035]の議論に従い、参照は"Bogus"と見なすべきである。 この明確化は、[RFC4955]で提言されるプライベートアルゴリズムの広範な使用を 促進する。 5.4. ローカルポリシー及び複数のRRSIGに関する注意喚起 複数のRRSIGが任意のRRsetをカバーする場合に関して、[RFC4035]のセクション 5.3.3は、"リゾルバーがこれらのRRSIG RRを検査しなければならないか、また 複数のRRSIG RRが異なる結果を示した場合、その衝突をどのように解決するか については、ローカルリゾルバーのセキュリティポリシーが決定する"と提言 している。 本文書は、次のように規定する。リゾルバーは、RRSIGが有効ならばどれでも 充分なものとして受理し、すべてのRRSIGのバリデーションが失敗した場合に限り RRSIGがカバーするRRsetを"Bogus"と判定すべき(SHOULD)である。 リゾルバーがより制限の強いポリシーを採用している場合、適切に署名された データであっても、キャッシュのタイミングに関する問題のために、不必要に バリデーションに失敗するかもしれない恐れがある。更に、[RFC6781]の セクション4.2.1.2記載の"二重署名法によるZSKロールオーバー"のような特定の ゾーン管理手法は確実な動作をしなくなる。また、そのようなリゾルバーは、 悪意を持ってでたらめな署名を挿入する攻撃に対しても脆弱になる。 5.5. 鍵タグの計算 [RFC4034]の付録B.1において、アルゴリズム1の鍵タグフィールドの計算を 誤って定義している。鍵タグは、公開鍵のモジュラスの下位24ビットの内 上位16ビットであるという記述は正確である。しかし、[RFC4034]は続けて誤った 記述をしており、これは公開鍵モジュラスのオクテット列の最後から4番目と 最後から3番目であるとしている。これは、正しくは最後から3番目と最後から 2番目のオクテットである。 5.6. 応答におけるDOビットの設定 [RFC3225]のセクション3記載の通り、問い合わせのDNSSEC OK(DO)ビットは応答に コピーされなければならない(MUST)。しかし、送信時にこのルールを無視する実装 との相互運用を行うためには、リゾルバーは応答に設定されたDOビットを無視 しなければならない(MUST)。 Weiler & Blacka Standards Track [Page 9] RFC 6840 DNSSEC Implementation Notes February 2013 5.7. 問い合わせにおけるADビットの設定 問い合わせにおけるAD(Authentic Data)ビットの意味は、これまで未定義で あった。[RFC4035]のセクション4.6は、リゾルバーに対し、問い合わせを作成する 際にはADビットを常にクリアするよう指示していた。 本文書は、問い合わせにおけるADビットの設定を、問い合わせ発行者がADビットを 理解し、応答に含まれるADビットの値に興味を持っていることを示す通知として 定義する。これにより、問い合わせ発行者は、DOビットを設定してDNSSECデータを 要求しなくても、ADビットを理解することを示せるようになる。 5.8. 応答におけるADビットの設定 [RFC4035]のセクション3.2.3は、署名を検証するリゾルバーが応答に含まれる ADビットを設定またはクリアすべき条件を記述している。ADビットを理解する ことも無視することもできない旧来のスタブリゾルバーや中継機器との相互運用を するために、署名を検証するリゾルバーは、[RFC4035]のセクション3.2.3に 列挙される条件を満たしており、かつ問い合わせにDOビットかADビットのどちらかが 設定されている場合に限り、ADビットを設定すべき(SHOULD)である。 5.9. 問い合わせにおけるCDビットの設定 CD(Checking Disabled)ビットが設定された問い合わせを処理する場合、 リゾルバーは、たとえDNSSECバリデーションに失敗したデータがあったと しても、応答データをすべて返そうと試みるべき(SHOULD)である。 [RFC4035]のセクション3.2.2は、CDビットが設定された問い合わせを処理する リゾルバーに対し、上流への問い合わせ時にCDビットを設定するように要求 している。 本文書は、更に次のように規定する。署名を検証するリゾルバーは、あらゆる 上流への問い合わせ時にCDビットを設定すべき(SHOULD)である。これは、 リゾルバーが受理した問い合わせにCDビットが設定されていたか、あるいは リゾルバーがQNAMEまたは上位の名前のトラストアンカーを保持しているかを 問わない。 [RFC4035]の記述は、CDビットが設定されていないキャッシュからの応答を取得 した場合の振る舞いがあいまいだが、このような状況は、上流への問い合わせすべてに CDビットを設定するという、先に記述した振る舞いはしないとリゾルバーが選択した 場合にしか発生しない。典型的な場合、新たな問い合わせは要求されず、また キャッシュも元になった問い合わせを行った際にCDビットを設定したかを追跡する 必要はない。しかし、キャッシュされた応答が"Server Failure"(RCODE 2)の 場合は問題が生じる。これは、上流に位置する署名を検証するリゾルバーに おいて、問い合わされたデータのDNSSECバリデーションに失敗した可能性がある ことを示している。([RFC2308]は、"Server Failure"の情報を最大5分間 キャッシュすることを許容している)。このような場合、CDビットを設定した 新たな問い合わせが必要となる。 付録Bで、本セクションで提示した推奨の背後にある理論をより詳しく議論する。 Weiler & Blacka Standards Track [Page 10] RFC 6840 DNSSEC Implementation Notes February 2013 5.10. ネストされたトラストアンカー DNSバリデーターは、ある応答に関して、応答ゾーンへの信頼の連鎖を署名検証 するために使用可能なトラストアンカーを複数設定で保持している場合がある。 例として、バリデーターが"example."及び"zone.example."のトラストアンカー を設定で保持している場合を考える。バリデーターが"www.sub.zone.example."に 対する応答の署名検証を依頼された場合、どちらのトラストアンカーも適用 できる。 このような状況において、どちらのトラストアンカーを使用するかはDNSSEC バリデーターに選択権がある。どちらを使用するかは、実装の選択の問題 である。付録Cにおいて、幾つかの選択可能なアルゴリズムを議論する。 選択ポリシーを設定オプションとして提示することは可能であり、そのように することが望ましい。デフォルトとして、バリデーターは、付録C.2に記述される "全トラストアンカー試行(Accept Any Success)"ポリシーを実装し、他の ポリシーは設定オプションとして提示することを提言する。 "全トラストアンカー試行"ポリシーは、署名検証結果が"Secure"となる (その場合最終的な署名検証結果も"Secure"となる)まで、適用可能なトラスト アンカーをすべて試みるというポリシーである。適用可能なトラストアンカーが すべて"Insecure(未署名状況検出:信頼度低)"という結果に終わった場合に限り、 最終的な署名検証結果も"Insecure"となる。複数のトラストアンカーが"Bogus" という結果となり、"Secure"の結果を得られるものが無かった場合、最終的な 署名検証結果は"Bogus"となる。 5.11. 必須のアルゴリズムルール [RFC4035]のセクション2.2の最終段落は、ゾーンに署名するためにどのアルゴ リズムを使用しなければならないかを記述するルールを含んでいる。これらの ルールは紛らわしいものであったので、異なる言い回しを使用して説明し直す ことにする。 DS RRsetとDNSKEY RRsetは、どのアルゴリズムでゾーンに署名したかを 通知するために使用される。あるアルゴリズムがゾーンのDS RRsetまたは DNSKEY RRsetのどちらかに存在する場合、ゾーン全体に署名するために そのアルゴリズムが使用されたことを通知する。 署名ゾーンは、ゾーンのDS RRset及びゾーンで想定されるトラストアンカー で提示される各アルゴリズムに対するDNSKEYを保持していなければならない (MUST)。また、ゾーンはDNSKEY RRsetで提示される各アルゴリズム(各署名鍵 ではない)で署名されていなければならない(MUST)。DSレコードに存在しない アルゴリズムをDNSKEYに追加することはできるが、その逆はできない。 DNSKEY RRsetの中に同じアルゴリズムの鍵が複数存在する場合、各RRsetへの 署名には、複数のDNSKEYのうちどのサブセットであっても充分である。 各RRsetに署名する際に各アルゴリズムのDNSKEYのうち少なくとも一つが 使用されている限り、あるRRsetに対して複数DNSKEYのサブセット(または 単一のDNSKEY)で署名をし、他のRRsetには別のサブセットで署名することも できる。 Weiler & Blacka Standards Track [Page 11] RFC 6840 DNSSEC Implementation Notes February 2013 同じように、同じアルゴリズムの複数の鍵を提示する複数のDSレコードが 存在する場合、DNSKEY RRsetの中で提示されるものはどのサブセット であってもよい。 この要件が適用される対象はサーバーであり、バリデーターではない。 バリデーターは、有効な単一のパスをどれであれ受理すべき(SHOULD)である。 しかし、DS RRsetに通知されたすべてのアルゴリズムが機能すると主張すべき ではなく(SHOULD NOT)、DNSKEY RRsetに通知されたすべてのアルゴリズムが機能 すると主張してはならない(MUST NOT)。バリデーターは、トラブル シューティングをサポートするために、署名の完全性テストを実行する 設定オプションを保持してもよい(MAY)。 5.12. 未知の鍵による余分な署名の無視 署名を検証するリゾルバーは、ゾーン内に対応するDNSKEYを(現在は)持たない RRSIGを無視しなければならない(MUST)。同様に、署名を検証するリゾルバーは、 DNSKEY RRsetに提示される中に存在しないアルゴリズムタイプを持つRRSIGを 無視しなければならない(MUST)。 RFC 6781及びその後継文書に記述され、また本文書の先のセクション記載の ルールで提言されたような良好な鍵のロールオーバー及びアルゴリズムの ロールオーバーの実践は、そのようなRRSIGをゾーン内に存在させることを要求 する場合がある。 6. 軽微な誤り訂正と仕様の明確化 6.1. ゾーンカットの発見 [RFC4035]の付録C.8で、親ゾーンのサーバーにDSの問い合わせを送信することを 議論しているが、親ゾーンのサーバーをどのように発見するかに関する記述が ない。これに関する固有の指示は、[RFC4035]のセクション4.2で得られる。 6.2. DNSKEYの使用法の明確化 ゾーンの異なるサブセットに対して異なるDNSKEYを使用することは可能であり、 制約するものはセクション5.11記載のルールだけである。ゾーン内にある 各RRsetに対してそれぞれ異なるDNSKEYを使用することすら可能である。先の ルールに加えて、DNSKEY RRsetサイズという実際的な制限を受けるだけである。 しかし、リゾルバーに対して特定のDNSKEYを使用するという意図を通知する 方法はないことに注意せよ。ゾーン内の署名付きDNSKEY RRsetに含まれる どのDNSKEYであっても、ゾーン内の任意のRRsetを認証するために使用できる。 例えば、NSEC RRsetまたは動的に更新される全レコードを認証するため、 弱いまたは信頼性の低いDNSKEYを使用中の場合に、ゾーンの他のRRsetに 署名するために同じDNSKEYを使用することができる。 更に、SEPビットの設定はDNSKEYをどのように使用するかについて何ら影響を 及ぼさないことに注意せよ。[RFC4034]のセクション2.1.2において、署名検証 処理はこのビットの使用を明確に禁止されている。 Weiler & Blacka Standards Track [Page 12] RFC 6840 DNSSEC Implementation Notes February 2013 ゾーンへの唯一のセキュアエントリーポイントとしてSEPビットを設定しない DNSKEYを使用し、ゾーン内の(DNSKEY RRsetを除く)全RRsetへの署名にSEP ビットを設定したDNSKEYを使用することも可能である。また、DNSKEY RRset 自身を含むゾーン全体に署名するために、SEPビットの有無によらず、単一の DNSKEYを使用することもできる。 6.3. 例示における誤り [RFC4035]の付録C.1の文章は、例として付録B.1の"x.w.example.com"を参照 しているが、実際にB.1で使用されているのは"x.w.example" である。 これは、第2段落で"RRSIGのラベルフィールド値3は、回答がワイルドカード 展開を経ずに得られた結果であることを示している。"とはっきり書かれている ことからも明らかである。この記述は"x.w.example"に対しては正しいが、 "x.w.example.com"に対しては誤りである。後者の場合、ラベル数は勿論4に なる(反対に、ラベル数が3であれば、回答がワイルドカード展開の結果である ことを意味する)。 [RFC4035]の付録C.6の第1段落にも軽微な誤りが存在する。"a.z.w.w.example" への参照は、前の行にあるように "a.z.w.example"となるべきである。 6.4. RFC 5155における誤り Empty Non-Terminalに一致するNSECレコードは、事実上どのタイプにも関連 付けられない。このNSEC3レコードが保持するタイプビットマップは空になる。 [RFC5155]のセクション3.2.1は以下の記述を含んでいる。 タイプを持たないブロックは(タイプビットマップフィールドに) 含まれてはならない(MUST NOT)。 しかし、同セクションは以下の正規表現の記述も含んでいる。 タイプビットマップフィールド = ( ウインドウブロック番号 | ビットマップ長 | ビットマップ )+ 正規表現において、プラス("+")記号は、プラス記号の前に一つ以上の要素が 存在することを表現する。これは、最低でも一つはウインドウブロックが存在 しなければならないことを意味する。このウインドウブロックがタイプを 持たない場合、先の記述と矛盾する。従って、[RFC5155]のセクション 3.2.1の正しい文章は次のようになるべきである。 タイプビットマップフィールド = ( ウインドウブロック番号 | ビットマップ長 | ビットマップ )* 7. セキュリティに関する考慮点 本文書は、DNSSECプロトコルの中心部分に、SHA-2とNSEC3のサポートを追加 している。これらの機能を追加することに対するセキュリティに関する考慮点は、 これらを定義する文書の中で議論されている。これに加えて、本文書は、 中心的なDNSSEC文書における幾つかのあいまいな記述や記述漏れのうち、 実装者が理解し、対応しないとセキュリティ上の障害を生じさせる可能性が あるものに対処した。 Weiler & Blacka Standards Track [Page 13] RFC 6840 DNSSEC Implementation Notes February 2013 特に、セクション4記載のバリデーションアルゴリズムの明確化は、DNSSECが 提供するセキュリティ機能を維持するために極めて重要である。更に、 セクション5記載の相互運用に関する懸念事項の対処に失敗すると、新しい アルゴリズムを追加するといった今後のDNSSECの変更または拡張を制限する ことにもなりかねない。 セクション5.9記載のCDビットを常に設定すべきという推奨には、セキュリティの 含意が存在する。CDビットを設定することにより、リゾルバーは、より厳格な バリデーションルールや、上流バリデーターが保持する豊富なトラストアンカーの 恩恵を得られなくなる。 8. References 8.1. Normative References [RFC1034] Mockapetris, P., "Domain names - concepts and facilities", STD 13, RFC 1034, November 1987. [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC3225] Conrad, D., "Indicating Resolver Support of DNSSEC", RFC 3225, December 2001. [RFC4033] Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose, "DNS Security Introduction and Requirements", RFC 4033, March 2005. [RFC4034] Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose, "Resource Records for the DNS Security Extensions", RFC 4034, March 2005. [RFC4035] Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose, "Protocol Modifications for the DNS Security Extensions", RFC 4035, March 2005. [RFC4509] Hardaker, W., "Use of SHA-256 in DNSSEC Delegation Signer (DS) Resource Records (RRs)", RFC 4509, May 2006. [RFC5155] Laurie, B., Sisson, G., Arends, R., and D. Blacka, "DNS Security (DNSSEC) Hashed Authenticated Denial of Existence", RFC 5155, March 2008. [RFC5702] Jansen, J., "Use of SHA-2 Algorithms with RSA in DNSKEY and RRSIG Resource Records for DNSSEC", RFC 5702, October 2009. Weiler & Blacka Standards Track [Page 14] RFC 6840 DNSSEC Implementation Notes February 2013 8.2. Informative References [Huston] Michaelson, G., Wallstrom, P., Arends, R., and G. Huston, "Rolling Over DNSSEC Keys", Internet Protocol Journal, Vol. 13, No.1, pp. 2-16, March 2010. [RFC2308] Andrews, M., "Negative Caching of DNS Queries (DNS NCACHE)", RFC 2308, March 1998. [RFC3755] Weiler, S., "Legacy Resolver Compatibility for Delegation Signer (DS)", RFC 3755, May 2004. [RFC4955] Blacka, D., "DNS Security (DNSSEC) Experiments", RFC 4955, July 2007. [RFC5011] StJohns, M., "Automated Updates of DNS Security (DNSSEC) Trust Anchors", STD 74, RFC 5011, September 2007. [RFC5074] Weiler, S., "DNSSEC Lookaside Validation (DLV)", RFC 5074, November 2007. [RFC6781] Kolkman, O., Mekking, W., and R. Gieben, "DNSSEC Operational Practices, Version 2", RFC 6781, December 2012. Weiler & Blacka Standards Track [Page 15] RFC 6840 DNSSEC Implementation Notes February 2013 Appendix A. Acknowledgments The editors would like the thank Rob Austein for his previous work as an editor of this document. The editors are extremely grateful to those who, in addition to finding errors and omissions in the DNSSEC document set, have provided text suitable for inclusion in this document. The lack of specificity about handling private algorithms, as described in Section 5.3, and the lack of specificity in handling ANY queries, as described in Section 4.2, were discovered by David Blacka. The error in algorithm 1 key tag calculation, as described in Section 5.5, was found by Abhijit Hayatnagarkar. Donald Eastlake contributed text for Section 5.5. The bug relating to delegation NSEC RR's in Section 4.1 was found by Roy Badami. Roy Arends found the related problem with DNAME. The errors in the [RFC4035] examples were found by Roy Arends, who also contributed text for Section 6.3 of this document. Text on the mandatory algorithm rules was derived from suggestions by Matthijs Mekking and Ed Lewis. The CD bit logic was analyzed in depth by David Blacka, Olafur Gudmundsson, Mike St. Johns, and Andrew Sullivan. The editors would like to thank Alfred Hoenes, Ed Lewis, Danny Mayer, Olafur Gudmundsson, Suzanne Woolf, Rickard Bellgrim, Mike St. Johns, Mark Andrews, Wouter Wijngaards, Matthijs Mekking, Andrew Sullivan, Jeremy Reed, Paul Hoffman, Mohan Parthasarathy, Florian Weimer, Warren Kumari and Scott Rose for their contributions to this document. 付録B. CDビットの設定に関する議論 [RFC4035]は、あるゾーンに関して、スタブリゾルバーと権威サーバーの間に 署名検証システムは多くとも1台しか存在しないという暗黙の了解に依存して いるように読み取れる。しかし、スタブリゾルバーと権威サーバーの間に2台以上 のバリデーターが存在することは充分に可能である。これらの異なる バリデーターが、互いに重ならない領域をカバーするトラストアンカーを 設定で保持する場合、各バリデーターはDNSツリーの一部を署名検証することは できるが、どれもDNSツリー全体を署名検証できないということが生じ得る。 Weiler & Blacka Standards Track [Page 16] RFC 6840 DNSSEC Implementation Notes February 2013 従って、上流への問い合わせではCDビットを設定しない方が望ましいのでは ないかという異論もあるかもしれない。そうする事でバリデーションの最大化 が可能となるからである。 本文書のセクション5.9において、たとえ受理した問い合わせがCD=0であっても、 上流への問い合わせにCDビットを設定するよう推奨している。これには次に示す 二つの理由がある。一つは、ただ一つのバリデーターだけが常にバリデーションを 実行するので、より予測可能なバリデーション経験を促進すること、もう一つは、 CD=1の問い合わせの到着によって、その問い合わせに関連する全DNSSECデータを ローカルキャッシュから入手可能かもしれないことを保証することである。 ポリシーの問題として、セクション5.9で提案したものと異なる形でCDビットを 設定することも可能である。もちろん、別の選択をすると、先に列挙した便益を 常に得られるとは限らない。考えられ得るすべてのポリシーに関する賛否両論を 概説することは、本文書の対象範囲を超える話題である。それでもなお、三つの アプローチと、その根底にある運用哲学について記述することは可能だろう。 三つのアプローチは以下の表に並べて提示されている。 各モデルを記述する表は5列で構成される。第1列は、(反復リゾルバーのネーム サーバーサイドで、あるいはスタブリゾルバーの場合はローカルポリシーやAPI から)リゾルバーが受信するCDビットの値を示している。第2列は、問い合わせが 名前解決のために転送を必要とするか(F)、ローカルキャッシュだけで充足可能 か(C)を示している。第3列は行番号で、これによって表の中でを後からこの行を 参照できるようになっている。第4列は、リゾルバーにおけるあらゆる関連条件を 示している。例えば、リゾルバーは問い合わせ名をカバーするトラストアンカーを 保持しているかどうか等である。パラメーターが何もない場合、この列は 空欄になる。第5列と最終列は、リゾルバーの動作を示している。 表は、"データのキャッシュ"と"RCODE=2のキャッシュ"の扱いを区別 している。簡単に言えば、重要な点はRCODE=2(Server Failure)は特別なものと して処理する必要がある、なぜなら上流のどこかで起きたバリデーションの 失敗を示すものかもしれないからだ、ということである。"RCODE=2のキャッシュ" と"それ以外すべてのキャッシュ"の間には確かな違いが存在する。 表は、スタブリゾルバーが中間リゾルバーに問い合わせを送信した際に何が 起きるかを記述する観点から考えるのが恐らく最も簡単だろう。しかし、 表は完璧なまでに一般的なものであり、あらゆる署名を検証するリゾルバーに 適用可能である。 モデル 1: "CDビットを常に設定(always set)" このモデルは、署名を検証するリゾルバーが、問い合わせをカバーするトラスト アンカーを保持しているかに拘わらず問い合わせにCDビットを設定するので このように名付けられた。 Weiler & Blacka Standards Track [Page 17] RFC 6840 DNSSEC Implementation Notes February 2013 この表によって表現される一般的な運用哲学は、ただ一つのリゾルバーだけが バリデーションの責任を担うべきであり、処理中のQNAMEとは異なる、あるいは 付加的なQNAMEをカバーするトラストアンカーを保持するリゾルバーが上流に 存在する可能性にはこだわらないということである。これは本文書のセクション 5.9で推奨したモデルである。 CD F/C 行番号 関連条件 動作 ====================================================================== 1 F A1 上流への問い合わせでCD=1に設定 0 F A2 上流への問い合わせでCD=1に設定 1 C A3 キャッシュの内容を返す (データまたはRCODE=2) 0 C A4 カバーするTA無し キャッシュの内容を返す (データまたはRCODE=2) 0 C A5 カバーするTA保持 キャッシュされた結果を署名 検証し、それを返す モデル 2: "CD=0受信時CDビット設定せず(never set when receiving CD=0)" このモデルは、署名を検証するリゾルバーが、たとえ問い合わせをカバーする トラストアンカーを保持していても、CD=0の問い合わせすべてについて、上流への 問い合わせでCD=0を設定するのでこのように名付けられた。この表によって表現 される一般的な運用哲学は、二つ以上のリゾルバーがQNAMEの署名検証の責任を 負ってもよく、一連のリゾルバーのどれかがQNAMEのバリデーションに失敗した ならば、それは問い合わせのバリデーション失敗を意味するということである。 このモデルの使用は推奨されない(NOT RECOMMENDED)。 CD F/C 行番号 関連条件 動作 ====================================================================== 1 F N1 上流への問い合わせでCD=1に設定 0 F N2 上流への問い合わせでCD=0に設定 1 C N3 データのキャッシュ データのキャッシュを返す 1 C N4 RCODE=2のキャッシュ 行番号N1として扱う 0 C N5 カバーするTA無し キャッシュの内容を返す (データまたはRCODE=2) 0 C N6 カバーするTA保持 & 行番号N2として扱う データのキャッシュは CD=1で生成された 0 C N7 カバーするTA保持 & 署名検証して返す データのキャッシュは CD=0で生成された モデル 3: "条件充足時CDビット設定(sometimes set)" このモデルは、署名を検証するリゾルバーが、CD=0の問い合わせ受信をトリガーに して、問い合わせをカバーするトラストアンカーを設定で保持しているかに 基づいて上流への問い合わせにCDビットを設定するのでこのように名付けられた。 カバーするトラストアンカーを保持していない場合、リゾルバーは上流への 問い合わせのCDビットをクリアする。 Weiler & Blacka Standards Track [Page 18] RFC 6840 DNSSEC Implementation Notes February 2013 カバーするトラストアンカーを保持している場合、リゾルバーはCD=1を設定し、 自身でバリデーションを実行する。この表によって表現される一般的な運用 哲学は、リゾルバーはQNAMEをカバーするトラストアンカーを保持する場合には バリデーションを試みるべきであり、カバーするトラストアンカーを保持しない 場合は、他のリゾルバーによるバリデーションを妨げるべきでないということ である。このモデルの使用は推奨されない(NOT RECOMMENDED)。 CD F/C 行番号 関連条件 動作 ====================================================================== 1 F S1 上流への問い合わせでCD=1に設定 0 F S2 カバーするTA保持 上流への問い合わせでCD=1に設定 0 F S3 カバーするTA無し 上流への問い合わせでCD=0に設定 1 C S4 データのキャッシュ データのキャッシュを返す 1 C S5 RCODE=2のキャッシュ 行番号S1として扱う 0 C S6 データのキャッシュは キャッシュの内容を返す CD=0で生成された 0 C S7 データのキャッシュは 署名検証を行い、キャッシュ CD=1で生成された& の内容を返す カバーするTA保持 0 C S8 RCODE=2のキャッシュ キャッシュの内容を返す 0 C S9 データのキャッシュは 行番号S3として扱う CD=1で生成された& カバーするTA無し 付録C. トラストアンカーの優先オプションに関する議論 本セクションでは、署名を検証するリゾルバーが得られた回答の署名検証を 行う際に、利用できるトラストアンカーの選択肢が存在する場合に使用する 幾つかの異なるポリシーを提示する。 C.1. 最近接名(Closest Encloser)ポリシー ポリシーの一つとして、応答のQNAMEに最も近いトラストアンカーを選択する というものが挙げられる。例として、"example."と"zone.example."の二つの トラストアンカーを設定で保持するバリデーターを考える。 "www.sub.zone.example."に対する応答を署名検証するように依頼された場合、 "最近接名(Closest Encloser)"ポリシーを使用するバリデーターは、 "zone.example."のトラストアンカーを選択する。 このポリシーの利点は、リゾルバー運用者が上位ゾーンのトラストアンカーよりも より強力な方法で検証可能な下位ゾーン(恐らくはリゾルバー運用者が 当該ゾーンと提携することになるのだろう)のトラストアンカーを自然な形で 優先(override)できることである。 Weiler & Blacka Standards Track [Page 19] RFC 6840 DNSSEC Implementation Notes February 2013 また、このポリシーは、必要な公開鍵の処理回数を最小化するので、リソースに 制限のある環境では有効である。 このポリシーの欠点は、サブゾーンのトラストアンカーが更新されず放置された 場合、ユーザーが予期しない、また不必要な署名検証失敗を引き起こすことである。 具体的な例として、バリデーターが"zone.example."のトラストアンカーを 2009年に設定し、"example."のトラストアンカーを2011年に設定した場合を 考える。2012年に"zone.example."のKSKがロールオーバーされ、DSレコードが 更新されたが、バリデーター運用者はトラストアンカーを更新しなかったとする。 すると、"最近接名"ポリシーを使用する場合、バリデーターは署名検証に失敗する。 C.2. 全トラストアンカー試行(Accept Any Success)ポリシー "全トラストアンカー試行"ポリシーは、署名検証結果が"Secure"となる (その場合最終的な署名検証結果も"Secure"となる)まで、適用可能なトラスト アンカーをすべて試みるというポリシーである。適用可能なトラストアンカーが すべて"Insecure"という結果に終わった場合に限り、最終的な署名検証結果も "Insecure"となる。複数のトラストアンカーが"Bogus"という結果となり、 "Secure"の結果を得られるものが無かった場合、最終的な署名検証結果は "Bogus"となる。 このポリシーの利点は、署名検証の失敗が最も少なくなるので、より良い ユーザー体感品質を提供できることである。トラストアンカーの一つが(先に 示した例のように)放置され期限切れとなった場合でも、ユーザーは依然として "Secure"な署名検証結果(ひいてはDNS応答)を得られる。 このポリシーの欠点は、バリデーターは自身が保持する複数のトラストアンカーの 中で最も弱い鍵の漏洩の影響を受けることである。しかし、旧いトラストアンカー を設定で永久に保持することで、影響を緩和することができる。 C.3. 出自に基づく優先付け(Preference Based on Source)ポリシー トラストアンカーが異なる出自である場合(例えば、自動更新([RFC5011])に よるもの、一つ以上のDNSSEC Lookaside Validation (DLV)レジストリ([RFC5074]) から得たもの、手動で設定されたもの等)、バリデーターは、それぞれの出自の 信頼性の認識に基づいた選択をしたいかもしれない。優先順位が設定オプションと して開示される場合もあるかもしれない。 例えば、手動で設定したトラストアンカーは積極的な保守が期待できないという 理由から、バリデーターはDLVレジストリから取得したトラストアンカーを 手動で設定したものよりも高い優先度にするかもしれない。 Weiler & Blacka Standards Track [Page 20] RFC 6840 DNSSEC Implementation Notes February 2013 逆に、手動で設定したトラストアンカーはより慎重に認証されたという理由 から、バリデーターは手動で設定したトラストアンカーをDLVレジストリから 取得したものよりも高い優先度にするかもしれない。 あるいは、バリデーターは、より複雑な優先付けをするかもしれない。例えば、 (設定オプションに基づき)手動で設定されたトラストアンカーの一部を最も 優先し、次に[RFC5011]記載の仕組みを使用して更新されたトラストアンカー、 その次はDLVレジストリから取得したトラストアンカー、その次は異なるDLV レジストリから取得したトラストアンカー、最後に手動で設定された残りの トラストアンカーが続くといったことも考えられる。 Authors' Addresses Samuel Weiler (editor) SPARTA, Inc. 7110 Samuel Morse Drive Columbia, MD 21046 US EMail: weiler@tislabs.com David Blacka (editor) Verisign, Inc. 12061 Bluemont Way Reston, VA 20190 US EMail: davidb@verisign.com Weiler & Blacka Standards Track [Page 21]