Internet Engineering Task Force (IETF) K. Fujiwara RFC: 8198 JPRS 更新(Updates): 4035 A. Kato 分類: 標準化過程 Keio/WIDE ISSN: 2070-1721 W. Kumari Google 2017年7月 DNSSEC署名検証済みキャッシュの積極的使用 要旨 DNSのスケールはキャッシュ利用に依存する。しかし、キャッシュの検索は、 一般に完全一致を必要とする。本文書は、DNSSEC署名を検証するリゾルバー (DNSSEC-validating resolver)が所定の範囲内にある名前のネガティブ応答 を生成したり、ワイルドカードから肯定応答を生成したりできるようにする ためのNSEC/NSEC3リソースレコードの使用法を規定する。この新しい規定は パフォーマンスを向上させ、応答遅延を減少させ、権威サーバーと再帰 サーバーの両方でリソース使用率を低下させ、プライバシーを向上させる。 また、一部の状況において特定のDoS攻撃に対する耐性を高める一助とも なる。 本文書は、署名を検証するリゾルバーがNSEC/NSEC3レコードに基づいて ネガティブ応答を生成すること及びワイルドカードの存在を利用して 肯定応答を生成することを可能にする。この二点により、本文書は RFC 4035を更新する。 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 7841. 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/rfc8198. Fujiwara, et al. Standards Track [Page 1] RFC 8198 NSEC/NSEC3 Usage July 2017 Copyright Notice Copyright (c) 2017 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. 目次 1. はじめに . . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. 用語 . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3 3. 問題提起 . . . . . . . . . . . . . . . . . . . . . . . . . . 3 4. 背景 . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 5. DNSSEC署名検証済みキャッシュの積極的使用 . . . . . . . . . . 6 5.1. NSEC . . . . . . . . . . . . . . . . . . . . . . . . . . 6 5.2. NSEC3 . . . . . . . . . . . . . . . . . . . . . . . . . . 6 5.3. ワイルドカード . . . . . . . . . . . . . . . . . . . . . 6 5.4. TTLに関する考慮点 . . . . . . . . . . . . . . . . . . . . 7 6. 本手法の利点 . . . . . . . . . . . . . . . . . . . . . . . . 7 7. RFC 4035の更新 . . . . . . . . . . . . . . . . . . . . . . . 7 8. IANAに関する考慮点 . . . . . . . . . . . . . . . . . . . . . 9 9. セキュリティに関する考慮点 . . . . . . . . . . . . . . . . . 9 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 9 10.1. Normative References . . . . . . . . . . . . . . . . . . 9 10.2. Informative References . . . . . . . . . . . . . . . . . 10 付録 A. 実装に関する詳細な注記 . . . . . . . . . . . . . . . 11 付録 B. NSEC使用時の判定手順: ENTかNXDOMAINか . . . . . . . 11 Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 12 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 13 Fujiwara, et al. Standards Track [Page 2] RFC 8198 NSEC/NSEC3 Usage July 2017 1. はじめに DNSにはネガティブキャッシュがあり、RRsetが存在しないという事実を キャッシュするために使用される。ネガティブキャッシュ利用は、完全一致 を必要とする。この仕様は、不必要な追加の検索を生じさせ、応答遅延を 増大させ、権威サーバーと再帰サーバー両方における余分なリソース使用を 引き起こし、問い合わせ漏洩によってプライバシーを低下させる。 本文書は、リゾルバーがキャッシュとして保持する情報からネガティブ応答 を合成するにあたってNSEC/NSEC3レコードを使用できるようにするため、 RFC 4035を更新する。これにより、以前にキャッシュされたNSEC/NSEC3 リソースレコードで表現される範囲内に問い合わされた名前があれば、署名を 検証するリゾルバーは直ちにネガティブ応答を返せるようになる。また、 ワイルドカードの存在を利用して肯定応答を合成できるようにもなる。 積極的なネガティブキャッシュ利用は、問い合わされた名前をカバーする NSECレコードを効率的に見つけるために、DNSSEC Lookaside Validation (DLV)[RFC5074]のセクション6で初めて提案された。 [RFC8020]と[RES-IMPROVE]は、NXDOMAIN情報を使用してより効率的な キャッシュ利用を行うための手順を提案している。本文書は、この 手法を更に活用する。 2. 用語 本文書におけるキーワード"しなければならない(MUST)"、"してはならない (MUST NOT)"、"要求される(REQUIRED)"、"するものとする(SHALL)"、"しない ものとする(SHALL NOT)"、"すべきである(SHOULD)"、"すべきでない(SHOULD NOT)"、"推奨される(RECOMMENDED)"、"してもよい/することができる(MAY)"、 "任意である(OPTIONAL)"等は、ここに示されるようにすべて大文字で表記 されている場合に限り、BCP 14[RFC2119][RFC8174]の記述どおりに解釈 されるものとする。 本文書で使用される専門用語の多くは、"DNSの用語"[RFC7719]で定義 されている。 本文書におけるキーワード"合成源(source of synthesis)"は、[RFC4592]の 記述どおりに解釈されるものとする。 3. 問題提起 DNSのネガティブキャッシュはネガティブな(不在)情報をキャッシュし、 ほとんどの場合完全一致を必要とする[RFC2308]。 (DNSSECで署名された)"example.com"ゾーンが以下を含むものとする。 albatross.example.com. IN A 192.0.2.1 elephant.example.com. IN A 192.0.2.2 zebra.example.com. IN A 192.0.2.3 Fujiwara, et al. Standards Track [Page 3] RFC 8198 NSEC/NSEC3 Usage July 2017 署名を検証するリゾルバーがcat.example.comへの問い合わせを受信すると、 自身が使用するリゾルバー(恐らく自分自身だろう)にコンタクトして example.comのサーバーに問い合わせを行い、(アルファベット順で)albatross とelephantの間にはレコードが存在しないことを提示するNSECレコードか、 または二つのハッシュ化された名前の間には何も存在しないことを提示する NSEC3レコードを取得する。その結果、リゾルバーはcat.example.comが存在 しないことを認識するが、(albatrossからelephantまでの)範囲をカバー する不在証明があるという事実を使用して、同じ範囲内にある他のラベル への問い合わせを抑制しようとはしない。これは、その署名を検証する リゾルバーがball.example.com(またはdog.example.com)への問い合わせを 受信すると、もう一度先の手順を開始し、example.comのサーバーにそれらの 名前を問い合わせることを意味する。 この振る舞いは、帯域を無駄にするだけではなく、再帰サーバーのリソース を無駄にし(未完了の問い合わせの状態を保持する必要があるため)、権威 サーバーのリソースを無駄にし(追加の問い合わせに回答する必要があるため)、 応答遅延を増加させ(エンドユーザーはNXDOMAINの回答を取得するために 必要以上に待たなければならない)、DoSを引き起こすために攻撃者によって 利用される可能性がある。また、プライバシーへの影響も存在する(例えば タイプミスによる必要以上の漏洩)。 別の例として、(DNSSECで署名された)"example.org"ゾーンが以下を含む ものとする。 avocado.example.org. IN A 192.0.2.1 *.example.org. IN A 192.0.2.2 zucchini.example.org. IN A 192.0.2.3 leek.example.orgへの問い合わせが受信されると、システムは自身が使用する リゾルバー(恐らく自分自身だろう)にコンタクトしてexample.orgのサーバー に問い合わせを行い、(アルファベット順で)avocadoとzucchiniの間にはレコード が存在しないことを提示するNSECレコード(か、二つのハッシュ化された名前の 間には何も存在しないことを提示するNSEC3レコード)を取得する。あわせて、 所有者名のラベル数が2に設定された署名を含むleek.example.orgへの回答も 取得する(詳細については[RFC7129]のセクション5.3を参照せよ)。 署名を検証するリゾルバーがbanana.example.orgへの問い合わせを受信した 場合、(たとえリゾルバーが既にワイルドカードが存在する証拠を得ていても) もう一度先の手順を開始し、example.orgのサーバーにbanana.example.orgを 問い合わせる。先の例と同様に、この振る舞いにはプライバシーへの影響が存在 し、リソースを浪費させ、DoSの一因となる可能性がある。 4. 背景 DNSSEC[RFC4035]と[RFC5155]は、どちらも"不在証明(authenticated denial of existence)"を提供する。これは、問い合わされた名前が存在しないまたは タイプが存在しないことに関する暗号に基づく証明である。名前が存在しない という証明は、問い合わされた名前に対してアルファベット順で前と後に現れる 名前を含む(DNSSECで保護された)レコードを提供することで達成される。 Fujiwara, et al. Standards Track [Page 4] RFC 8198 NSEC/NSEC3 Usage July 2017 先の一つめの例では、(DNSSEC署名を検証する)再帰サーバーがdog.example.com を問い合わせると、"albatross"と"elephant"の間にはラベルが存在しないことを 提示する(署名された)NSECレコード(か、NSEC3の場合はハッシュ化された 名前のペアに関する同様の情報)を受信する。これが、これらの名前は問い合わせ 対象ラベルの前及び後の名前であるという事実に関する署名された、つまり 暗号に基づく証明である。dog.example.comはこの範囲内にあるため、再帰 サーバーはdog.example.comが間違いなく存在しないことを認識する。 タイプが存在しないという証明は、問い合わされた名前とリクエストされた タイプを含まないタイプビットマップを含む(DNSSECで保護された)レコード を提供することで達成される。 本文書は、署名を検証するサーバーが受信したあらゆる問い合わせのうち、 NSEC/NSEC3レコードにカバーされる範囲内にあるものに関しては、(それらの レコードのTTL期間内は)それらのNSEC/NSEC3レコードを使用してネガティブ 応答が生成されるべきであると規定する。また、本文書は、署名を検証する サーバーが受信したあらゆる問い合わせのうち、ワイルドカードレコードに よってカバーされると証明されているものに関しては、肯定応答が生成 されるべきであるとも規定する。 [RFC4035]のセクション4.5は以下のように述べている。 理論的には、リゾルバーは、対象となるレコードのTTLまたは署名が期限 切れになるまでは、ワイルドカードまたはNSEC RRを使用して、(それぞれ) 肯定応答、ネガティブ応答を生成できるだろう。しかし、リゾルバーが 新しい権威を持つデータを取得したり、新しいデータを独自に合成したり するのをブロックしない方が賢明であるように思われる。この推奨に従う リゾルバーは、より一貫性のある名前空間の展望が得られるだろう。 また、[RFC4035]のセクション4.5の前の部分では以下のように述べている。 これらの推奨の理由は、最初の問い合わせからデータのキャッシュが破棄 されるまでの間に、権威を持つデータが変更される(例えば動的更新に よって)可能性があることである。 言い換えると、リゾルバーがNSECレコードからネガティブ応答を生成すると、 (TTL期間内は)NSECの範囲内にある名前へのあらゆる問い合わせが送信されなく なる。この期間内に新しい名前がゾーンに追加されても、リゾルバーはそれを 認識しない。同様に、リゾルバーがワイルドカードから応答を生成する場合、 (TTL期間内は)同じ処理をし続ける。 この推奨は緩和できると考えている。なぜなら、この手法を適用しない場合 であっても、ゾーンに追加される予定の名前を正確に指定した検索がこの 期間内にやってきて、ゾーンにその名前を追加した時点でネガティブ応答が 既にキャッシュされてしまっているということもあり得るからである(詳細 な背景については[RFC2308]を参照せよ)。これは、ゾーン運用者は、追加 された名前が直ちに機能すると期待すべきではないことを意味する。 Fujiwara, et al. Standards Track [Page 5] RFC 8198 NSEC/NSEC3 Usage July 2017 DNSSEC及びDNSSEC署名検証済みキャッシュの積極的使用を行う場合、 NSEC/NSEC3レコードのTTLとSOA.MINIMUMフィールドが、ゾーン内でどの程度 早く名前が機能し始めるかに関する権威を持つ声明となる。 5. DNSSEC署名検証済みキャッシュの積極的使用 本文書は、[RFC4035]のセクション4.5で与えられる制約を緩和する。詳細に ついてはセクション7を参照せよ。 署名を検証するリゾルバーのネガティブキャッシュが問い合わせの応答に十分 な情報を持っている場合、リゾルバーは、本文書に記述されているように、 NSEC、NSEC3、ワイルドカードレコードを使用して回答を合成すべきである (SHOULD)。そうでない場合、リゾルバーは、フォールバックして権威DNS サーバーに問い合わせを送信しなければならない(MUST)。 5.1. NSEC 署名を検証するリゾルバーは、合成源と一致する/合成源をカバーするNSEC RRが存在するか、及び問い合わせ名をカバーするNSEC RRが存在するかを 検査する必要がある。 キャッシュ内のNSECレコードを使用し、[RFC4035]のセクション5.4に提示 されるルールに従って不在と判定できる場合、リゾルバーは直ちに(適宜) NXDOMAINまたはNODATA応答を返すことができる。 5.2. NSEC3 NSEC3の積極的なネガティブキャッシュ利用は、NSECの積極的なキャッシュ 利用よりも面倒である。署名ゾーンがNSEC3を使用している場合、署名を 検証するリゾルバーは、問い合わせ名から導出した非終端名とワイルドカード の存在を検査する必要がある。 キャッシュ内のNSEC3レコードを使用し、[RFC5155]のセクション8.4、8.5、 8.6、8.7に提示されるルールに従って不在と判定できる場合、リゾルバーは 直ちに(適宜)NXDOMAINまたはNODATA応答を返すことができる。 ドメイン名をカバーするNSEC3 RRがOpt-Outフラグを持つ場合、カバーする NSEC3 RRはそのドメイン名の不在を証明しないので、そのドメイン名に 対して積極的なネガティブキャッシュ利用を行うことは不可能である。 5.3. ワイルドカード [RFC4035]のセクション4.5の最後の段落でも、ワイルドカードとNSEC RRを 使用して肯定応答を生成することについて議論しており、それらに依存 すべきでないと推奨している。ネガティブ応答生成にNSEC/NSEC3を積極的に 使用するのと同様に、この推奨を改訂する。 Fujiwara, et al. Standards Track [Page 6] RFC 8198 NSEC/NSEC3 Usage July 2017 署名を検証するリゾルバーが[RFC4035]のセクション5.3.4に提示される ルール(NSEC)か、または[RFC5155]のセクション8.8に提示されるルール (NSEC3)に従って、ある名前がワイルドカードのマッチを除けば存在しない と判定できるならば、リゾルバーはキャッシュからその存在が推論される ワイルドカードを使用して、その名前に対する回答(またはNODATA応答)を 合成すべきである(SHOULD)。対応するワイルドカードがキャッシュ内にない 場合、リゾルバーはフォールバックして権威DNSサーバーに問い合わせを送信 しなければならない(MUST)。 5.4. TTLに関する考慮点 新しく追加されたドメイン名は、ネガティブ情報が有効である間は使用 できないので、ネガティブ情報のTTL値は特に重要である。 [RFC2308]のセクション5は、ネガティブキャッシュTTL値の最大デフォルト として3時間(10800)を示唆している。署名を検証するリゾルバーは、 ネガティブ応答(NSEC/NSEC3 RR)の最大実効TTL値をこれと同じ値に制限する ことが推奨される(RECOMMENDED)。 また、[RFC2308]のセクション5は、ネガティブキャッシュエントリーのTTL としてSOA.MINIMUMフィールドとSOAのTTLの最小値が採用されるとも述べて いる。NSECレコードまたはNSEC3レコードのTTLはSOA.MINIMUMフィールドと 等しいので([RFC4035]のセクション2.3及び[RFC5155]のセクション3を 参照せよ)、この採用されたTTLは、これらのレコードのTTLよりも小さく なる可能性がある。 NSECとNSEC3の積極的使用をサポートするリゾルバーは、ネガティブ応答の 権威部に含まれるSOA.MINIMUMがNSECとNSEC3のTTLよりも小さい場合、NSEC とNSEC3のTTLをSOA.MINIMUMに一致させるように減らすべきである(SHOULD)。 6. 本手法の利点 本文書に記述される手法は、(順不同で)以下に示すような数多くの利点を 提供する。 遅延の減少: 署名を検証するリゾルバーは、キャッシュから直接回答する ことで、検索対象の名前が存在しないことを直ちにクライアントに通知 できるため、ユーザー体感を向上させる。 再帰サーバーの負荷低減: 署名を検証するサーバーは、キャッシュから回答 を合成して問い合わせに回答することで、問い合わせを送信して応答を 待たなければならない状況を回避する。これは、使用帯域を削減すること に加えて、サーバーが状態を割り当てて維持する必要がなくなるため、 メモリとCPUの負荷が減少することも意味する。 Fujiwara, et al. Standards Track [Page 7] RFC 8198 NSEC/NSEC3 Usage July 2017 権威サーバーの負荷低減: 再帰サーバーは、権威サーバーに依頼する ことなく問い合わせに回答できるため、権威サーバーが受信する問い合わせ は少なくなる。これは、権威サーバーの帯域、1秒あたりの問い合わせ数 (qps)、CPU使用率を低下させる。 得られる利益の規模は、問い合わせの分布を初めとする複数の要因に依存する。 例えば、本文書執筆時点において、ルートネームサーバーへの問い合わせの 約65%にNXDOMAIN応答が返されている([ROOT-SERVERS]の統計情報を参照せよ)。 本手法は、このような問い合わせのかなりの量を取り除くだろう。 本文書に記述される手法は、攻撃者がランダムなサブドメインへの多数の 問い合わせをリゾルバーに送信する、いわゆる"ランダムサブドメイン攻撃"も 軽減する。リゾルバーはキャッシュされた回答を保持しないため、外部 サーバーにランダムな問い合わせを依頼するので、権威サーバー(と、 多くの場合リゾルバー)に対するDoSを引き起こす。本手法は、既にリクエスト された範囲内にあるあらゆるランダムな問い合わせに対し、リゾルバーが キャッシュから直接回答できるようにすることで、このような攻撃を軽減 する一助となるだろう。本手法が常に効果的な防御として機能するとは 限らない。特に、DNSSECで署名されたゾーンが少ない現状ではなおさら である。とは言え、防御の追加レイヤーを提供することは確かである。 これらの利点はDNSSECを使用している者だけが得られるので、本手法がDNSSEC の一層の普及をもたらすことが期待される。 7. RFC 4035の更新 [RFC4035]のセクション4.5は、次のようになっている。"理論的には、リゾルバー は、対象となるレコードのTTLまたは署名が期限切れになるまでは、ワイルド カードまたはNSEC RRを使用して、(それぞれ)肯定応答、ネガティブ応答を生成 できるだろう。しかし、リゾルバーが新しい権威を持つデータを取得したり、 新しいデータを独自に合成したりするのをブロックしない方が賢明であるように 思われる。この推奨に従うリゾルバーは、より一貫性のある名前空間の展望が 得られるだろう。" この段落は、以下のように更新される。 +-----------------------------------------------------------------+ | レコードが一旦署名検証されたならば、DNSSEC対応の署名を検証する | | リゾルバーは、署名検証済みレコードの実効TTLまたは署名が期限 | | 切れになるまでは、ワイルドカード及びNSEC/NSEC3リソース | | レコードを使用して、肯定応答、ネガティブ応答を生成すべき | | である(SHOULD)。 | +-----------------------------------------------------------------+ Fujiwara, et al. Standards Track [Page 8] RFC 8198 NSEC/NSEC3 Usage July 2017 8. IANAに関する考慮点 本文書は、IANAの作業を何も要求しない。 9. セキュリティに関する考慮点 DNSSECの署名検証をせずにNSEC/NSEC3リソースレコードを使用すると、 重大なセキュリティ上の問題が生じる可能性があるため、本手法は DNSSECの署名検証を必要とする。 新しく登録されたリソースレコードは、すぐには使用されないかも しれない。しかし、適切なTTL値及びネガティブキャッシュTTL値 (SOA.MINIMUMフィールド)を選択することで遅延の懸念は軽減される ので、セキュリティ上の問題とはならない。 また、この問題を軽減するため、ネガティブキャッシュに含まれるNSEC/NSEC3 リソースレコードの最大TTL値を、例えば10800秒(3時間)に制限すること も提案されている。 NSEC/NSEC3レコードのTTLは、通常かなり短い(数分または数時間)が、関連 するRRSIGの有効期限は今後更に(数週間くらいに)長くなる可能性がある。 応答を首尾よく偽造できる攻撃者は、古いNSEC/NSEC3レコードでキャッシュ を汚染できる可能性がある。リゾルバーがNSEC/NSEC3を積極的に使用して いなければ、攻撃者は、問い合わせごとに攻撃を繰り返さなければならない。 これに対し、リゾルバーがNSEC/NSEC3を積極的に使用している場合、一旦 攻撃が成功すると、ネガティブキャッシュTTLが満了するまで新しい名前 への多数の問い合わせを抑止できてしまう。 10. References 10.1. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, . [RFC2308] Andrews, M., "Negative Caching of DNS Queries (DNS NCACHE)", RFC 2308, DOI 10.17487/RFC2308, March 1998, . [RFC4035] Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose, "Protocol Modifications for the DNS Security Extensions", RFC 4035, DOI 10.17487/RFC4035, March 2005, . Fujiwara, et al. Standards Track [Page 9] RFC 8198 NSEC/NSEC3 Usage July 2017 [RFC4592] Lewis, E., "The Role of Wildcards in the Domain Name System", RFC 4592, DOI 10.17487/RFC4592, July 2006, . [RFC5155] Laurie, B., Sisson, G., Arends, R., and D. Blacka, "DNS Security (DNSSEC) Hashed Authenticated Denial of Existence", RFC 5155, DOI 10.17487/RFC5155, March 2008, . [RFC7129] Gieben, R. and W. Mekking, "Authenticated Denial of Existence in the DNS", RFC 7129, DOI 10.17487/RFC7129, February 2014, . [RFC7719] Hoffman, P., Sullivan, A., and K. Fujiwara, "DNS Terminology", RFC 7719, DOI 10.17487/RFC7719, December 2015, . [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, . 10.2. Informative References [RES-IMPROVE] Vixie, P., Joffe, R., and F. Neves, "Improvements to DNS Resolvers for Resiliency, Robustness, and Responsiveness", Work in Progress, draft-vixie-dnsext-resimprove-00, June 2010. [RFC5074] Weiler, S., "DNSSEC Lookaside Validation (DLV)", RFC 5074, DOI 10.17487/RFC5074, November 2007, . [RFC8020] Bortzmeyer, S. and S. Huque, "NXDOMAIN: There Really Is Nothing Underneath", RFC 8020, DOI 10.17487/RFC8020, November 2016, . [ROOT-SERVERS] "Root Server Technical Operations Assn", . Fujiwara, et al. Standards Track [Page 10] RFC 8198 NSEC/NSEC3 Usage July 2017 付録 A. 実装に関する詳細な注記 ・ 以前は、キャッシュされたネガティブ応答はQNAME、QCLASS、QTYPE及び CDビットの有無によってインデックスが作成され(RFC 4035のセクション 4.7参照)、インデックスキーに一致する問い合わせにだけキャッシュから 回答されていた。ネガティブキャッシュを積極的に利用する場合、 バリデーターは、問い合わせを送信する前にキャッシュ内に回答がないかを 検査することに加えて、署名検証済みNSECレコードのキャッシュが検索 対象レコードの不在を示唆していないかも確認する。ネガティブキャッシュ を積極的に利用することにより、バリデーターは署名検証済みNSECレコード のキャッシュにカバーされるあらゆる名前への問い合わせを行わなくなる。 更に、クライアントからの問い合わせに回答するバリデーターは、利用 可能な署名検証済みNSECがキャッシュ内にある場合、到着した問い合わせに CDビットが設定されていない限り常にネガティブ応答(またはNODATA応答) を合成するようになる。([RFC5074]のセクション6より引用)。 ・ 積極的なネガティブキャッシュ利用を実装するということは、NSEC/NSEC3 レコードがカバーする名前を効率的に見つけるために、NSEC/NSEC3レコード の署名者ドメイン名それぞれについて、順序付けられたNSEC/NSEC3レコード のデータ構造をバリデーターが構築しなければならないことを示唆している。 この表を"NSEC_TABLE"と呼ぶ([RFC5074]のセクション6.1より引用して追記)。 ・ 積極的なネガティブキャッシュ利用は、再帰リゾルバーのキャッシュ検索 処理部に挿入されるだろう。 ・ 積極的なネガティブキャッシュ利用アルゴリズムでエラーが発生した場合、 リゾルバーはフォールバックして通常どおりに問い合わせ解決をしなければ ならない(MUST)。"通常どおりに問い合わせ解決をする"とは、リゾルバーが 積極的なネガティブキャッシュ利用を実装していないかのように問い合わせ を処理しなければならないことを意味する。 付録 B. NSEC使用時の判定手順: ENTかNXDOMAINか ここに示す手順は、NSECを使用して、与えられた名前が存在していないのか、 またはENT(空の非終端名。[RFC5155]のセクション1.3を参照せよ)なのかを 判定する方法の概要である。 NSECレコードがSecure(検証成功: 信頼度高)であると確認されていない場合 は破棄する。 与えられた名前が順序的にNSECの所有者名の前にある、またはNSECの所有者名 と一致する場合、そのNSECはNXDOMAINやENTを証明しないため破棄する。 与えられた名前がNSECの所有者名のサブドメインであり、そのNSECのタイプ ビットマップにNSビットは存在するがSOAビットがない場合、そのNSECは 親ゾーン由来のものなので破棄する。 Fujiwara, et al. Standards Track [Page 11] RFC 8198 NSEC/NSEC3 Usage July 2017 NSECの次ドメイン名が順序的にそのNSECの所有者名の後ろにあり、与えられた 名前が順序的にその次ドメイン名よりも後ろにあるか次ドメインと一致する 場合、そのNSECはNXDOMAINやENTを証明しないため破棄する。 NSECの次ドメイン名が順序的にそのNSECの所有者名の前にあるか所有者名と 一致し、与えられた名前が次ドメイン名のサブドメイン名ではない場合、 そのNSECはNXDOMAINやENTを証明しないため破棄する。 残ったNSECレコードは、NXDOMAINまたはENTを証明する。 NSECの次ドメイン名が与えられた名前のサブドメインである場合、そのNSECは ENTを証明する。そうでない場合、そのNSECはNXDOMAINを証明する。 Acknowledgments The authors gratefully acknowledge DNSSEC Lookaside Validation (DLV) [RFC5074] author Samuel Weiler and the Unbound developers. Thanks to Mark Andrews for providing the helpful notes for implementors provided in Appendix B. The authors would like to specifically thank Stephane Bortzmeyer (for standing next to and helping edit), Ralph Dolmans, Tony Finch, Tatuya JINMEI for extensive review and comments, and also Mark Andrews, Casey Deccio, Alexander Dupuy, Olafur Gudmundsson, Bob Harold, Shumon Huque, John Levine, Pieter Lexis, Matthijs Mekking (who even sent pull requests!), and Ondrej Sury. Fujiwara, et al. Standards Track [Page 12] RFC 8198 NSEC/NSEC3 Usage July 2017 Authors' Addresses Kazunori Fujiwara Japan Registry Services Co., Ltd. Chiyoda First Bldg. East 13F, 3-8-1 Nishi-Kanda Chiyoda-ku, Tokyo 101-0065 Japan Phone: +81 3 5215 8451 Email: fujiwara@jprs.co.jp Akira Kato Keio University/WIDE Project Graduate School of Media Design, 4-1-1 Hiyoshi Kohoku, Yokohama 223-8526 Japan Phone: +81 45 564 2490 Email: kato@wide.ad.jp Warren Kumari Google 1600 Amphitheatre Parkway Mountain View, CA 94043 United States of America Email: warren@kumari.net Fujiwara, et al. Standards Track [Page 13]