Independent Submission R. Gieben RFC: 7129 Google 分類: 情報提供(Informational) W. Mekking ISSN: 2070-1721 NLnet Labs 2014年2月 DNSにおける不在証明 要旨 不在証明により、リゾルバーは特定のドメイン名が存在しないことを検証できる。 また、ドメイン名が問い合わされた特定のリソースレコード(RR)を持たないことを 通知するために使用することもできる。DNSSEC(DNS Security Extensions)の 不在応答を返す場合、ネームサーバーは通常、最大二つのNSECレコードを応答に 付加する。NSEC3(NSEC version 3)を使用する場合、その数は3になる。 本文書は、DNSSECが不在証明応答を提供するために使用するNSEC及びNSEC3に ついて、付加的な背景の説明とこれまでの経緯を提供する。 Status of This Memo This document is not an Internet Standards Track specification; it is published for informational purposes. This is a contribution to the RFC Series, independently of any other RFC stream. The RFC Editor has chosen to publish this document at its discretion and makes no statement about its value for implementation or deployment. Documents approved for publication by the RFC Editor are not a candidate for any level of Internet Standard; see Section 2 of RFC 5741. Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at http://www.rfc-editor.org/info/rfc7129. Gieben & Mekking Informational [Page 1] RFC 7129 Authenticated Denial in DNS February 2014 Copyright Notice Copyright (c) 2014 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. 目次 1. はじめに ........................................................3 2. 不在証明 ........................................................4 2.1. NXDOMAIN 応答 ..............................................4 2.2. NODATA 応答 ................................................5 3. DNSSECの不在証明 ................................................6 3.1. NXT ........................................................7 3.2. NSEC .......................................................7 3.3. NODATA応答 .................................................9 3.4. NSECの問題点 ..............................................10 4 実験的なもので廃止となった仕組み: NO、NSEC2、DNSR ..............11 5. NSEC3 ..........................................................12 5.1. Opt-Out ...................................................14 5.2. ゾーンで使用されるNSEC3パラメーターの取得 .................15 5.3. DNSにおけるワイルドカード処理 .............................15 5.4. CNAMEレコードとワイルドカード .............................18 5.5. 最近接名とNSEC3レコード ...................................19 5.6. NSEC3レコードが三つ必要な理由 .............................24 6. セキュリティに関する考慮点 .....................................25 7. Acknowledgments ................................................25 8. References .....................................................26 8.1. Normative References ......................................26 8.2. Informative References ....................................26 付録 A. オンライン署名方式: 最小限にカバーするNSECレコード .......28 付録 B. オンライン署名方式: 方便的NSEC3 ..........................29 付録 C. ハッシュ化所有者名とオリジナル所有者名の対応表 ...........29 Gieben & Mekking Informational [Page 2] RFC 7129 Authenticated Denial in DNS February 2014 1. はじめに DNSSECは幾分複雑な案件だが、仕様の中に、他に比べて特に理解が難しい部分 がある。その一つが "不在証明" である。 不在証明(denial of existence)は、リゾルバーに特定のドメイン名が存在しない ことを通知する仕組みである。また、ドメイン名が問い合わされた特定の リソースレコード(RR)を持たないことを通知するために使用することもできる。 前者に対応するものがドメイン名の不在を意味する NXDOMAIN 応答([RFC2308] セクション2.1)で、後者に対応するものが NODATA 応答([RFC2308]セクション2.2) である。どちらも不在応答(negative response)として知られている。 不在証明(authenticated denial of existence)は、暗号技術を使用して不在応答に 署名を行う。しかし、回答が存在しない場合、何が署名されるべきだろうか? この問題をより複雑にするのが、署名付きゾーン内に存在しない名前へのあらゆる 問い合わせに対して使用できる不在応答をあらかじめ用意しておきたいという要望 である。詳細はセクション3参照のこと。 本文書は、不在証明がどのように機能するかを説明する。DNSSEC導入前のDNSに 使用されていた不在証明の説明から始めて、DNSSECに至るまでの取り組み過程を 提示する。その後、DNSSECが踏み出した第一歩を説明し、NSEC及びNSEC3が どのように機能するかを記述する。NXT、NO、NSEC2、DNSR といったレコードも 手短ながら登場する。これらのレコードはNSEC及びNSEC3の下地となったから である。 不在証明をより完全に理解するために、仕様を複雑にする厄介なDNSワイルド カードについても説明する必要がある。ワイルドカードは、CNAMEと組み合わさると 特に複雑になる。 注: 本文書において、ゾーンファイル例に含まれるドメイン名はドット(".")で終端 されるが、本文ではそうなっていない。本文書は、DNSSECについて充分理解している 読者を対象とする。以下のRFCを読むことは要求されないが、これらのRFCは 問題空間の理解に役立つ。 ・ [RFC5155] ・・・ DNSSECにおけるハッシュを使用した不在証明 ・ [RFC4592] ・・・ DNSにおけるワイルドカードの役割 また、以下のRFCは一般的なDNSSECの情報を提供する。 ・ [RFC4033]、[RFC4034]、[RFC4035] ・・・ DNSSEC仕様 Gieben & Mekking Informational [Page 3] RFC 7129 Authenticated Denial in DNS February 2014 ・ [RFC4956] ・・・ DNSSEC Opt-In。このRFCの状態は実験的(Experimental)だが、 良質な読み物である。 以下の三つの文書は、NSEC3の開発に関する背景情報を提供する。 ・ NO レコード [DNSEXT] ・ NSEC2 レコード [DNSEXT-NSEC2] ・ DNSR レコード [DNSR-RR] 2. 不在証明 DNSの基本的事項と、NXDOMAINの処理手順から説明を始める。 より見やすくするために、三つの名前("example.org", "a.example.org", "d.example.org")と四つのタイプ(SOA, NS, A, TXT)で構成された小さなDNSゾーン を使用する。簡潔にするため、クラスは表示せず(デフォルトはINである)、 SOAレコードも短縮する。その結果、以下に示すゾーンファイルが得られる。 example.org. SOA ( ... ) example.org. NS a.example.org. a.example.org. A 192.0.2.1 TXT "a record" d.example.org. A 192.0.2.1 TXT "d record" 図1: 未署名の "example.org" ゾーン 2.1. NXDOMAIN 応答 リゾルバーがこのゾーンを提供するサーバーに "a.example.org" に対応する TXT タイプ のデータを問い合わせる場合、次のように表記する問い合わせを発行する: "a.example.org TXT"。 ネームサーバーは保持するゾーンデータを調査し、回答を生成する。今回の場合、 データの存在を肯定する次のようなものとなる: "はい、データは存在します。 これがそのデータです"。結果として返される応答は以下のようになる。 ;; status: NOERROR, id: 28203 ;; ANSWER SECTION: a.example.org. TXT "a record" ;; AUTHORITY SECTION: example.org. NS a.example.org. Gieben & Mekking Informational [Page 4] RFC 7129 Authenticated Denial in DNS February 2014 "status: NOERROR" は正常に終了したことを通知する。"id" は問い合わせと 回答を一致させるために使用する整数である。回答部には回答が存在する。 権威部は、"example.org" ゾーンに関する情報を持つネームサーバー名を保持 する。権威部の付加は任意(optional)であることに注意。 リゾルバーが "b.example.org TXT" を問い合わせると、問い合わされた名前は存在しない という以下の回答を受理する。 ;; status: NXDOMAIN, id: 7042 ;; AUTHORITY SECTION: example.org. SOA ( ... ) 今回の場合、回答部は無く、状態は NXDOMAIN に設定される。この応答から リゾルバーは "b.example.org" は存在しないと判断する。権威部は "example.org" のSOAレコードを保持するので、リゾルバーはこれを使用して不在応答をキャッシュ することができる。 2.2. NODATA 応答 "不在を通知する" 応答は NXDOMAIN が唯一ではないと理解することが重要である。 名前は存在するが、問い合わされたタイプが存在しない場合もある。この種の不在に 対しては NODATA 応答と呼ばれるものが返される。ネームサーバーに対して "a.example.org AAAA" を問い合わせた場合の回答は以下のようになる。 ;; status: NOERROR, id: 7944 ;; AUTHORITY SECTION: example.org. SOA ( ... ) "status: NOERROR" は、"a.example.org" という名前が存在することを示して いる。しかし応答には回答部がない。ここが NXDOMAIN 応答と NODATA 応答の 違いである。メッセージの残り部分は非常に似ている。リゾルバーは、これら 情報の断片をつなぎ合わせて、"a.example.org" は存在するが "AAAA" レコード は保持していないと判断する。 Gieben & Mekking Informational [Page 5] RFC 7129 Authenticated Denial in DNS February 2014 3. DNSSECの不在証明 前のセクションで説明した内容を、DNSSECの提供するセキュリティに対応した 世界に変換する必要がある。しかし、DNSSECの幾つかの基本理念との整合を 検討しなければならない。 1. ネームサーバーは、回答と署名に関する処理をその場で(on the fly)実行しても 構わないが、プロトコルは "まず署名してからロードする" という姿勢が 念頭に置かれている。この理念は、NXDOMAIN とは整合しない。しかし、 DNSSECの設計の大部分は、不在証明に対応する必要があるという事実に 由来している。DNSにNXDOMAINが無ければDNSSECはもっとシンプルになった だろうが、はるかに不便になっていただろう。 2. DNSメッセージのメッセージヘッダーは署名されない。これは "status: NXDOMAIN" は信頼できないことを意味する。実際に、ADビット(ADは Authentic Data の略。[RFC3655]参照)を含むヘッダー全体を偽造できる ことは検討の材料になる。 3. DNSワイルドカードとCNAMEレコードは、問題の複雑さを劇的に悪化させる。 この点についてはセクション5.3及び5.4で採り上げる。 一つめの基本理念は、すべての不在証明応答は事前に生成される必要があることを 意味する。しかし、(想定されるすべての)不在応答を事前に生成することは不可能 である。 あらゆる種類の不在を証明するために、汎用の否定レコードを使用する選択肢は とれない。そのようなレコードは再生攻撃(replay attack)に対して脆弱である。 具体的に、ネームサーバーに対して実際に存在する任意のレコードを問い合わせると、 中間者(man in the middle)は汎用の否定レコードを無制限に再生できてしまう。 その場合、応答が正当なものか偽造されたものかを判定することは不可能である。 言い換えると、汎用の否定レコード再生することで、"あらゆる"応答を不在応答に できてしまう。 また、回答に含まれるQNAMEに署名することで、実質上 NXDOMAIN 応答に署名 できるかもしれない。このアプローチは理論的には機能するが、オフラインで署名 するという理念とは整合しない。 この問題を解決した方法は、存在する二つの名前のすき間を定義するレコードの 導入である。言い換えると、このレコードはゾーン内の空隙(存在しない名前)を 定義する。このレコードは事前に署名でき、署名付きでリゾルバーに提供できる。 付録A及びBに、この方式と互換性のあるオンライン署名方式を記載している。 これら多くの問題点を俯瞰してみると、DNSSECの設計者達が容易なルートを 採り、オンライン署名を許容しなかったのはなぜか?という疑問が生じる。 その理由は、その当時(2000年以前)、オンライン署名はその当時最新のハード ウェアでも実現不可能だったからである。 Gieben & Mekking Informational [Page 6] RFC 7129 Authenticated Denial in DNS February 2014 大規模なサーバーは、毎秒 2,000~6,000 の問い合わせを受ける(以後、これを 2,000~6,000 qpsと表記する)。ピークは20,000 qps以上にもなることに留意 してほしい。この程度の水準で署名生成ができるようにスケールさせるのは いつの時代においても課題なのである。別の問題は、鍵管理であった(今も そうだ)。オンライン署名が機能するためには、"すべての"権威サーバーが秘密鍵に アクセスできる必要がある。これはセキュリティリスクを伴うと考えられる。 以上により、プロトコルはオンライン署名に依存しないことが求められる。 現在使用されている解決策 (NSEC/NSEC3) までの道のりは遠かった。始まりは NXT(next)レコードだった。続いて NO(not existing)レコードが導入されたが、 これはRFC化されなかった。その後、NXTはNSEC(next secure)レコードに置き換え られた。更に NSEC2/DNSR を経て、最終的にRFC 5155規定の NSEC3 (Next SECure version3)に至っている。 3.1. NXT 不在証明を規定する最初の試みは、NXT([RFC2535])である。RFC 2535の セクション5.1で以下のようにNXTレコードが導入されている。 NXTリソースレコードは、所有者名(owner name)を持つRRが、ゾーン内の特定の 名前と名前のすき間に存在しない通知、また存在する名前はどのような RRタイプを保持しているかの通知を署名付きで行うために使用される。 NXTレコードは、どの名前を保持しているかを明示することで、どの名前を保持 していないかを暗示する。NXTはNSECに置き換えられた。次セクションで、NSEC (NXT)がどのように機能するか(機能したか)を説明する。 3.2. NSEC [RFC3755]で、すべてのDNSSECのタイプ名が新しくなった。SIGはRRSIGに、KEYは DNSKEYに、NXTはNSECに変更された。また、DNSSEC処理に存在した軽微な問題が (訳注: 幾つかの関連RFCで)修正された。具体的に、タイプビットマップが 再定義され、([RFC2535]のセクション5.2で規定された)127を越えるタイプを 列挙できるようになった。 NXTと全く同じように、NSECは二つの名前のすき間を記述するために使用される。 これにより、ゾーン内に存在しない名前をリゾルバーに対して間接的に通知する。 これを機能させるには、先に例示した "example.org" ゾーンを正規順 (canonical order)でソートし([RFC4034]セクション6.1)、その後にNSECを生成 する必要がある。例示ゾーンの場合、三つのNSECレコードが追加される。NSEC レコードは、各名前に対してそれぞれ設定され、次の名前とのすき間をカバーする。 そして順序的に最後に位置するNSECレコードは、ゾーン先頭(頂点)の名前に戻る ポインタを提供する。これはRFC 4034の要求に従うものである。各NSECレコード の関係を以下の図2に示す。 1. 一つめのNSECは、"example.org" と "a.example.org" のすき間をカバーする。 Gieben & Mekking Informational [Page 7] RFC 7129 Authenticated Denial in DNS February 2014 2. 二つめのNSECは "a.example.org" と" "d.example.org" のすき間をカバーする。 3. 三つめのNSECは "example.org" に戻るポインタを提供し、"d.example.org" と "example.org" のすき間 (つまりゾーンの最後まで)をカバーする。 名前と名前のすき間を定義し、リソースレコードを対応づけたので、これで署名が 可能になった。 example.org ** +-- ** <--+ (1) / . . \ (3) / . . \ | . . | v . . | ** (2) ** a.example.org ** ---------> ** d.example.org 図2: "example.org" ゾーンに設定されたNSECレコード。 矢印(→)がNSECレコードを表現しており、ゾーン頂点から開始される。 署名ゾーンはネームサーバーにロードされる。それは以下のようなものになる。 example.org. SOA ( ... ) DNSKEY ( ... ) NS a.example.org. NSEC a.example.org. NS SOA RRSIG NSEC DNSKEY RRSIG(NS) ( ... ) RRSIG(SOA) ( ... ) RRSIG(NSEC) ( ... ) RRSIG(DNSKEY) ( ... ) a.example.org. A 192.0.2.1 TXT "a record" NSEC d.example.org. A TXT RRSIG NSEC RRSIG(A) ( ... ) RRSIG(TXT) ( ... ) RRSIG(NSEC) ( ... ) d.example.org. A 192.0.2.1 TXT "d record" NSEC example.org. A TXT RRSIG NSEC RRSIG(A) ( ... ) RRSIG(TXT) ( ... ) RRSIG(NSEC) ( ... ) 図3: NSECレコード(及び署名)が付加された、ソートされた署名付き "example.org" ゾーン例。簡潔にするため、クラスは表示せず (デフォルトはINである)、SOA、DNSKEY、RRSIGレコードは短縮した。 Gieben & Mekking Informational [Page 8] RFC 7129 Authenticated Denial in DNS February 2014 DNSSEC対応リゾルバーが "b.example.org" を問い合わせると、"status: NXDOMAIN"の メッセージを受信する。この情報自体は無意味である(DNSメッセージヘッダーは 署名されていないので、偽造可能であることを思い出してもらいたい)。 "b"が存在しないことを署名付きで検知できるようにするため、応答には、 "b" があるはずの名前空間をカバーする署名付きNSECレコードが存在しなければ ならない。 以下に示すレコード a.example.org. NSEC d.example.org. A TXT RRSIG NSEC は、"b" は "a" の後に配置されるはずだが、次に現れる所有者名は "d.example.org" であるから、"b" は存在しない、という事実を厳密に提示する。 唯一この処理を実行することで、リゾルバーは "b" が存在しないと判定できる ようになる。NSECレコードの署名が有効であれば、"b"の不在が証明される。 これで不在証明が実現した。ワイルドカード展開を否定するために、NSEC レコードを同様に付加する必要がある。セクション5.3参照のこと。 中間者は、例えば "c.example.org" への問い合わせに対して、依然としてこの NXDOMAIN 応答を再生できることに注意。しかし、それは問い合わせに対する 正しい応答だと証明できるため、無害である。 3.3. NODATA応答 NSECレコードは、NODATA応答でも使用される。その場合、タイプビットマップを より注意深く検査する必要がある。NSECレコードのタイプビットマップは、NSECが 関連づけられている名前が保持するレコードタイプを通知する。"a.example.org" に対するNSECレコードを調査すると、ビットマップには、次に示すタイプ A、TXT、 NSEC、RRSIG が設定されていることがわかるだろう。これは、ゾーン内に名前 "a" に対する A、TXT、NSEC、RRSIG レコードが必ずあるはずだということを示している。 NSECレコードのタイプビットマップを使用することで、リゾルバーは、名前は存在 するがタイプは存在しないこと検証できる。例えば、リゾルバーが "a.example.org AAAA" を問い合わせると、応答は以下のようになる。 ;; status: NOERROR, id: 44638 ;; AUTHORITY SECTION: example.org. SOA ( ... ) example.org. RRSIG(SOA) ( ... ) a.example.org. NSEC d.example.org. A TXT RRSIG NSEC a.example.org. RRSIG(NSEC) ( ... ) Gieben & Mekking Informational [Page 9] RFC 7129 Authenticated Denial in DNS February 2014 リゾルバーは権威部を検査し、以下のように判定すべきである。 (1) "a.example.org" は存在する。なぜなら、NSEC の所有者名だからである。 (2) 問い合わせタイプ (AAAA) は存在しない。なぜなら、タイプビットマップ内に AAAAが列挙されていないからである。 NSECで使用されるNXDOMAIN応答、NODATA応答の実現方法が、DNSSECの不在証明 の基本となっている。 3.4. NSECの問題点 NSEC(及びNXT)には二つの問題がある。一つめはゾーンウォーキング(zone walking) が出来てしまうことである。NSECレコードは、存在する名前から別の存在する名前 へのポインタを提供する。例示ゾーンの場合、"example.org" は "a.example.org" をポイントし、"a.example.org" は "d.example.org" をポイントする。また、 "d.example.org" から "example.org" に戻るポインタが提供される。これにより、 "example.org" ゾーン全体の再構成が可能となる。その結果、ゾーン転送を管理上 ブロックするという試みは失敗する([RFC2065]セクション5.5)。 二つめの問題は、委任が主たる内容の(delegation-centric)大規模ゾーン ([RFC5155]セクション1.1)でDNSSECを展開する場合、どの名前に対しても NSECとRRSIGが設定される。その結果、(署名付きの場合)ゾーンサイズが極めて 大きくなってしまう。この種のゾーンのオペレーターがDNSSECを展開しようと すると、導入コストの問題に直面する。これはDNSSEC採用の妨げになる。 これら二つの問題が、結果的にNSEC3開発につながった。NSEC3は以下を実現する。 ・ 所有者名を不明瞭なものに変換する方法を提供することで、ゾーンウォーキング を抑止する。 ・ 次所有者名に指定されるべき名前をスキップできる。この特徴をOpt-Out と呼ぶ(セクション5.1参照)。これは、ゾーン内の全レコードがNSEC3と署名を 持たないことを意味する。この仕組みにより、DNSSECを"段階的に範囲を拡大 する"形で展開することが可能となる。 ゾーンウォーキングの問題を軽減する別の方法も存在することに注意。 RFC 4470[RFC4470]は、最小限にカバーする(minimally covering)NSECレコード を導入することで、ゾーンウォーキングを抑制する。この方法は付録Aに 記述される。 NSEC3について詳細に説明する前に、その先行的な取り組みである NO、NSEC2、DNSR について手短に論じることにする。 Gieben & Mekking Informational [Page 10] RFC 7129 Authenticated Denial in DNS February 2014 4. 実験的なもので廃止となった仕組み: NO、NSEC2、DNSR NSECが定義されるよりもだいぶ前に、NOレコードが導入された。これは、 NXTレコードによって生じたゾーンウォーキングの問題を解決するために、 ハッシュ化所有者名のアイディアを使用した最初のレコードである。 NOレコードは、NXTレコードのタイプビットマップの問題も解決したが、 これはあまり空間効率の良い方法ではなかった。当時(2000年前後)、ゾーン ウォーキングは新しいレコードの導入を正当化するほど重要な問題とは考えられて いなかった。また、当時の人びとは、不在を通知する別の手段が開発されることで、 DNSSECの展開が抑制されるのではないかとの懸念を持っていた。そのため、 NOレコードは棚上げとなり、NXTが残された。 新しいDNSSEC仕様[RFC4034]が執筆された時点においても、人びとは依然として ゾーンウォーキングが解決されるべき問題だと納得していなかった。その結果、 NSECが登場したが、NXTから二つの問題を受け継いだままだった。 数年後、NSECの二つの問題を解決する手段としてNSEC2が導入された。NSEC2文書 [DNSEXT-NSEC2] には以下の段落がある。 本文書は、存在しない名前の不在証明を可能にしつつ、所有者名を秘匿する、 従来とは別の方式を提案する。提案方式は、二つの新しいRRタイプ、NSEC2と EXIST を使用する。 不在証明の仕組みにおけるEXISTレコードの位置づけの説明には、特別な注意を 払う必要がある。EXISTレコードはRDATAを持たないレコードとして定義され、 ドメイン名の存在を通知するために使用される。[DNSEXT-NSEC2]から引用する。 ワイルドカードでカバーされる範囲内にレコードが存在しないことを証明 するためには、最近接名(closest encloser)(訳注: 本文書後半に説明がある) が存在することを証明する必要がある。EXISTレコードがそれを行う。 EXISTの所有者名は最近接名で、RDATAは持たない。他に最近接名の存在を 証明するRRがあるならば、EXISTレコードのかわりにそのレコードを使うべき (SHOULD)である。 このレコードの導入は、(特にDNSSECにおいて)ワイルドカードが実際に何を意味 するかの議論を引き起こした。NSEC3が標準化される前に "DNSにおけるワイルド カードの役割" [RFC4592] が標準化されたのは、恐らく偶然ではないだろう。 NSEC2は、レコード内の"次所有者名"を(SHA1とソルトで)ハッシュ化することで ゾーンウォーキングを無効化し、問題を解決した。しかし、Opt-Out機能は 無かった。 DNSRレコードは、ハッシュ化した名前を使用することでゾーンウォーキングを失敗 させる別の試みである。また、("Authoritative Only Flag"と称する)Opt-Outの 概念も導入し、委任が主たる内容のゾーンにおけるDNSRの使用を限定できた。 Gieben & Mekking Informational [Page 11] RFC 7129 Authenticated Denial in DNS February 2014 これらの提案は完成まで至らなかったが、有用な洞察を提供してくれた。 以下に要約する。 ・ NOレコードは、ハッシュ化の仕組みを導入した。しかし、このアイディアは 長い間なおざりにされていた。 ・ NSEC2レコードは、ワイルドカードが完全に理解されていなかったことを 明らかにした。 ・ DNSRレコードは、Opt-Outを通知するために、RDATA内の新しいフラグフィールド を使用した。 5. NSEC3 NSEC2及びDNSRから得られた経験を基盤としてNSEC3が構築された。NSEC3は、 Opt-Outと名前ハッシュ化の両機能を保持する。NSEC3は人びとがNSECに感じて いた問題を解決したが、若干複雑になった。 NSEC3はNSECを置き換えない。どちらもDNSSECレコードとして定義される。 従って、DNSSECはNSEC・NSEC3という二つの異なる不在証明の恩恵を 受けられる。NSEC3では、所有者名を含むすべての名前がハッシュ化される。 これは、NSEC3連鎖は正規順ではなくハッシュ整列順でソートされることを 意味する。所有者名がハッシュ化されるので、"example.org" の次所有者名は "a.example.org" にはならない。次所有者名がハッシュ化されるので、 ゾーンウォーキングは困難になる。 オリジナル所有者名の取得をより困難にするため、前回のハッシュ出力を入力と したハッシュ処理を複数回繰り返すことができる。また、事前に計算した ハッシュ値をゾーン間で再利用するのを防ぐため、(ゾーン別に)ソルトを付加 できる。例示ゾーン "example.org" のNSEC3処理で、名前を3回ハッシュし ([RFC5155]セクション5)、ソルトとして"DEAD"を使用した。結果得られた、 標準的なNSEC3レコードは以下のようになる。 15bg9l6359f5ch23e34ddua6n1rihl9h.example.org. ( NSEC3 1 0 2 DEAD A6EDKB6V8VL5OL8JNQQLT74QMJ7HEB84 NS SOA RRSIG DNSKEY NSEC3PARAM ) 1行目にハッシュ化所有者名 "15bg9l6359f5ch23e34ddua6n1rihl9h.example.org" が現れる。これは、FQDN "example.org" のハッシュを Base32 [RFC4648] で エンコードしたものである。"example.org" をハッシュ化しても、ゾーン名が ドメイン名のように再度現れることに注意。例示ゾーンの場合、フォーマットは "Base32(SHA1(FQDN)).example.org" となる。 Gieben & Mekking Informational [Page 12] RFC 7129 Authenticated Denial in DNS February 2014 次ハッシュ化所有者名 "A6EDKB6V8VL5OL8JNQQLT74QMJ7HEB84" (2行目)は、 "d.example.org" のハッシュを Base32 で表現したものである。 ここで、(NSECでは"a.example.org"であったはずの)次所有者名として "d.example.org" が使用されているのは、ハッシュ整列順に従うから であることに注意。"d.example.org" のハッシュは、ゾーン頂点である "example.org" のハッシュの次に位置する。また、".example.org" という ゾーン名が次ハッシュ化所有者名に付加されないことにも注意。この名前は 必ず現在のゾーン内に存在するからである。 NSEC3の "1 0 2 DEAD" 部は、以下の情報を通知する。 ・ ハッシュアルゴリズム: 1 (SHA1がデフォルトである。NSEC3で使用される 他のハッシュアルゴリズムは定義されていない。[RFC5155]セクション3.1.1 参照)。 ・ Opt-Out: 0 (無効。[RFC5155]セクション6参照)。 ・ ハッシュ繰り返し回数: 2 (値0は最低限実行される1回を意味するので、 この値は3回の繰り返しを意味する。[RFC5155]セクション3.1.3参照)。 ・ ソルト: "DEAD" ([RFC5155]セクション3.1.5参照)。 最後に、タイプビットマップが現れる。これはNSECのビットマップと同じで、 オリジナル所有者名が保持するタイプを列挙する。先に示した例において、 タイプ NSEC3 は列挙されていないことに注意。これは、オリジナル所有者名 ("example.org")はタイプNSEC3を保持していないという事実による。 NSEC3はハッシュ化した名前にしか設定されない。 "1.h.example.org" のような名前をハッシュ化して、NSEC3の単一ラベルにする 場合、所有者名として使用するのであれば "1.h.example.org" は "117gercprcjgg8j04ev1ndrk8d1jt14k.example.org" になる。次の所見は重要 である。名前のハッシュ化によって、ゾーンの深さに関する情報が失われる。 ハッシュ化により、NSECとは対照的にフラットな名前空間が導入される。 先に使用した名前("1.h.example.org")は、Empty Non-terminalを生成する。 Empty Non-terminalとは、一つ以上のサブドメインがRRを持つが、それ自体は 関連するRRを持たない場合にだけ生成されるドメイン名である ([RFC5155] セクション1.3)。例として、以下に示すレコードを考える。 1.h.example.org. TXT "1.h record" このレコードは、以下の二つの名前を生成する。 1. "1.h.example.org": タイプ TXT を持つ。 2. "h.example.org": タイプを何も持たない。これが Empty Non-terminal である。 Gieben & Mekking Informational [Page 13] RFC 7129 Authenticated Denial in DNS February 2014 Empty Non-terminalはNSEC3レコードを持つが、NSECレコードは持たない。 セクション5.5で、リゾルバーがEmpty Non-terminalのNSEC3レコードを使用して 不在証明を検証する方法を提示する。 NSEC3が常に有用とは限らないことに注意。例えば、ip6.arpa や in-addr.arpa 等の 逆引きゾーンのように、高度に構造化されたゾーンでは、NSEC3を使用していても、 その構造のためにゾーンウォーク可能である。同様に、小規模で平凡なゾーンは 容易に内容を類推可能である。このような場合、NSEC3はゾーンウォーキングを 防げないにもかかわらず、権威サーバーやバリデーター(validator)に計算負荷が 課されるだけになる。 5.1. Opt-Out 名前のハッシュ化により、NSECのゾーンウォーキング問題は軽減された。 もう一つの問題、Insecureなゾーンへの委任(訳注: 委任先が未署名なので、 親側にNSはあってもDSがない委任)を署名付きで実施すると高コストになる問題 にはOpt-Outで対応する。Opt-Outを使用する場合、Insecureな委任(及び Insecureな委任からしか生じないEmpty Non-Terminal)の名前はNSEC3レコードが 不要となる。Insecureな委任エントリそれぞれについて、(Opt-Outを使用せず すべて署名付きで委任を行う場合に比べて)少なくとも2レコード分、NSEC3レコード 一つと対応するRRSIGレコード一つ分はゾーンサイズを縮小可能である。Insecureな 委任がEmpty Non-terminalを生じさせる場合、より多くのレコードをゾーンから 除外できる。 Opt-Outを有効にしたNSEC3レコードは、Insecureな委任の存在も不在も証明 できない。言い換えると、Opt-Outされた委任は、DNSSECが提供する暗号技術に 基づくセキュリティの恩恵を受けられない。 最近見つかった、まれだが面倒な事例(corner case)(RFC Erratta ID 3441 [Err3441]参照)は、Opt-Outされた委任が単に安全でなくなるだけではなく、 これらの委任から生じるEmpty Non-terminal空間にも問題が生じることを 示している。 Empty Non-terminal空間に含まれる名前は、[RFC4592]の定義に従うと存在 している。従って、サーバーはその名前への問い合わせに対してNODATA応答を 返すべきである。しかし、バリデーターは NODATA応答を証明するNSEC3レコード を必要とする([RFC5155]セクション8.5)。 バリデーターは、QNAMEに一致するNSEC3 RRが存在し、そのタイプビットマップ フィールドにはQTYPEとCNAMEタイプのいずれも設定されていないことを 検証しなければならない(MUST)。 ここで示した仕様の矛盾を解消する方法は、Empty Non-terminalについては、 たとえそれがInsecureな委任からしか生じないものであったとしても、 必ずNSEC3を設定することである。 Gieben & Mekking Informational [Page 14] RFC 7129 Authenticated Denial in DNS February 2014 5.2. ゾーンで使用されるNSEC3パラメーターの取得 存在しないレコードへの問い合わせを権威サーバーが受理した場合、問い合わせ名を ハッシュし、既存のハッシュ化名のどのすき間でカバーされるかを判定しなければ ならない。これを実行するためには、権威サーバーがゾーン固有のNSEC3パラメーター (ハッシュ繰り返し回数、ソルト)を知っている必要がある。 パラメーター取得の方法として、ゾーンをロードする際にNSEC3をスキャンし、 そこからパラメーターを収集することが考えられる。しかしそのためには、 ゾーン内に同じパラメーターを使用したNSEC3の完全なセットが最低一つは存在する ことを確認する必要がある。従って、全NSEC3レコードの検査が必要となる。 そこで、より洗練された方法が設計された。その方法は、ゾーン頂点への配置を 要求するNSEC3PARAMと称する新しいレコードの導入である。新レコードの役割は、 権威ネームサーバーがゾーンで使用中のNSEC3パラメーターを直接参照可能な 不動の場所を提供することである。また、レコードはゾーン内に配置される ので、容易にセカンダリに転送することができる。 5.3. DNSにおけるワイルドカード処理 ここまで、否定応答における不在証明についてだけ議論してきた。しかし、 肯定応答でも不在証明が生じることがある。具体的に、応答の回答部が空 でない不在証明である。このような状況は、ワイルドカードのために発生する。 ワイルドカードは、最初のDNS RFCからDNS仕様の一部である。ワイルドカードに より、特定のタイプを持つすべての名前を一度に定義することができる。 例示した "example.org" ゾーンで、次のようなワイルドカードを加える場合を 考える。 *.example.org. TXT "wildcard record" 全体的に見ると、(未署名の)ゾーンは以下のようになる。 example.org. SOA ( ... ) example.org. NS a.example.org. *.example.org. TXT "wildcard record" a.example.org. A 192.0.2.1 TXT "a record" d.example.org. A 192.0.2.1 TXT "d record" 図4: ワイルドカードレコードを含む "example.org" ゾーン Gieben & Mekking Informational [Page 15] RFC 7129 Authenticated Denial in DNS February 2014 リゾルバーが "z.example.org TXT" を問い合わせると、ネームサーバーは NXDOMAIN を返す代わりに、ワイルドカードを展開して以下を応答する。 ;; status: NOERROR, id: 13658 ;; ANSWER SECTION: z.example.org. TXT "wildcard record" しかし、リゾルバーはこの応答がワイルドカードを展開して生成されたと検知 できない。回答は受信した通りのものだと判断する。DNSSECでは、この応答は どのようになるだろうか? ;; status: NOERROR, id: 51790 ;; ANSWER SECTION: z.example.org. TXT "wildcard record" z.example.org. RRSIG(TXT) ( ... ) ;; AUTHORITY SECTION: d.example.org. NSEC example.org. A TXT RRSIG NSEC d.example.org. RRSIG(NSEC) ( ... ) 図5: ワイルドカード展開して得られた、DNSSECが有効な応答 "z.example.org" に対するTXTレコードのRRSIGは、ワイルドカードが設定されて いたことを示す。RRSIG の RDATA には所有者名のラベル数が保持される([RFC4034] セクション3.1.3)が、その値は2となる(上図にその記載はない)。しかし、応答に 含まれるRRSIGの所有者名のラベル数は3である。この不一致により、ワイルドカード "*.example.org" の設定が存在したことを提示する。 鋭敏な読者には、"z.example.org" RRSIG(TXT) がデータとしてあらかじめ 登録されたものではなく、応答時にその場で生成されたもののように見えるかも しれない。その解釈は正しくない。"z.example.org" に対する署名は 存在しない。この署名は、存在する "*.example.org" に関連づけられたもので、 所有者名だけが "z.example.org" に変更されたものである。従って、 ワイルドカード処理を経ているとしても、その場で署名が生成された わけではない。 DNSSEC標準は、この種の応答にNSEC(またはNSEC3)を付加することを要求している。 それを行わないと、攻撃者は再生攻撃をを行い、偽造データでキャッシュを汚染 できてしまう。例として、リゾルバーが "a.example.org TXT" を問い合わせた場合を 考える。攻撃者は、たとえ "a.example.org TXT" に一致するレコードが存在 している状況においても、応答がワイルドカード展開を経て生成されたように 見せかけて、当該レコードが存在しないように偽造できてしまう。 Gieben & Mekking Informational [Page 16] RFC 7129 Authenticated Denial in DNS February 2014 具体的に、回答部を以下のように調整する程度の微修正で済む。 ;; status: NOERROR, id: 31827 ;; ANSWER SECTION: a.example.org. TXT "wildcard record" a.example.org. RRSIG(TXT) ( ... ) 図6: ワイルドカード展開を経ていない偽造応答 図5に示した所有者名との違いはわずかであることに注意。この応答には、 "a.example.org TXT" の内容が示されているが、ゾーン内には当該レコードに 対する別のRDATAが存在する (図4参照)。 "Wildcard Answer(ワイルドカード展開後一致)"応答にNSECまたはNSEC3を付加 することが要求されないのであれば、先の偽造された回答は完全に有効なもの となる。リゾルバーは "a.example.org TXT" がワイルドカード展開して得られた と信じ込み、実在するレコードは隠ぺいされてしまう。これは悪しき振る舞いで、 DNSSECが提供するセキュリティを無力化するものである。以上の理由により、 NSECまたはNSEC3が応答に存在しなければならない。 別の言い方で説明すると、DNSSECは、ネームサーバーがゾーン内の名前検索時に、 [RFC1034]セクション4.3.2記載の処理手順に従ったことをリゾルバーが確認する 手段を提供する。処理手順の一部(3c)に、ワイルドカード検索の処理が明記されて いる。DNSSECが有効な場合、その内容をリゾルバーに通知しなければならない。 (訳注: "*"ラベルが存在する/しない等)。従って、NSECまたはNSEC3が 必要になる。 Gieben & Mekking Informational [Page 17] RFC 7129 Authenticated Denial in DNS February 2014 5.4. CNAMEレコードとワイルドカード ここまで、応答が保持するNSECレコード数は最大2個であった。一つは不在証明用 で、もう一つがワイルドカード用である。"最大"と表記してきた理由は、単一の NSECで両方を証明できる場合があるためである。NSEC3の場合、最大3個になる。 (その理由については次セクションで説明する)。 ワイルドカードに関連づけられたCNAMEレコード(以下"CNAMEワイルドカード") を考慮すると、より多くのNSECまたはNSEC3レコードが必要になる。個々のワイルド カード展開について、そのワイルドカード展開は正当な処理であったことを 証明する必要があるからである。例示ゾーンに幾つかのCNAMEワイルドカードを 追加したものを以下に示す。 example.org. SOA ( ... ) example.org. NS a.example.org. *.example.org. TXT "wildcard record" a.example.org. A 192.0.2.1 TXT "a record" *.a.example.org. CNAME w.b *.b.example.org. CNAME w.c *.c.example.org. A 192.0.2.1 d.example.org. A 192.0.2.1 TXT "d record" w.example.org. CNAME w.a 図7: CNAMEワイルドカードの連鎖を追加した "example.org" ゾーン Gieben & Mekking Informational [Page 18] RFC 7129 Authenticated Denial in DNS February 2014 "w.example.org A" への問い合わせには以下の応答が返される。 ;; status: NOERROR, id: 4307 ;; ANSWER SECTION: w.example.org. CNAME w.a.example.org. w.example.org. RRSIG(CNAME) ( ... ) w.a.example.org. CNAME w.b.example.org. w.a.example.org. RRSIG(CNAME) ( ... ) w.b.example.org. CNAME w.c.example.org. w.b.example.org. RRSIG(CNAME) ( ... ) w.c.example.org. A 192.0.2.1 w.c.example.org. RRSIG(A) ( ... ) ;; AUTHORITY SECTION: *.a.example.org. NSEC *.b.example.org. CNAME RRSIG NSEC *.a.example.org. RRSIG(NSEC) ( ... ) *.b.example.org. NSEC *.c.example.org. CNAME RRSIG NSEC *.b.example.org. RRSIG(NSEC) ( ... ) *.c.example.org. NSEC d.example.org. A RRSIG NSEC *.c.example.org. RRSIG(NSEC) ( ... ) "*.a.example.org" のNSECレコードは、ワイルドカード展開して "w.a.example.org" を生成したことは適切だったことを証明する。"w.a." は "*.a" と "*.b" の すき間にある(つまり"w.a."に完全一致するものは存在しなかった)ことを明らかに するからである。同様に、"*.b.example.org" のNSECレコードは、 "w.b.example.org" と完全一致する名前は存在しないことを証明し、 "*.c.example.org" のNSECレコードは "w.c.example.org" と完全一致する名前が 存在しないことを証明する。 DNAMEレコードについては、[RFC6672]セクション3.3で繰り返し述べられている ように、 ワイルドカード名に対してDNAMEレコードを設定すべきではない。 5.5. 最近接名とNSEC3レコード これまでに、問い合わせ名の存在を否定する一つ以上のNSEC3レコードと、 ワイルドカード合成を否定するNSEC3レコードを紹介してきた。何か見落としは あっただろうか? 簡単に言ってしまえば、NSEC3で行われるハッシュ処理のためゾーンの深さが 失われ、すべての名前はフラットな平面上に配置される。この失われた情報を 補完するため、追加のレコードが必要になる。 Gieben & Mekking Informational [Page 19] RFC 7129 Authenticated Denial in DNS February 2014 NSEC3を理解するため、二つの定義を必要とする。 最近接名: [RFC4592]で導入された概念。以下のように定義される。 最近接名は、ゾーン内に存在するドメイン名の木構造のノード(節点)で、 問い合わせ名に対して(ルートから下方向に)最も多くのラベルが一致したもの を指す。 例示ゾーンの場合、問い合わせ名が "x.2.example.org" であれば、最近接名は "example.org" になる。 次近接名(next closer name): [RFC5155]で導入された概念。最近接名に一つ以上の ラベルを左に付加したもの。問い合わせ名 "x.2.example.org" の最近接名が "example.org" の場合、次近接名は "2.example.org" になる。 "最近接名の証拠(closest encloser proof)"となるNSEC3は以下の構成になる。 1. 最近接名と "一致" するNSEC3レコード。これは、ハッシュ化前のオリジナル 所有者名が最近接名であることを意味する。この情報は、次のように リゾルバーに通知される: "あなたが問い合わせた名前は存在しません。私が 保持するデータの中で最も近い名前はこれです"。 2. 次近接名を "カバー" するNSEC3レコード。このNSEC3レコードは、次近接名 のハッシュ化所有者名がハッシュ整列順でそこに存在するはずのすき間を定義 する。この情報は、次のようにリゾルバーに通知される: "次近接名はこのすき間 にあるはずですがありません。ですからあなたの問い合わせた名前は存在 しません。事実として、私が保持するデータの中で最も問い合わせ名に近い 名前は、紛れもなく最近接名です"。 上に挙げた二つのNSEC3レコードは、既に問い合わせ名の存在を否定しているので、 問い合わせ名それ自体をカバーするNSEC3レコードは不要である。次近接名の存在を 否定することで、問い合わせ名の存在も否定しているからである。 NSECを使用する場合、二つの名前の間に存在するすべてのEmpty Non-terminalの存在が 否定されるので、問い合わせ名の存在を否定するNSECレコードの中に暗黙のうちに 最近接名が含まれることに注意。 どのような問い合わせ名に対しても、ワイルドカード展開が可能な場所は1カ所 しかない。これを "合成源(source of synthesis)" と呼び、([RFC4592]セクション 2.1.1及び3.3.1で)以下のように定義される。 <アスタリスクラベル>.<最近接名> 言い換えると、応答がワイルドカード合成の結果であることを否定するために、 リゾルバーは合成源のハッシュ値を知る必要がある。問い合わせ名の最近接名は 前もってわからないので、回答で提供されなければならない。 Gieben & Mekking Informational [Page 20] RFC 7129 Authenticated Denial in DNS February 2014 以下の例で説明する。二つのTXTレコードを持つゾーンを考える。ゾーンに追加 されたレコードは "1.h.example.org" と "3.3.example.org" である。NSEC3を 使用し、署名を行うものとするが、以下に示すものは未署名のゾーンである。 example.org. SOA ( ... ) example.org. NS a.example.org. 1.h.example.org. TXT "1.h record" 3.3.example.org. TXT "3.3 record" 図8: TXTレコードを保持する "example.org" ゾーン。これらのTXTレコードは、 次に示す二つのEmpty Non-terminalを生成する: h.example.org, 3.example.org リゾルバーが "x.2.example.org TXT" を問い合わせると、サーバーは NXDOMAIN 応答 を返すが、この応答には三つのNSEC3レコードが含まれる。ハッシュ化所有者名と オリジナル所有者名の対応表は付録Cを参照のこと。また、図9の中に記載されて いる番号((1)~(3))は、以下のNSEC3レコードに対応する。 15bg9l6359f5ch23e34ddua6n1rihl9h.example.org. ( NSEC3 1 0 2 DEAD 1AVVQN74SG75UKFVF25DGCETHGQ638EK NS SOA RRSIG DNSKEY NSEC3PARAM ) 1avvqn74sg75ukfvf25dgcethgq638ek.example.org. ( NSEC3 1 0 2 DEAD 75B9ID679QQOV6LDFHD8OCSHSSSB6JVQ ) 75b9id679qqov6ldfhd8ocshsssb6jvq.example.org. ( NSEC3 1 0 2 DEAD 8555T7QEGAU7PJTKSNBCHG4TD2M0JNPJ TXT RRSIG ) NSECのアプローチに従うのであれば、リゾルバーは次に示す一事にだけ関心を持てば よい。"x.2.example.org" のハッシュは、応答のNSEC3レコードが指定するすき間に 位置するだろうか? Gieben & Mekking Informational [Page 21] RFC 7129 Authenticated Denial in DNS February 2014 example.org ** +-- ** . . . . . . . . . . . (1) / . ^ . . / . | . . | . | . . v . | . . ** | (2) ** ++ h.example.org ** ----+----> ** 3.example.org ++ 2.example.org . / . | . . / (5) . | (3) . . / . | . . / . v . 1.h.example.org ** ** ++ ** <--------- ** 3.3.example.org ++ x.2.example.org (4) 図9: "x.2.example.org" は存在しない。5本の矢印はNSEC3レコードを表現する。 (1),(2),(3)は回答で返されるNSEC3である。"2.example.org" は(3)に カバーされる。また "x.2.example.org" は(4)にカバーされるので 回答には含まれない。 "x.2.example.org" のハッシュは "ndtu6dste50pr4a1f2qvr1v31g00i2i1" である。 このハッシュが一つめのNSEC3が提示するすき間、 "15bg9l6359f5ch23e34ddua6n1rihl9h"(example.org) と "1avvqn74sg75ukfvf25dgcethgq638ek"(h.example.org) に存在するかを検査すると、存在しないことがわかる。二つめのNSEC3が提示する すき間 "1avvqn74sg75ukfvf25dgcethgq638ek"(h.example.org) "75b9id679qqov6ldfhd8ocshsssb6jvq"(3.example.org) にも存在しないことがわかる。三つめのNSEC3が提示するすき間 "75b9id679qqov6ldfhd8ocshsssb6jvq"(3.example.org) "8555t7qegau7pjtksnbchg4td2m0jnpj"(3.3.example.org) も同様の結果となる。 リゾルバーはどう処理すべきだろうか?NSEC3は上限の三つが提供されたが、 そのすべてが役に立たないように見える。 ここで最近接名の証拠が登場する。まず、最近接名の証拠が機能するために、 リゾルバーは最近接名が何かを知る必要がある。最近接名は、ゾーン内に存在する 問い合わせ名の先祖(訳注:親、親の親等)でなければならない。つまり、問い合わせ名 よりも短い名前のはずである。リゾルバーは、問い合わせ名を段階的に短くしながら 名前のハッシュを計算していき、NSEC3の所有者名と一致するまで繰り返す。 最後に一致した所有者名が最近接名である。 リゾルバーは最近接名を発見すると、次の処理として次近接名を構築する。 次近接名は、最近接名を得るために問い合わせ名から最後に取り除いたラベルを戻す (前に付加する)ことで構築される。構文にすると次のようになる。 "<最後に取り除いたラベル>.<最近接名>"。次近接名のハッシュは、応答に含まれる NSEC3レコードが指定するどこかのすき間でカバーされるべきである。 Gieben & Mekking Informational [Page 22] RFC 7129 Authenticated Denial in DNS February 2014 その後、リゾルバーはワイルドカードが存在したかを検査しなければならない。 リゾルバーは、最近接名にアスタリスクラベルを前に付加し、"*.<最近接名>" を 生成してハッシュを計算する。 先に示した例で説明する。初めに、リゾルバーは最近接名に一致するNSEC3を発見 しなければならない。これは、問い合わせ名のラベルを先頭から取り除いていき、 得られた名前のハッシュを(問い合わせたゾーンで指定された繰り返し回数で) 計算し、応答と比較することで達成される。従って、以下に示すような ハッシュ処理と、NSEC3との比較が行われる。 x.2.example.org: "ndtu6dste50pr4a1f2qvr1v31g00i2i1" 最後に取り除かれたラベル: "<(空)>" 2.example.org: "7t70drg4ekc28v93q7gnbleopa7vlp6q" 最後に取り除かれたラベル: "x" example.org: "15bg9l6359f5ch23e34ddua6n1rihl9h" 最後に取り除かれたラベル: "2" 計算されたハッシュの中で、NSEC3レコードの所有者名と一致するのは次の一つ だけである: "15bg9l6359f5ch23e34ddua6n1rihl9h"。これを最近接名と判断する。 (オリジナル所有者名 "example.org")。これが(1)のNSEC3レコードの主たる目的 である。リゾルバーに最近接名を通知するのである。 Opt-Outを使用する場合、QNAMEに対する本当の最近接名はNSEC3レコードを 持たない可能性がある。その場合、証明可能な最近接名(closest provable encloser)を使用する。これは、NSEC3レコードを持つ最近接の正式名である。 最悪の場合、証明可能な最近接名はゾーン頂点のNSEC3レコードになる。 ゾーン頂点名は必ずNSEC3レコードを持つからである。 (証明可能な)最近接名を使用して、リゾルバーは次近接名を構築する。例の場合、 次近接名は "2.example.org" となる。"example.org" が最近接名で、最後に 取り除かれたラベルが "2" だからである。この名前のハッシュは、他のNSEC3の どれかによってカバーされるべきである。"2.example.org" のハッシュは "7t70drg4ekc28v93q7gnbleopa7vlp6q" となるので、 "75b9id679qqov6ldfhd8ocshsssb6jvq" と "8555t7qegau7pjtksnbchg4td2m0jnpj" の すき間に位置する。(この情報を提供するのが(3)のNSEC3の役割である)。 リゾルバーはこの情報から何が得られるだろうか? ・ "example.org" は存在する。 ・ "2.example.org" は存在しない。 また、"2.example.org" が存在しないのであれば、"x.2.example.org" に 直接一致する名前も存在しない。最後の処理は、合成源の存在を否定することで、 ワイルドカード展開はできなかったことを証明することである。 Gieben & Mekking Informational [Page 23] RFC 7129 Authenticated Denial in DNS February 2014 リゾルバーは "*.example.org" をハッシュして "22670trplhsr72pqqmedltg1kdqeolb7" を生成し、これが応答に含まれるNSEC3にカバーされているかを検査する。 例の場合、ハッシュは "1avvqn74sg75ukfvf25dgcethgq638ek" と "75b9id679qqov6ldfhd8ocshsssb6jvq" に位置するので、これまで参照されていない 最後のNSEC3 (2) でカバーされる(図9参照)。この意味は、最近接名の直下に ワイルドカードレコードは存在しないので、"x.2.example.org" は間違いなく 存在しないということである。 最後に署名を検証すれば、ゴール、すなわち不在証明が達成される。 5.6. NSEC3レコードが三つ必要な理由 ワイルドカードレコードの存在を否定するために、NSEC3レコード一つと対応する 署名を追加するのは過剰に思えるかもしれない。しかし、これを取り除くことは できない。最近接名を提示するNSEC3付加を仕様で必須とせず、二つのNSEC3レコード (問い合わせ名を否定するものとワイルドカードを否定するもの)だけを要件に すると、攻撃者は合成源が存在するのに存在していないとリゾルバーを偽ることが できてしまう。 先の例で、ワイルドカードが存在する状況を考える。その場合、未署名のゾーンは 以下のようになる。 example.org. SOA ( ... ) example.org. NS a.example.org. *.example.org. TXT "wildcard record" 1.h.example.org. TXT "1.h record" 3.3.example.org. TXT "3.3 record" "x.2.example.org TXT" への問い合わせには、以下のような回答が返される べきである。 x.2.example.org. TXT "wildcard record" 攻撃者は、ワイルドカード名 "*.2.example.org" のハッシュを計算し、 そのハッシュをカバーするNSEC3レコードを見つけることで、このワイルド カード展開を否定することができる。まず、"*.2.example.org" のハッシュは "fbq73bfkjlrkdoqs27k5qf81aqqd7hho" である。次に、ゾーン内でこのハッシュ化 所有者名をカバーするNSEC3を探す。"3.3" がカバーすることがわかる。 8555t7qegau7pjtksnbchg4td2m0jnpj.example.org. ( NSEC3 1 0 2 DEAD 15BG9L6359F5CH23E34DDUA6N1RIHL9H TXT RRSIG ) このNSEC3レコードは問い合わせ名 "x.2.example.org" (ハッシュは "ndtu6dste50pr4a1f2qvr1v31g00i2i1")もカバーしている。 Gieben & Mekking Informational [Page 24] RFC 7129 Authenticated Denial in DNS February 2014 攻撃者は、このNSEC3レコードを権威セクションに追加(再生)することで、 "x.2.example.org" 及びあらゆるワイルドカード展開を否定する再生攻撃を 行える。その結果、リゾルバーは "x.2.example.org" はワイルドカード展開を経て 合成されるべきものであるにも拘わらず、存在しないと判定してしまう。 最近接名 "example.org" に一致するNSEC3があるので、リゾルバーはワイルド カード展開は "*.example.org" かどこか他の場所でしか生じないと信じこむ。 はじめの質問に戻ってみよう。問い合わせ名の存在を否定するために、最大三つの NSEC3レコードが必要な理由は何だろうか?リゾルバーは、"最近接名" を明示的に 通知される必要がある。これを実現するために、NSEC3レコードを一つ消費する。 次に、次近接名はNSEC3にカバーされる必要がある。これで二つ。最後に、NSEC3を 使用して、ワイルドカード展開が可能であったかどうかを通知しなければならない。 以上のように、NSEC3は三つ揃って始めて目的を達成するのである。 6. セキュリティに関する考慮点 DNSSECはサービス不能攻撃を防御せず、またデータの秘匿性も提供しない。 DNSSECに関するより一般的な考察については [RFC4033]、[RFC4034]、[RFC4035]、 [RFC5155] を参照のこと。 これらのRFCは、不在証明の設計で、ある種の選択がなされた理由を簡潔にしか 記していない。DNSSECのこの側面を正しく扱わない実装は、DNSSECが付加する セキュリティ機能にセキュリティホールを生じさせる。これは、Secureな委任 で特に厄介な問題になる。攻撃者が DS(Delegation Signer)の存在を否定 できると、リゾルバーは信頼の連鎖を構築できないので、リゾルバーは以後の 名前解決処理をDNSSEC無効な(insecure)DNSにフォールバックして実行 しなければならない。 本文書は、この "文書に記載された内容と記載されなかった側面のギャップ" を 埋め、未来の実装者や他の関係者に充分な背景情報を提供することで、不在証明の より良い理解の一助となることを意図している。 7. Acknowledgments This document would not be possible without the help of Ed Lewis, Roy Arends, Wouter Wijngaards, Olaf Kolkman, Carsten Strotmann, Jan-Piet Mens, Peter van Dijk, Marco Davids, Esther Makaay, Antoin Verschuren, Lukas Wunner, Joe Abley, Ralf Weber, Geoff Huston, Dave Lawrence, Tony Finch, and Mark Andrews. Also valuable was the source code of Unbound ("validator/val_nsec3.c") [Unbound]. Extensive feedback for early versions of this document was received from Karst Koymans. Gieben & Mekking Informational [Page 25] RFC 7129 Authenticated Denial in DNS February 2014 8. References 8.1. Normative References [RFC1034] Mockapetris, P., "Domain names - concepts and facilities", STD 13, RFC 1034, November 1987. [RFC2065] Eastlake, D. and C. Kaufman, "Domain Name System Security Extensions", RFC 2065, January 1997. [RFC2308] Andrews, M., "Negative Caching of DNS Queries (DNS NCACHE)", RFC 2308, March 1998. [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. [RFC4592] Lewis, E., "The Role of Wildcards in the Domain Name System", RFC 4592, July 2006. [RFC4648] Josefsson, S., "The Base16, Base32, and Base64 Data Encodings", RFC 4648, October 2006. [RFC5155] Laurie, B., Sisson, G., Arends, R., and D. Blacka, "DNS Security (DNSSEC) Hashed Authenticated Denial of Existence", RFC 5155, March 2008. [RFC6672] Rose, S. and W. Wijngaards, "DNAME Redirection in the DNS", RFC 6672, June 2012. 8.2. Informative References [DNSEXT-NSEC2] Laurie, B., "DNSSEC NSEC2 Owner and RDATA Format", Work in Progress, October 2004. [DNSEXT] Josefsson, S., "Authenticating denial of existence in DNS with minimum disclosure", Work in Progress, November 2000. Gieben & Mekking Informational [Page 26] RFC 7129 Authenticated Denial in DNS February 2014 [DNSNR-RR] Arends, R., "DNSSEC Non-Repudiation Resource Record", Work in Progress, June 2004. [Err3441] RFC Errata, Errata ID 3441, RFC 5155, . [RFC2535] Eastlake, D., "Domain Name System Security Extensions", RFC 2535, March 1999. [RFC3655] Wellington, B. and O. Gudmundsson, "Redefinition of DNS Authenticated Data (AD) bit", RFC 3655, November 2003. [RFC3755] Weiler, S., "Legacy Resolver Compatibility for Delegation Signer (DS)", RFC 3755, May 2004. [RFC4470] Weiler, S. and J. Ihren, "Minimally Covering NSEC Records and DNSSEC On-line Signing", RFC 4470, April 2006. [RFC4956] Arends, R., Kosters, M., and D. Blacka, "DNS Security (DNSSEC) Opt-In", RFC 4956, July 2007. [Unbound] NLnet Labs, "Unbound: a validating, recursive, and caching DNS resolver", 2006, . [phreebird] Kaminsky, D., "Phreebird: a DNSSEC proxy", January 2011, . Gieben & Mekking Informational [Page 27] RFC 7129 Authenticated Denial in DNS February 2014 付録 A. オンライン署名方式: 最小限にカバーするNSECレコード NSECレコードは、ゾーン内に存在する次の名前を列挙するので、ゾーン内の 名前すべての取得を容易にしている。これはNSEC3でも同様だが、敵対者は ハッシュ化した名前しか取得できない。DNSSECオンライン署名方式を使用すると、 次所有者名を偽装することでゾーンウォーキングを抑制することができる。 NSECによる次所有者名の取得を抑制するために、次所有者名とは異なる、存在 しない名前([RFC4592]セクション2.2記載の"名前が存在する"の定義に従う)を 使用する。しかし、どのような名前でも使用できるわけではない。バリデータは NSECレコードがカバーするすき間の大きさから何か推測を行うかもしれないから である。そのすき間は、QNAMEをカバーする程度に充分大きくなければならないが、 既存の名前をカバーしてしまうほど大きすぎてもいけない。 [RFC4470]は、最小限にカバーするNSECレコード生成法を導入した。このNSEC レコードが使用する次所有者名は、実在の次所有者名よりも辞書的にNSEC所有者名 に近く、また実在する名前をカバーしないことが保証される名前である。 この特殊な次所有者名は、QNAMEから所謂イプシロン関数を使用して導出される。 例として、セクション3.2に示した例示ゾーンにおいて、"b.example.org" の 存在を否定する場合、以下のNSECレコードが生成される。 a.example.org. NSEC c.example.org. RRSIG NSEC このNSECレコードは、"b.example.org" が存在しないことを証明するが、敵対者が ゾーンウォーキング攻撃で次所有者名の取得を行うことは"できない"。タイプビット マップはRRSIGとNSECのビットだけが設定されることに注意。その理由は [RFC4470] に以下の記述があるからである。 生成されたNSECレコードのタイプビットマップには、RRSIGとNSECのビットを 設定しなければならない(MUST)。また他のビットは設定すべきではない (SHOULD NOT)。 これは、(RFC 4035では禁止されていた)ゾーン署名前に存在しなかった名前に 対してNSECレコードを生成できるように、仕様を緩和するためのものである。 しかし、今回の例では "a.example.org" は署名時に存在しており、他のRRタイプも 保持している。従って、AとTXTのビットマップを設定することはできる (すべきではないが)。 DNSにおける名前の順序づけは非常に厳密なので、生成されるすき間は最小に すべきである。これを実現するため、NSECの所有者名は、QNAMEの左端のラベルを デクリメント(ラベルの最後の文字の文字コードをデクリメントする)し、その ラベルのラベル長が最大値の63オクテットになるまでオクテット値255で 埋め尽くしたものにする。また、次所有者名は、QNAMEの先頭ラベルの前に 単一のヌルオクテットを付加したものにする。この規則を適用すると、 "b.example.org" を最小限にカバーするNSECレコードは以下の通りとなる。 Gieben & Mekking Informational [Page 28] RFC 7129 Authenticated Denial in DNS February 2014 a\255\255\255\255\255\255\255\255\255\255\255\255\255\255\255\255\255 \255\255\255\255\255\255\255\255\255\255\255\255\255\255\255\255\255 \255\255\255\255\255\255\255\255\255\255\255\255\255\255\255\255\255 \255\255\255\255\255\255\255\255\255\255\255.example.org. ( NSEC \000.b.example.org. RRSIG NSEC ) 付録 B. オンライン署名方式: 方便的NSEC3 最小限にカバーするすき間によって不在証明行うという考え方をNSEC3にも 適用可能である。この仕組みには、Phreebird [phreebird] 実装時に "方便的NSEC3(NSEC3 White Lies)" というニックネームがつけられている。 この方法は、NSEC3の所有者名にQNAMEのハッシュ値-1を使用し、次所有者名に QNAMEのハッシュ値+1を使用するというものである。 以下の方便的NSEC3は、"b.example.org" の存在を否定する(この名前の ハッシュは "iuu8l5lmt76jeltp0bir3tmg4u3uu8e7" である)。 iuu8l5lmt76jeltp0bir3tmg4u3uu8e6.example.org. ( NSEC3 1 0 2 DEAD IUU815LMT76JELTP0BIR3TMG4U3UU8E8 ) この場合、タイプビットマップは空になる。ただし、"b.example.org" の ハッシュ値-1が存在する名前のハッシュ値と衝突する場合、ビットマップには 衝突する名前が保持するRRタイプの値を設定すべきである。このレコードは、 実質的に次近接名(好都合なことに "b.example.org" である)の存在を 否定する。当然だが、最近接名に一致するNSEC3レコードと、ワイルドカード展開を 否定するNSEC3レコードは依然として必要である。これらのレコードは以下のように なる。 # 最近接名 "example.org" (15bg9l6359f5ch23e34ddua6n1rihl9h) に一致 15bg9l6359f5ch23e34ddua6n1rihl9h.example.org. ( NSEC3 1 0 2 DEAD 15BG9L6359F5CH23E34DDUA6N1RIHL9I NS SOA RRSIG DNSKEY NSEC3PARAM ) # "*.example.org" (22670trplhsr72pqqmedltg1kdqeolb7)をカバーして # ワイルドカード展開を否定 22670trplhsr72pqqmedltg1kdqeolb6.example.org.( NSEC3 1 0 2 DEAD 22670TRPLHSR72PQQMEDLTG1KDQEOLB8 ) 付録 C. ハッシュ化所有者名とオリジナル所有者名の対応表 以下に、本文書で使用する所有者名とハッシュ化所有者名と対応表を示す。 これらの名前の起点は "example.org" である。 Gieben & Mekking Informational [Page 29] RFC 7129 Authenticated Denial in DNS February 2014 +----------------+-------------------------------------+ | オリジナル名 | ハッシュ化名 | +----------------+-------------------------------------+ | "a" | "04sknapca5al7qos3km2l9tl3p5okq4c" | | "1.h" | "117gercprcjgg8j04ev1ndrk8d1jt14k" | | "@" | "15bg9l6359f5ch23e34ddua6n1rihl9h" | | "h" | "1avvqn74sg75ukfvf25dgcethgq638ek" | | "*" | "22670trplhsr72pqqmedltg1kdqeolb7" | | "3" | "75b9id679qqov6ldfhd8ocshsssb6jvq" | | "2" | "7t70drg4ekc28v93q7gnbleopa7vlp6q" | | "3.3" | "8555t7qegau7pjtksnbchg4td2m0jnpj" | | "d" | "a6edkb6v8vl5ol8jnqqlt74qmj7heb84" | | "*.2" | "fbq73bfkjlrkdoqs27k5qf81aqqd7hho" | | "b" | "iuu8l5lmt76jeltp0bir3tmg4u3uu8e7" | | "x.2" | "ndtu6dste50pr4a1f2qvr1v31g00i2i1" | +----------------+-------------------------------------+ 表 1: ハッシュ整列順に列挙された "example.org" のハッシュ化所有者名 Authors' Addresses R. (Miek) Gieben Google EMail: miek@google.com W. (Matthijs) Mekking NLnet Labs Science Park 400 Amsterdam 1098 XH NL EMail: matthijs@nlnetlabs.nl URI: http://www.nlnetlabs.nl/ Gieben & Mekking Informational [Page 30]