Internet Engineering Task Force (IETF) S. Bortzmeyer Request for Comments: 8020 AFNIC Updates: 1034, 2308 S. Huque Category: Standards Track Verisign Labs ISSN: 2070-1721 November 2016 ドメイン名不在: 下には全く何もない Abstract この文書は、DNSリゾルバーがドメイン名不在のレスポンスコードを持つ応答を 受信した場合、ないと否定されたドメイン名とその下にあるすべての名前は存 在しないということを明確に述べている。 この文書はRFC 1034を明確にし、RFC 2308の一部を修正して、それら両方を 更新している。 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/rfc8020. Copyright Notice Copyright (c) 2016 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. Bortzmeyer & Huque Standards Track [Page 1] RFC 8020 NXDOMAIN Cut November 2016 目次 1. 導入と背景 ......................................................2 1.1. 用語 .......................................................3 2. 規則 ............................................................3 3. RFCの更新 .......................................................5 3.1. RFC 1034の更新 .............................................5 3.2. RFC 2308の更新 .............................................5 4. 利点 ............................................................5 5. 起こりうる問題 ..................................................6 6. 実装の考察 ......................................................6 7. セキュリティの考察 ..............................................7 8. References ......................................................7 8.1. Normative References .......................................7 8.2. Informative References .....................................8 付録A. なぜ返されたSOAレコードの所有者名を用いないのか？ ...........9 付録B. 関連するアプローチ ..........................................9 Acknowledgments ....................................................9 Authors' Addresses ................................................10 1. 導入と背景 DNSプロトコル[RFC1035]はレスポンスコード3を「名前エラー」または「ドメ イン名不在」[RFC2308]と定義し、それは問い合わせを受けたドメイン名は DNSに存在しないということを意味する。ドメイン名はラベルの木 ([RFC1034], 3.1節)として表現されるため、ノードが存在しないということ は、そのノードを根に持つ部分木全体が存在しないということを意味してい る。 DNSの反復名前解決アルゴリズムは、この方式で正確にドメイン名不在シグナ ルを解釈する。もし権威サーバーからのドメイン名不在レスポンスコードに遭 遇した場合、直ちに反復検索を止め、ドメイン名不在応答を問い合わせ元に返 す。 ところが、今日存在すると知られているリゾルバーのほとんどにおいて、 キャッシュされたドメインの非存在情報は、その下に子のドメインがないと いうことを「証明」するとは考えられていない。これは [RFC1034] にある、 Empty Non-Terminal(ENT)([RFC7719])と存在しない名前(3.1節)を区別するこ とができないあいまいさによるものである。この区別はDNSSECの発展のためには 特に重要になる。なぜならDNSSECは非存在の証明を提供するからである。 [RFC4035]の3.1,3.2節ではDNSSEC対応の権威を持つネームサーバーがどのよう に区別を行うかについて述べられているが、再帰的問い合わせを行うネーム サーバーの動作について述べたRFCは存在しない。 Bortzmeyer & Huque Standards Track [Page 2] RFC 8020 NXDOMAIN Cut November 2016 この文書には、あるドメイン名に対するドメイン名不在応答は、その問い合わ せを受けた名前の下には子ドメインも存在しないことを意味するということ が明記されている。更にそれは、DNSリゾルバーはキャッシュされた非存在情 報をこの方式で解釈すべきであることを意味する。ドメイン名は一本の木で 構成されているため、それは木構造の単純な結果である。すなわちあるノー ドが存在しないということは、このノードを根に持つ部分木全体が存在しな いということを意味する。 1.1. 用語 本文書におけるキーワード"しなければならない(MUST)"、"してはならない (MUST NOT)"、"要求される(REQUIRED)"、"するものとする(SHALL)"、"しな いものとする(SHALL NOT)"、"すべきである(SHOULD)"、"すべきでない (SHOULD NOT)"、"推奨される(RECOMMENDED)"、"してもよい/することがで きる(MAY)"、"任意である(OPTIONAL)"は、RFC 2119[RFC2119]に記述されて いる通りに解釈するものとする。 "問い合わせ名(QNAME)": [RFC1034]及び[RFC1035]の4.1.2節で定義されている が、[RFC2308]が異なる定義を提供しているため、私たちはここで元の定義を 繰り返す。すなわち問い合わせ名(QNAME)は問い合わせ部におけるドメイン名であ る。 "非存在名(Denied name)": ドメイン名不在の応答RCODEによってその存在が 否定されたドメイン名。多くの場合は問い合わせ名(QNAME)であるが、 [RFC6604]の理由で、いつでも当てはまるというわけではない。 その他の用語は[RFC1034]や[RFC1035]、(ドメイン名不在そのもののように) より最近の[RFC7719]で定義されている。 ドメインの名前空間は概念的に木構造の観点から定義される。DNSリゾルバー/ キャッシュの実装は木構造もしくは他のデータ構造を用いることができる (MAY)。キャッシュはドメインの名前空間のデータの部分集合であるため、木 構造の観点からそれを推論し、物事をそれらの用語(下/上にある名前、子孫 の名前、部分木、等)で説明するのがより簡単である。実際、[RFC1034]にお けるDNSアルゴリズムの記述では、キャッシュは木構造であるという仮定が述 べられてさえいるため、先例がすでにかなり確立されている。その4.3.2節を 見ると、「次のアルゴリズムは、リソースレコードはいくつかの木構造で構 成されていて、一つはそれぞれのゾーン、もう一つはキャッシュに対応すると 仮定する...」と書かれている。従って、この文書では、木または木の操作に ついて議論するごとに、実際の実装ではなくモデルを参照している。 2. 規則 反復キャッシュDNSリゾルバーがドメイン名不在応答を受信した場合、それを キャッシュに格納すべきであり(SHOULD)、そのノードにある、もしくはその 下にあるすべての名前とリソースレコードのセット(RRsets)は到達不能である と考えられるべきである(SHOULD)。それらの名前に対するその後の問い合わせ はドメイン名不在応答を生じさせるべきである(SHOULD)。 Bortzmeyer & Huque Standards Track [Page 3] RFC 8020 NXDOMAIN Cut November 2016 しかし、もしリゾルバーが不在ドメイン名の枝以下のキャッシュされたデータ を持っている場合、これが問い合わせを受信した時の追加の処理を避けるかも しれないゆえに、(このキャッシュされたデータのTTLが終了するまで)それを 応答として送り続けることができる(MAY)。6章はこれについてさらなる情報 を提供している。 もう一つの例外は、署名を検証するリゾルバーは、ドメイン名不在応答がDNSSEC で検証されている時のみ、(この章の最初の段落で説明されている)"不在ドメ イン名の枝"の動作を実装することを決めることができる(MAY)。その根拠に ついては7章を見てほしい。 部分木が存在しないという事実は永久ではない。[RFC2308]の3章では、ドメ イン名不在応答がキャッシュされる時間についての説明がすでになされてい る("ネガティブTTL")。 もしキャッシュされた非存在情報によるドメイン名不在応答がDNSSECで署名 されたゾーンからであった場合、その名前の非存在を証明するNSECまたは NSEC3レコードが付随するだろう。元の不在ドメイン名の子孫の名前に対し、 同じNSECまたはNSEC3レコードのセットがその子孫の名前の非存在を証明す る。反復検索、キャッシングを行うリゾルバーは、もし問い合わせにDNSSEC OK(DO)ビットがセットされていた場合、これらのNSECまたはNSEC3レコードを 引き金となる問い合わせへに対し返さなければならない(MUST)。 警告: もしCNAME(またはDNAME)のチェーンがある場合、存在しない名前は チェーンの最後であり([RFC6604])問い合わせ名(QNAME)ではない。キャッシュ に格納された不在ドメイン名は非存在名であり、常に問い合わせ名(QNAME)にあ たるわけではない。 これらのルールの結果の例として、非存在ドメイン'foo.example'を持つ、リ ゾルバーに対する二つの連続する問い合わせを考える。最初は'foo.example'(ドメ イン名不在になる)であり、2番目は'bar.foo.example'(こちらもドメイン名 不在になる)である。今日の多くのリゾルバーは両方の問い合わせを転送するだろ う。ところが、この文書のルール("不在ドメイン名の枝")に従うと、リゾル バーは非存在の合図として最初のドメイン名不在応答をキャッシュし、すぐに2 番目の問い合わせに対し、それを権威サーバーに送信することなく、ドメイン名 不在応答を返すだろう。 もし最初の要求が'bar.foo.example'で2番目が'baz.foo.example'であった場 合、最初のドメイン名不在応答は'baz.foo.example'について何も伝えないだ ろう。それゆえに、"不在ドメイン名の枝"の最適化の利用の前であるため2番 目の問い合わせは送信されるだろう(付録Aを参照)。 Bortzmeyer & Huque Standards Track [Page 4] RFC 8020 NXDOMAIN Cut November 2016 3. RFCの更新 3.1. RFC 1034の更新 この文書はEmpty Non-Terminal (ENT) ([RFC7719]) と存在しない名前を明確 に区別しなかった [RFC1034] における潜在的なあいまいさを明確にし、明確に区 別するその後の文書を参照する。ENTはDNSにおけるノードであり、自身と関 連づけられたリソースレコードを保持しないが、リソースレコードを保持す る子孫のノードを持つ。ENTに対する正しい応答はNODATA応答(すなわち、 NOERRORのレスポンスコードと空の回答部)である。これらの点における追加 の明確にする説明は[RFC2136]の7.16節と[RFC4592]の2.2.2節と2.2.3節で提 供される。 3.2. RFC 2308の更新 [RFC2308]での5章の第2段落では次のように述べられている。 "Name Error(名前エラー)"応答(ドメイン名不在)から生じるネガティブア ンサーは、同じの問い合わせが別途行われた際の応答とし て、キャッシュされたネガティブ応答の結果が検索され返されるよう、 キャッシュされるべきである。 この文書はその段落を次のように改訂する。 "Name Error(名前エラー)"応答(ドメイン名不在)から生じるネガティブア ンサーは、同じの問い合わせ、もしくは問い合わせ名(QNAME) が元の問い合わせ名(QNAME)の子孫でありQCLASSが同じ場合の問い合わせが別 途行われた際の応答として、キャッシュされたネガティブ応答の結果が検 索され返されるよう、キャッシュされるべきである。 上部の2章はこの改訂された規則に磨きをかけ、いつ力を抜くか無視するのが 理にかなうかについて明記している。 4. 利点 主な利点はキャッシュの効率向上である。上の例において、リゾルバーは二つで はなく一つの問い合わせのみを送信し、2番目の問い合わせはキャッシュから回答 される。権威ネームサーバーが処理する不必要な通信が少なくなるため、これ はDNS全体のエコシステムにとって有益となるだろう。 ([RFC1034]で規定されこの文書でより明確になった)正しい振る舞いは、問合 わせ名(QNAME)の最小化[RFC7816]と組み合わせた時に特に有用となる。なぜ ならドメイン名不在に遭遇するとすぐにリゾルバーは探索を止めることができ るからである。 Bortzmeyer & Huque Standards Track [Page 5] RFC 8020 NXDOMAIN Cut November 2016 「不在ドメイン名の枝」もまたランダムな問い合わせ名(QNAME)を送りつける攻 撃[joost-dnsterror]と[balakrichenan-dafa888]の特定の種類を軽減する助 けになるかもしれない。その攻撃においては存在しないサフィックスが固定 されている。権威ネームサーバーに対するこれらの攻撃では、一般的に存在し ない、固定されたサフィックス("dafa888.wf"は上で紹介した記事の一つ)と、 それぞれの要求ごとに異なるランダムなプレフィックスから構成された問合 わせ名(QNAME)を持つ問い合わせがリゾルバーに送信される。これらの要求を受信 したリゾルバーはそれを権威サーバーに転送しなければならない。「不在ドメイ ン名の枝」がある場合、システム管理者は固定されたプレフィックスを持つ 問い合わせをリゾルバーに送信するしかないが、リゾルバーはドメイン名不在を得 て問い合わせの転送を止めるだろう(ドメイン名不在応答内のSOAレコードが非 存在ドメインを見つけるのに十分であった場合その方が良いが、これは起こ らない。付録Aを見てほしい。)。 5. 起こりうる問題 exampleというトップレベルドメイン(TLD)が存在するが、foobar.exampleに は権限の委譲がされていない(すなわちexampleのネームサーバーは anything.foobar.exampleについての問い合わせに対しドメイン名不在を返す) 場合を想定してみよう。システム管理者はoffice.foobar.example下の自分の 組織の内部コンピュータにドメイン名をつけることを決め、リゾルバーがこの ゾーンについての問い合わせ要求をローカルな権威ネームサーバーに転送する小 枝を用いる。「不在ドメイン名の枝」はここで問題を生じさせる。リゾルバー への要求の順序に従い、exampleが存在しないことをキャッシュし、それゆえ にexample以下のすべての名前を「消去する」かもしれない。この文書では、そ のような設定はまれでありサポートされる必要はないと想定する。 今日では、別の起こりうる問題が存在する。ENT([RFC7719], 6章)に対し通常 のNODATA応答([RFC7719], 3章)ではなくドメイン名不在を返す権威ネーム サーバーを私たちは観測している。 そのようなネームサーバーは明確に間違いであり常にそうであってきた。その 振る舞いはDNSSECと相容れない。「不在ドメイン名の枝」の利点を考慮する とこの振る舞いをサポートする理由はほとんどない。 6. 実装の考察 この章は非規範的であり、実装者に役立つかもしれないさまざまな事柄のみで構 成されている。再帰的リゾルバーは自身のキャッシュをさまざまな方法で実装する かもしれない。最も理解しやすいものは木のデータ構造である。なぜならド メイン名のデータモデルと一致するからである。しかし実際には、他の実装 も可能であり、それは(いくつかの共通のドメイン名をインデックスに持つよ うに拡張された木のような)さまざまな最適化があるのと同様である。 Bortzmeyer & Huque Standards Track [Page 6] RFC 8020 NXDOMAIN Cut November 2016 もしリゾルバーが自身のキャッシュを(何の最適化もなく)木構造で実装する場 合、2章での規則に従う一つの方法は次のようになる。ドメイン名不在を受信 した時、そのノードにおいて存在するキャッシュエントリーの部分木を切り取 るかもしくは、そのノードの下の名前の個々のキャッシュエントリーをすべて削 除する。その後、キャッシュ内を下方向に探索する時、もしキャッシュされ た非存在情報に遭遇した場合この反復キャッシュリゾルバーは探索を止めるだ ろう。 いくつかのリゾルバーは木構造で構成されていない(例えば、辞書型構造のよう な)キャッシュを持つかもしれない。それゆえに2章の規則を無視する理由が ある。従ってこれらの規則では「しなければならない(MUST)」ではなく「す べきである(SHOULD)」という表現を用いる。 7. セキュリティの考察 この文書で説明されている技術は「ランダムな問い合わせ名を送りつける攻 撃」と呼ばれる、4章で説明されたサービス不能攻撃に対する助けになるかも しれない。 もしリゾルバーが応答をDNSSECで検証しない場合、またはゾーンが署名されて いない場合、当然リゾルバーは偽の不在ドメイン名で汚染される。従って、ド メイン名の木の一部を「消去」することになる。このサービス不能攻撃はす でにこの文書の規則がなくとも可能である(むしろ「不在ドメイン名の枝」が その影響を増大させるかもしれない)。唯一の解決策はDNSSECを用いることで ある。 8. References 8.1. Normative References [RFC1034] Mockapetris, P., "Domain names - concepts and facilities", STD 13, RFC 1034, DOI 10.17487/RFC1034, November 1987, . [RFC1035] Mockapetris, P., "Domain names - implementation and specification", STD 13, RFC 1035, DOI 10.17487/RFC1035, November 1987, . [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, . [RFC2136] Vixie, P., Ed., Thomson, S., Rekhter, Y., and J. Bound, "Dynamic Updates in the Domain Name System (DNS UPDATE)", RFC 2136, DOI 10.17487/RFC2136, April 1997, . Bortzmeyer & Huque Standards Track [Page 7] RFC 8020 NXDOMAIN Cut November 2016 [RFC2308] Andrews, M., "Negative Caching of DNS Queries (DNS NCACHE)", RFC 2308, DOI 10.17487/RFC2308, March 1998, . [RFC4592] Lewis, E., "The Role of Wildcards in the Domain Name System", RFC 4592, DOI 10.17487/RFC4592, July 2006, . [RFC6604] Eastlake 3rd, D., "xNAME RCODE and Status Bits Clarification", RFC 6604, DOI 10.17487/RFC6604, April 2012, . 8.2. Informative References [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, . [RFC7719] Hoffman, P., Sullivan, A., and K. Fujiwara, "DNS Terminology", RFC 7719, DOI 10.17487/RFC7719, December 2015, . [RFC7816] Bortzmeyer, S., "DNS Query Name Minimisation to Improve Privacy", RFC 7816, DOI 10.17487/RFC7816, March 2016, . [DNSRRR] 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. [NSEC] Fujiwara, K., Kato, A., and W. Kumari, "Aggressive use of NSEC/NSEC3", Work in Progress, draft-ietf-dnsop-nsec- aggressiveuse-04, September 2016. [joost-dnsterror] Joost, M., "About DNS Attacks and ICMP Destination Unreachable Reports", December 2014, . [balakrichenan-dafa888] Balakrichenan, S., "Disturbance in the DNS - "Random qnames", the dafa888 DoS attack"", October 2014, . Bortzmeyer & Huque Standards Track [Page 8] RFC 8020 NXDOMAIN Cut November 2016 付録A. なぜ返されたSOAレコードの所有者名を用いないのか？ この文書では、あるドメインが存在しないことをドメイン名不在応答によっ てのみ推測し、そこでは非存在名は正確なドメインである。もしリゾルバーが exampleというトップレベルドメインのネームサーバーに問い合わせを送信し、 www.foobar.exampleのメール交換(MX)レコードを尋ね、結果としてドメイン 名不在を受信した場合、www.foobar.example(とその下にあるすべて)は存在し ないという事実をリゾルバーは記録するだけである。付随するSOAレコードの対 象がexampleドメインのみであるかどうかに関わらずこれは事実である。誰も foobar.exampleは存在しないということを推測することはできない。付随す るSOAレコードは存在する最も近いドメイン名ではなくゾーンの頂点を指し示 す。従って、「不在ドメイン名の枝」を推測するためにSOAレコードの権威部 における所有者名を用いることは現在のところ絶対に間違いである。 ドメイン名不在応答のSOAレコードからあるノードが存在しないことを推測す ることは、間違いなくランダムな問い合わせを送りつける攻撃の助けとなるか もしれないが、これはこの文書のスコープ外である。この章の最初の段落で 述べられた問題を扱う必要があるだろう。可能な解決策は、木構造の中で一つ 以上上位にあるSOAでドメイン名不在を受け取った時に、その問い合わせ名 (QNAME)とSOAレコードの所有者名の間に位置するドメインの要求を送信する ことである。(DNSSECの検証または問い合わせ名(QNAME)の最小化を行うリゾル バーはとにかくそれを行う必要があるだろう。) 付録B. 関連するアプローチ [NSEC]の文書は同じ懸念(存在しないドメイン名のトラフィックを減らすこ と)のいくつかを扱う別の方法を説明している。「不在ドメイン名の枝」と違 いそれはDNSSECを必要とするが、より強力である。なぜなら問い合わせを受け ていないドメインに対するドメイン名不在を合成することができるからであ る。 Acknowledgments The main idea in this document is taken from [DNSRRR], Section 3, "Stopping Downward Cache Search on NXDOMAIN". Thanks to its authors, Paul Vixie, Rodney Joffe, and Frederico Neves. Additionally, Tony Finch, Ted Lemon, John Levine, Jinmei Tatuya, Bob Harold, and Duane Wessels provided valuable feedback and suggestions. Bortzmeyer & Huque Standards Track [Page 9] RFC 8020 NXDOMAIN Cut November 2016 Authors' Addresses Stephane Bortzmeyer AFNIC 1, rue Stephenson Montigny-le-Bretonneux 78180 France Phone: +33 1 39 30 83 46 Email: bortzmeyer+ietf@nic.fr URI: https://www.afnic.fr/ Shumon Huque Verisign Labs 12061 Bluemont Way Reston, VA 20190 United States of America Email: shuque@verisign.com URI: http://www.verisignlabs.com/ Bortzmeyer & Huque Standards Track [Page 10]