ネットワークワーキンググループ S. Weiler インターネットドラフト SPARTA, Inc. 更新(Updates): 4033, 4034, 4035, 5155 D. Blacka (承認後) VeriSign, Inc. 想定する状態: 標準化過程(Standards Track) 2010年3月27日 有効期限: 2010年9月28日 DNSSECbisの明確化と実装に関するノート draft-ietf-dnsext-dnssec-bis-updates-11 要旨 本文書は、DNSSECbisに関する一連の文書について、技術的仕様を明確化した 記述をまとめたものである。本文書は、正誤情報を集積し、実装者に情報提供を 行うことを意図するものである。 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 September 28, 2010. Copyright Notice 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 Weiler & Blacka Expires September 28, 2010 [Page 1] Internet-Draft DNSSECbis Implementation Notes March 2010 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 BSD License. 目次 1. はじめに . . . . . . . . . . . . . . . . . . . . . . . . . . . 3 1.1. 本文書の構成 . . . . . . . . . . . . . . . . . . . . . . . 3 1.2. 用語 . . . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. DNSSECbisプロトコル文書の重要な追加 . . . . . . . . . . . . . 3 2.1. NSEC3のサポート . . . . . . . . . . . . . . . . . . . . . 3 2.2. SHA-2のサポート . . . . . . . . . . . . . . . . . . . . . 4 3. スケーラビリティに関する懸念事項 . . . . . . . . . . . . . . . 4 3.1. BADキャッシュの実装 . . . . . . . . . . . . . . . . . . . 4 4. セキュリティに関する懸念事項 . . . . . . . . . . . . . . . . . 4 4.1. 不在証明 . . . . . . . . . . . . . . . . . . . . . . . . . 4 4.2. タイプANYの問合わせに対する応答の検証 . . . . . . . . . . 5 4.3. CNAMEの検査 . . . . . . . . . . . . . . . . . . . . . . . 5 4.4. 署名付き委任の検証 . . . . . . . . . . . . . . . . . . . . 5 5. 相互運用性に関する懸念事項 . . . . . . . . . . . . . . . . . . 6 5.1. 正規化を要するタイプコードリストの誤り . . . . . . . . . . 6 5.2. 未知のDSメッセージダイジェストアルゴリズム . . . . . . . . 6 5.3. プライベートアルゴリズム . . . . . . . . . . . . . . . . . 7 5.4. ローカルポリシーおよび複数のRRSIGに関する注意喚起 . . . . 7 5.5. 鍵タグの計算 . . . . . . . . . . . . . . . . . . . . . . . 8 5.6. 応答におけるDOビットの設定 . . . . . . . . . . . . . . . . 8 5.7. 問合わせにおけるADビットの設定 . . . . . . . . . . . . . . 8 5.8. 応答におけるADビットの設定 . . . . . . . . . . . . . . . . 8 5.9. CDビットが設定された問合わせの扱い . . . . . . . . . . . . 8 5.10. ネストされたトラストアンカー . . . . . . . . . . . . . . . 9 5.10.1. "最近接名"ポリシー . . . . . . . . . . . . . . . . . 9 5.10.2. "全トラストアンカー"ポリシー . . . . . . . . . . . . 10 5.10.3. "出自に基づく優先付け"ポリシー . . . . . . . . . . . 10 6. 軽微な誤り訂正と仕様の明確化 . . . . . . . . . . . . . . . . . 10 6.1. ゾーンカットの発見 . . . . . . . . . . . . . . . . . . . . 11 6.2. DNSKEYの使用法 . . . . . . . . . . . . . . . . . . . . . . 11 6.3. 例示における誤り . . . . . . . . . . . . . . . . . . . . . 11 6.4. RFC 5155における誤り . . . . . . . . . . . . . . . . . . . 12 7. IANAに関する考慮点 . . . . . . . . . . . . . . . . . . . . . . 12 8. セキュリティに関する考慮点 . . . . . . . . . . . . . . . . . . 12 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 13 9.1. Normative References . . . . . . . . . . . . . . . . . . . 13 9.2. Informative References . . . . . . . . . . . . . . . . . . 13 Appendix A. Acknowledgments . . . . . . . . . . . . . . . . . . . 14 Weiler & Blacka Expires September 28, 2010 [Page 2] Internet-Draft DNSSECbis Implementation Notes March 2010 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 14 Weiler & Blacka Expires September 28, 2010 [Page 3] Internet-Draft DNSSECbis Implementation Notes March 2010 1. はじめに 本文書は、DNSSECbis仕様の中心部分、具体的には当初[RFC4033]、[RFC4034]、 [RFC4035]で記述され、後に[RFC5155]で修正されたものについて、幾つかの 仕様の追加・明確化・修正等を列挙する。(中心的な一連の文書に対して 追加された仕様についてはセクション2を参照のこと)。 実装者への情報を提供するとともに、DNSSECbis文書が"標準化への提唱(Proposed Standard)"から"標準化への草稿(Draft Standard)"へと前進する際に検討が必要な 項目を集積することを意図している。 1.1. 本文書の構成 本文書は、DNSSECbis仕様について明確化した記述を重要度順に並べている。 具体的に、見落とすとセキュリティ上の問題を生じさせる可能性のある事柄の 明確な記述から始まり、重要度が順次下がっていき、最後に運用上の影響は わずかと予想される事柄の明確化を行う。 1.2. 用語 本文書におけるキーワード"しなければならない(MUST)"、"してはならない (MUST NOT)"、"要求される(REQUIRED)"、"するものとする(SHALL)"、 "しないものとする(SHALL NOT)"、"すべきである(SHOULD)"、 "すべきでない(SHOULD NOT)"、"推奨される(RECOMMENDED)"、 "してもよい/することができる(MAY)"、"任意である(OPTIONAL)"は、 [RFC2119]の記述どおりに解釈するものとする。 2. DNSSECbisプロトコルへの重要な仕様追加 本セクションでは、当初[RFC4033]のセクション10で指定された文書に加えて、 中心的なDNSSECプロトコル文書と見なすべき幾つかの文書を列挙する。 2.1. NSEC3のサポート [RFC5155]は、NSEC3 RRおよびNSEC3PARAM RRによるハッシュを使用した不在 証明法と、その動作について記述している。バリデータ実装は、NSEC3を サポートすることが強く推奨される。多くの有名なゾーンがNSEC3を使用すると 予想されるからである。NSEC3を使用する応答を検証できないバリデータは、 DNS空間の大部分の検証に失敗することになるだろう。 [RFC5155]は、[RFC4033]セクション10記載の"DNSSECプロトコル文書群"の 一部と見なすべきである。 ゾーンで使用されるアルゴリズムIDがRFC 5155定義のもの(DSA-NSEC3-SHA1 およびRSASHA1-NSEC3-SHA1)やRFC 5702定義のもの(RSASHA256およびRSASHA512) であれば、当該ゾーンがNSECではなくNSEC3を使用することができる(MAY)と 示唆していることに注意してもらいたい。実際、ゾーンはどちらを使用しても よい(MAY)ので、これらのアルゴリズムをサポートするバリデータはNSEC3と NSEC両方の応答をサポートしなければならない(MUST)。 Weiler & Blacka Expires September 28, 2010 [Page 4] Internet-Draft DNSSECbis Implementation Notes March 2010 2.2. SHA-2のサポート [RFC4509]はDS(Delegation Signer) RRにおいてダイジェストアルゴリズムに SHA-256を使用する方式を記述している。また[RFC5702]はDNSKEYおよびRRSIG RRで RSASHA256およびRSASHA512を使用する方式を記述している。バリデータ実装は、 DS、DNSKEY、RRSIG RRにおいて、これらのアルゴリズムをサポートすることが 強く推奨される。 [RFC4509]および[RFC5702]は、ともに[RFC4033]セクション10記載の"DNSSEC プロトコル文書群"の一部と見なすべきである。 3. スケーラビリティに関する懸念事項 本セクションは未完成である。近日置き換え予定の新しい記述では、 "他の様々な実装とうまく相互運用してほしい"、"権威サーバに問合わせを 大量に送りつけないように"、"検証失敗から回復させるために過剰に再試行 しないこと"といったテーマを扱う。 3.1. BADキャッシュの実装 RFC 4035のセクション4.7において、DNSSEC対応リゾルバがBADキャッシュ (検証失敗キャッシュ)を実装することを許可している。先に概略を述べた 懸念事項により、勧告を次のように変更する。DNSSEC対応リゾルバは、 RFC 4035の記載に従うBADキャッシュを実装すべき(SHOULD)である。 4. セキュリティに関する懸念事項 本セクションは、見落とした場合にセキュリティ上の問題を生じさせ得る 事柄を明確化する。 4.1. 不在証明 [RFC4035]のセクション5.4記載の不在証明検査アルゴリズムはあいまいである。 具体的に、このアルゴリズムの記述では、先祖(訳注: 親、親の親等)ゾーン側の NSECまたはNSEC3 RRを使用して、子ゾーンのRRを不当に不在証明できてしまう 可能性がある。 "先祖側の委任(ancestor delegation)"のNSEC RR(またはNSEC3 RR)とは、 以下の条件を満たすものである。 ・ NSビットが設定されている ・ SOAビットが設定されていない ・ 対応するRRSIG RRの署名者名フィールドがNSEC RRの所有者名または NSEC3 RRのオリジナル所有者名よりも短い Weiler & Blacka Expires September 28, 2010 [Page 5] Internet-Draft DNSSECbis Implementation Notes March 2010 先祖側の委任のNSEC RRまたはNSEC3 RRに基づいて、ゾーンカット子側のいかなる RRの不在も想定してはならない(MUST NOT)。具体的に、委任元の(オリジナル) 所有者名においては、DS RRを除く全RRが対象であり、当該所有者名よりも下位に おいては、タイプに関わらず全RRがその対象となる。 同様に、先のアルゴリズムはDNAME RRと同じ所有者名を持つNSEC RRまたは DNAME RRと同じオリジナル所有者名を持つNSEC3 RRによって、DNAMEより下位に ある名前の不在証明ができてしまう。DNAMEビットが設定されたNSEC RRまたは NSEC3 RRに基づいて、NSEC/NSEC3 RRの(オリジナル)所有者名のサブドメインに おいて、いかなるRRの不在も想定してはならない(MUST NOT)。 4.2. タイプANYの問合わせに対する応答の検証 [RFC4035]には、QTYPE=*の場合にどのように応答を検証するかの記述がない。 [RFC1034]のセクション6.2.2の記述は、"QTYPE=*に対する適正な応答には 問合わせ名に対するRRsetのサブセットを含めてよい"となっている。 つまり、QNAMEを所有者名とする全RRsetを応答する必要はない。 QTYPE=*の応答を検証する場合、受信した応答に含まれる、QNAMEとQCLASSに 一致する全RRsetを検証しなければならない(MUST)。どれか1つでも検証に失敗 した場合、応答は"Bogus(検証失敗：信頼禁止)"と見なされる。QNAMEとQCLASSに 一致するRRsetが存在しない場合、[RFC4035]のセクション5.4の(本文書で 明確化した)規則に従い、一致するRRsetが存在しなかったという事実が検証 されなければならない(MUST)。ここで明記しておくが、バリデータはQTYPE=*の 応答に対して、QNAMEを所有者名とする全レコードの受信を期待してはならない。 4.3. CNAMEの検査 [RFC4035]のセクション5には、CNAMEに基づく(または基づくはずの)応答の検証に 関してわずかな記述しかない。NOERROR/NODATA応答を検証する場合、バリデータは QNAMEおよびQTYPEに一致するNSEC RRまたはNSEC3 RRについて、問合わせタイプの ビットに加えてCNAMEビットも検査しなければならない(MUST)。この検査をしない 場合、攻撃者は正常なCNAME(の存在を示す)応答をNOERROR/NODATA応答に変換 できてしまう可能性がある。 4.4. 署名付き委任の検証 [RFC4035]のセクション5.2において、委任が"Secure(検証成功：信頼度高)" ではないことをバリデータが証明する場合、NSEC(またはNSEC3)のタイプビット マップにDSおよびSOAビットが不在であるか検査する必要があると規定している。 バリデータは、一致するNSEC(またはNSEC3) RRにNSビットが存在するか検査 しなければならない(つまり委任が実際に存在することを証明する必要がある)。 あるいは、当該委任がOpt-Outフラグの設定されたNSEC3 RRでカバーされている ことを確認する必要がある。この検査を行わない場合、偽造された未署名委任を 使用して、既存の署名レコードが未署名であると明示できてしまうかもしれない。 Weiler & Blacka Expires September 28, 2010 [Page 6] Internet-Draft DNSSECbis Implementation Notes March 2010 5. 相互運用性に関する懸念事項 5.1. 正規化を要するタイプコードリストの誤り DNS名を正規化する場合、NSEC RRやRRSIG RRのRDATA部に格納されている DNS名は小文字に統一がなされていない。 [RFC4034]のセクション6.2の項番3において、DNSSEC(の名前の順序付けと署名の 両方)で必要な正規化を行うために、RDATAに格納されたDNS名を小文字に統一する リソースレコードタイプの一覧が示されている。その一覧には誤ってNSECおよび RRSIGが含まれている。[RFC3755]によれば、NSECおよびRRSIGのRDATAに格納されて いるDNS名は小文字に統一すべきではない。 同様に、同セクションの一覧にHINFOが誤って二度現れる。HINFOレコードは ドメイン名を含まないので、小文字に統一する処理の対象ではない。 5.2. 未知のDSメッセージダイジェストアルゴリズム [RFC4035]のセクション5.2に、委任が署名されているが、委任先に対応する DS RRsetが提示する公開鍵アルゴリズムを全くサポートしていない場合に、 当該委任をどう扱うかに関する規則が記述されている。しかし、未サポートの メッセージダイジェストアルゴリズムを使用するDSレコードをどう扱うかに ついては明確な記述が無い。手短にまとめると、未知または未サポートの メッセージダイジェストアルゴリズムを使用するDSレコードは、未知または 未サポートのアルゴリズムを提示するDNSKEY RRを参照するDSレコードと 同じ方法で処理されなければならない(MUST)。 [RFC4035]は以下のように記述している。 バリデータが認証済みのDS RRsetに列挙されたアルゴリズムをどれも サポートしていない場合、リゾルバは親から子に至るサポートされた認証経路を 持たない。このような場合、リゾルバは先に説明したようなDS RRsetの 不在証明をするNSEC RRを認証した場合と同様に処理すべきである。 上記の記述を言い換えると次のようになる。ゾーンのセキュリティ状況を判定 する場合、バリデータは未知または未サポートのアルゴリズムを提示する DSレコードを無視する。その結果何も残らなければ、当該ゾーンを未署名として 扱う。 DSメッセージダイジェストアルゴリズムを考慮して以下の記述を追加する。 バリデータは未知または未サポートのメッセージダイジェストアルゴリズムを 使用するDSレコードも無視する。 Weiler & Blacka Expires September 28, 2010 [Page 7] Internet-Draft DNSSECbis Implementation Notes March 2010 5.3. プライベートアルゴリズム 先に述べたように、[RFC4035]のセクション5.2では、バリデータがゾーンの DSレコードで示された公開鍵アルゴリズムに基づき、ゾーンのセキュリティ状況を 判断するように要求している。しかし、[RFC4034]付録A.1.1記載のプライベート アルゴリズムを使用する場合、DS RRの8ビットのアルゴリズムフィールドは、 実際に使用されているアルゴリズムが何であるかを示すわけではない。 DS RRsetの中にプライベートアルゴリズムが存在しない場合や、提示される アルゴリズムの中にサポートしているものがある場合、特別な処理は何も 必要ない。しかし、そうでない場合は、ゾーンのセキュリティ状態は使用中の プライベートアルゴリズムをリゾルバがサポートするかどうかに依存する (ただし使用するハッシュ関数がサポートされている必要がある。本文書 セクション5.2を参照のこと)。このような場合、リゾルバはプライベート アルゴリズムを使用するDS毎に対応するDNSKEYを取得し、使用中のアルゴリズムを 検査しなければならない(MUST)。DNSSEC対応リゾルバは、DNSKEY RRの所有者名と RDATAを連結させたもののハッシュ値がDS RRのダイジェストフィールド値と 一致することを確認しなければならない(MUST)。それらが一致せず、また ゾーンが"Secure"であると主張するDSが他に存在しない場合、[RFC4035]の記載に 従い、DS RRsetが参照しているDNSKEYは"Bogus"と見なすべきである。 本セクションで示した仕様の明確化により、[RFC4955]が示唆するプライベート アルゴリズムの広範な使用が容易になるだろう。 5.4. ローカルポリシーおよび複数のRRSIGに関する注意喚起 任意のRRsetが複数のRRSIGを持つ場合について、[RFC4035]のセクション5.3.3では 次のように記述している。"リゾルバがこれらのRRSIG RRを検査しなければ ならないか、また複数のRRSIG RRが異なる結果を示した場合、その衝突を どのように解決するかについては、ローカルリゾルバのセキュリティポリシーが 決定する"。ほとんどの場合、リゾルバは有効なRRSIGが1つでもあれば、 当該RRsetは検証成功と見なして受理するのが賢明だろう。具体的に、最初の RRSIGの検証が失敗した場合、リゾルバは他のRRSIGを試すことが望ましい。 複数のRRSIGのうちどれか1つでも検証できたならば検証は成功と判断し、全ての RRSIGの検証に失敗した場合に限り検証失敗と判断するということである。 リゾルバがより制限の強いポリシーを採用している場合、適切に署名された データであっても、おそらくはキャッシュのタイミングに関する問題のために、 不必要に検証失敗する危険がある。更に、ある種のゾーン管理手法、例えば [RFC4641]のセクション4.2.1.2記載の"二重署名法によるZSKロールオーバー"の ような方式の動作の確実性は保証されないかもしれない。 Weiler & Blacka Expires September 28, 2010 [Page 8] Internet-Draft DNSSECbis Implementation Notes March 2010 5.5. 鍵タグの計算 [RFC4034] 付録B.1において、アルゴリズム1の鍵タグフィールドの計算を 誤って定義している。鍵タグは、公開鍵のモジュラスの下位24ビットのうち 上位16ビットであると正しく記述している。しかし、[RFC4034]は続いて誤った 記述をしており、これは公開鍵モジュラスのオクテット列の最後から4番目と 最後から3番目のオクテットであるとしている。しかし、これは正しくは 後ろから3番目と2番目のオクテットである。 5.6. 応答におけるDOビットの設定 [RFC3225]記載のとおり、問合わせのDOビットは応答にコピーされなければ ならない(MUST)。少なくとも1つの実装が異なる振る舞いをするので、リゾルバは 受理するものについて寛容になることが賢明だろう。 5.7. 問合わせにおけるADビットの設定 問合わせにおけるADビットの使用についてはこれまで未定義であった。 本文書は、これを問合わせ発行者がADビットを理解し、応答におけるADビットの 値に興味を持っていることを示す通知として定義する。これにより、問合わせ 発行者は、DOビットを設定してDNSSECデータを要求しなくても、ADビットを 理解することを示せるようになる。 5.8. 応答におけるADビットの設定 [RFC4035]のセクション3.2.3で、署名を検証するリゾルバが応答でADビットを 設定またはクリアする条件を記述している。旧来のスタブリゾルバや中継機器を 保護するために、署名を検証するリゾルバは、応答がRFC 4035のセクション3.2.3に 列挙された条件を満たすことに加えて、問合わせにDOビットまたはADビットの どちらかが設定されている場合に限り、ADビットを設定すべき(SHOULD)である。 5.9. CDビットが設定された問合わせの扱い CDビットが設定された問合わせを処理する場合、リゾルバは、DNSSEC検証に 失敗したデータも含めて応答可能なデータを全て返すべき(SHOULD)である。 RFC 4035のセクション3.2.2では、CDビットを設定した問合わせを処理する リゾルバは、上位DNSへの問合わせでCDビットを設定するように要求している。 RFC 4035の記述は、キャッシュからCDビットが設定されていない応答を得た際の 振る舞いが曖昧である。典型的な場合、新たな問合わせは不要で、また キャッシュもその問合わせを行った際にCDビットを設定したかという情報を 追跡する必要はない。しかし、キャッシュされた応答が"Server Failure" (RCODE 2)の場合は問題が生じる。これは、上位の署名を検証するリゾルバで 問合わされたデータのDNSSEC検証に失敗したことを示している。(RFC 2308は "Server Failure"の情報を最大5分間キャッシュすることを許容している)。 このような場合、新たにCDビットを設定した問合わせが必要となる。 Weiler & Blacka Expires September 28, 2010 [Page 9] Internet-Draft DNSSECbis Implementation Notes March 2010 バリデータがQNAMEまたはQNAMEの上位にある名前をトラストアンカーで保持 している場合(したがって応答を検証可能と期待することが妥当である場合)、 効率化のために上位DNSへの問合わせ全てにCDビットを設定したいことも あるだろう。 5.10. ネストされたトラストアンカー DNSSECバリデータは、ある応答に対して、応答ゾーンへの信頼の連鎖を検証する ために使用可能なトラストアンカーを複数持つ場合がある。例えば、バリデータが "example."および"zone.example."のトラストアンカーを設定で保持している 場合を考える。バリデータが"www.sub.zone.example."への応答を検証しようと する場合、どちらのトラストアンカーも適用できる。 このような状況では、DNSSECバリデータはどちらのトラストアンカーを使用 するかを選択する。どちらを選択するかは実装に委ねられる。選択ポリシーを 設定オプションとして明らかにすることは可能であり、そのようにすることが 望ましい。本セクションでは、以下で幾つかのポリシーについて議論する。 デフォルトとして、バリデータは以下のセクション5.10.2記載の"全トラスト アンカー"ポリシーを実装し、他のポリシーを設定オプションとして示す ことを推奨する。 5.10.1. "最近接名"ポリシー ポリシーの1つとして、応答のQNAMEに最も近いトラストアンカーを選択する というものが挙げられる。先に示した例では、"zone.example." のトラスト アンカーが選択される。 このポリシーの利点は、リゾルバ運用者が上位ゾーンのトラストアンカーよりも (リゾルバ運用者が当該ゾーンと提携する等の)より強力な方法で検証可能な 下位ゾーンのトラストアンカーを容易に優先(override)できることである。 (訳注: 署名検証を下位ゾーンから始められることから)このポリシーは必要な 公開鍵処理の量を最小化できるので、リソースに制限のある環境では有効だろう。 このポリシーの欠点は、サブゾーンのトラストアンカーの更新を怠った場合に、 ユーザが予期しない、また不必要な検証失敗を引き起こす可能性があること である。具体的な例として、バリデータが2009年に"zone.example."のトラスト アンカーを設定し、2011年に"example."のトラストアンカーを設定した場合を 考える。2012年に"zone.example."のKSKがロールオーバーされ、DSレコードが 更新されたが、当該バリデータの運用者はトラストアンカーを更新しなかった とする。"最近接名"ポリシーを使用する場合、当該バリデータは検証に失敗 することになる。 Weiler & Blacka Expires September 28, 2010 [Page 10] Internet-Draft DNSSECbis Implementation Notes March 2010 5.10.2. "全トラストアンカー"ポリシー 別のポリシーとして、使用可能なトラストアンカーを検証成功するまで全て試す というものが挙げられる。どれか1つでも検証に成功すれば検証結果は成功 ("Secure")となる。使用可能なトラストアンカーが全て検証失敗した場合に だけ、検証結果は失敗("Insecure")となる。検証に成功したトラストアンカーが 存在せず、1つ以上のトラストアンカーが"Bogus"と判定された場合、検証結果は "Bogus"となる。 このポリシーの利点は、検証失敗を引き起こすことが少なくなるので、ユーザに より高い利便性を提供可能なことである。トラストアンカーの1つが(先に示した 例のように)同期ずれを起こした場合でも、依然として検証は成功し、ユーザは DNSの応答を得ることができる。 このポリシーの欠点は、複数のトラストアンカーの中で最も弱い鍵の漏洩の 影響を受けることだが、旧いトラストアンカーを永久に設定で保持することで 影響を緩和することができる。 5.10.3. "出自に基づく優先付け"ポリシー トラストアンカーが異なる出自である場合(例えば、自動更新([RFC5011])された もの、1つ以上のDLVレジストリ([RFC5074])から取得したもの、手動で設定した ものなど)、バリデータは各トラストアンカーの出自の信頼性の認識に基づいた 選択をしたいかもしれない。優先順序は設定オプションとして明示されるだろう。 例えば、手動で設定したトラストアンカーは積極的な保守が期待できないという 理由から、バリデータはDLVレジストリから取得したトラストアンカーを 手動で設定したものよりも高い優先度にするかもしれない。 それとは逆に、手動で設定したトラストアンカーはより慎重に認証されたという 理由から、バリデータは手動で設定したトラストアンカーをDLVレジストリから 取得したものよりも高い優先度にするかもしれない。 バリデータによっては、より複雑な優先付けを行うかもしれない。(設定 オプションに基づき)手動で設定した一部のトラストアンカーを高い優先度に 設定し、次はRFC 5011を使用して自動更新するトラストアンカー、その次は DLVレジストリから取得したトラストアンカー、その次は異なるDLVレジストリから 取得したトラストアンカー、最後に手動で設定したその他のトラストアンカー といった順序付けも考えられる。 6. 軽微な誤り訂正と仕様の明確化 Weiler & Blacka Expires September 28, 2010 [Page 11] Internet-Draft DNSSECbis Implementation Notes March 2010 6.1. ゾーンカットの発見 [RFC4035]の付録C.8に、親ゾーンのサーバにDSの問合わせを送信することに 関する記述がある。これを実行するためには、リゾルバで初めに親サーバを 発見するための特別なルールを適用する必要がある。 [RFC4035]のセクション3.1.4.1で説明されているように、DNSSEC対応ネーム サーバでは、DS RRを扱うための特別な処理ルールを適用する必要がある。 またある状況では、リゾルバが親のNS RRsetを保持していない場合に、 親ゾーンのネームサーバを特定するための特別なルールを適用する必要がある。 [RFC4035]のセクション4.2でその仕組みを規定している。 6.2. DNSKEYの使用法 時おり"このRRsetに署名する際に異なるDNSKEYを使用することができるか" といった類の質問を見かける。 手短な回答は"間違いなく使える"である。DNSKEY RRsetのサイズが実用的な 範囲に収まっている必要はあるものの、ゾーン内のRRsetそれぞれに対して 異なるDNSKEYで署名することもできる。しかし、リゾルバに対してどのDNSKEYを 使用しているかを通知する方法がないことに注意してもらいたい。署名付き DNSKEY RRsetに含まれるどのDNSKEYであっても、ゾーン内の任意のRRsetを 認証するために使用できる。例えば、脆弱または信頼性の低いDNSKEYを使用して NSEC RRsetまたは他の動的に更新されるレコードを署名している場合、同じ DNSKEYを使用してゾーンの他のRRsetに署名できる。 更に、SEPビットの設定はDNSKEYをどのように使用するかについて何ら影響を 及ぼさないことに注意してもらいたい。[RFC4034]のセクション2.1.2において、 検証処理でこのビットを使用することを明確に禁止している。ゾーンへの唯一の セキュアエントリーポイントとして、SEPビットを設定しないままDNSKEYを使用 することもできる。更に、ゾーン内の(DNSKEY RRsetを除く)全RRsetに対して SEPビットを設定したDNSKEYで署名することもできる。また、SEPビットが設定 されていても、設定されていなくても、DNSKEY RRset自身を含むゾーン全体に 単一の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であるということは 回答がワイルドカード展開から得られた結果であることを意味する)。 Weiler & Blacka Expires September 28, 2010 [Page 12] Internet-Draft DNSSECbis Implementation Notes March 2010 [RFC4035]の付録C.6の第1段落にも軽微な誤りが存在する。"a.z.w.w.example"への 参照は、前の行にあるように"a.z.w.example"となるべきである。 6.4. RFC 5155における誤り 空の非終端に一致するNSEC3レコードは、事実上どのタイプにも関連付け られない。このNSEC3レコードのタイプビットマップは空になる。 [RFC5155]のセクション3.2.1には以下の記述がある。 タイプを持たない、つまりビットマップが全て0のブロックを含めては ならない(MUST NOT)。 しかし、同じセクションに以下の正規表現の記述がある。 タイプビットマップフィールド = ( ウインドウブロック番号 | ビットマップ長 | ビットマップ )+ 正規表現で、プラス("+")記号はプラス記号の前に1つ以上の要素が存在する ことを表現する。これは最低でも1つはウインドウブロックが存在することを 意味する。このウインドウブロックがタイプを持たない場合、先に示した記述と 矛盾する。したがって、RFC 5155セクション3.2.1の正しい記述は、以下のように なるだろう。 タイプビットマップフィールド = ( ウインドウブロック番号 | ビットマップ長 | ビットマップ )* 7. IANAに関する考慮点 本文書はIANAへの要求を何も規定しない。 8. セキュリティに関する考慮点 本文書は、DNSSECプロトコルの中心部分に2つの暗号仕様を追加している。 また、中心的な一連のDNSSEC文書における幾つかのあいまいな記述や記述漏れ のうち、実装者が理解し対応しないとセキュリティ上の障害を生じさせる可能性が あるものに対処した。セクション4記載の明確化された検証アルゴリズムは、 DNSSECが提供するセキュリティ機能を維持するために極めて重要である。 更に、セクション5記載の相互運用に関する懸念事項に対処せずにいると、 新しいアルゴリズムを追加するといった今後のDNSSECの変更または拡張を制限 することにもなりかねない。 9. References Weiler & Blacka Expires September 28, 2010 [Page 13] Internet-Draft DNSSECbis Implementation Notes March 2010 9.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. 9.2. Informative References [RFC3755] Weiler, S., "Legacy Resolver Compatibility for Delegation Signer (DS)", RFC 3755, May 2004. [RFC4641] Kolkman, O. and R. Gieben, "DNSSEC Operational Practices", RFC 4641, September 2006. [RFC4955] Blacka, D., "DNS Security (DNSSEC) Experiments", RFC 4955, July 2007. [RFC5011] StJohns, M., "Automated Updates of DNS Security (DNSSEC) Trust Anchors", RFC 5011, September 2007. Weiler & Blacka Expires September 28, 2010 [Page 14] Internet-Draft DNSSECbis Implementation Notes March 2010 [RFC5074] Weiler, S., "DNSSEC Lookaside Validation (DLV)", RFC 5074, November 2007. 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 DNSSECbis 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. The editors would like to thank Alfred Hoenes, Ed Lewis, Danny Mayer, Olafur Gudmundsson, Suzanne Woolf, Rickard Bellgrim, Mike St. Johns, and Scott Rose for their substantive comments on the text of this document. Authors' Addresses Samuel Weiler SPARTA, Inc. 7110 Samuel Morse Drive Columbia, Maryland 21046 US Email: weiler@tislabs.com Weiler & Blacka Expires September 28, 2010 [Page 15] Internet-Draft DNSSECbis Implementation Notes March 2010 David Blacka VeriSign, Inc. 21345 Ridgetop Circle Dulles, VA 20166 US Email: davidb@verisign.com Weiler & Blacka Expires September 28, 2010 [Page 16]