NXDOMAIN：その下には本当に何もない

アブストラクト

この文書は、DNSリゾルバがNXDOMAINのレスポンスコードでレスポンスを受信したときに、このように拒否されたドメイン名とそれ以下のすべての名前が存在しないことを意味します。

この文書はRFC 1034を明確にし、RFC 2308の一部を修正し、両方を更新します。

このメモの状況

これはインターネット標準化文書です。

この資料はインターネット技術特別調査委員会（IETF）の製品です。それはIETFコミュニティの合意を表しています。それは一般のレビューを受けており、Internet Engineering Steering Group（IESG）による公開が承認されています。インターネット標準に関する詳細情報は、RFC 7841のセクション2にあります。

この文書の現在の状況、正誤表、およびそのフィードバック方法に関する情報は、http://www.rfc-editor.org/info/rfc8020 で入手できます。

著作権表示

Copyright（c）2016 IETF Trustおよび文書の著者として識別された人物。全著作権所有。

この文書は、この文書の発行日に有効なBCP 78およびIETF文書のIETF文書に関する法的規定（ http://trustee.ietf.org/license-info ）に従います。これらの文書は、この文書に関するあなたの権利と制限を説明しているので、慎重に検討してください。本書から抽出されたコードコンポーネントには、Trust Legal Provisionsのセクション4.eに記載されているSimplified BSD Licenseのテキストが含まれており、Simplified BSD Licenseに記載されているとおり無保証で提供されます。

1. イントロダクションと背景

DNSプロトコル[RFC1035]は、応答コード3を “Name Error”、または “NXDOMAIN” [RFC2308]として定義しています。これは問い合わせたドメイン名がDNSに存在しないことを意味します。ドメイン名はラベルの木として表されるので（[RFC1034]、セクション3.1）、ノードが存在しないことは、このノードをルートとするサブツリー全体が存在しないことを意味します。

DNS反復解決アルゴリズムは、この方法でNXDOMAIN信号を正確に解釈します。信頼できるサーバからのNXDOMAINレスポンスコードに遭遇した場合は、ただちに反復を停止し、NXDOMAINレスポンスをクエリアに返します。

しかし、今日のほとんどの既知の既存のリゾルバでは、ドメインのキャッシュされた非存在は、その下に子ドメインが存在し得ないという「証拠」とは見なされません。これは存在しない名前（セクション3.1）から空の非終端（ENT）名（[RFC7719]）を区別するのに失敗した[RFC1034]のあいまいさによるものです。この区別は、存在しないことを証明するDNSSECの開発にとって特に重要になりました。[RFC4035]、セクション3.1.3.2は、セキュリティを意識した権威あるネームサーバがどのように区別するのかを説明していますが、既存のRFCでは再帰ネームサーバの動作を説明していません。このドキュメントはドメイン名のためのNXDOMAIN応答が質問された名前の下に子供ドメインがどちらも存在しないことを意味することを指定します。さらに、DNSリゾルバはキャッシュされた存在しないものをこの方法で解釈すべきであることを意味します。

1.1. 用語

この文書の「してはいけない」、「してはいけない」、「必要」、「しない」、「しない」、「しない」、「推奨」、「可能」、および「任意」のキーワードは次のとおりです。 [RFC2119]で説明されるように解釈されるために。

“QNAME”：[RFC1034]と[RFC1035]、セクション4.1.2で定義されていますが、[RFC2308]は別の定義を提供しているので、ここで元の定義を繰り返します。QNAMEは質問セクションのドメイン名です。

“拒否された名前”：NXDOMAINの応答RCODEによってその存在が拒否されたドメイン名。ほとんどの場合、それはQNAMEですが、[RFC6604]のために、常にそうとは限りません。

他の用語は[RFC1034]、[RFC1035]、および（NXDOMAIN自体のように）より最近の[RFC7719]で定義されています。

ドメインネームスペースは概念的にはツリー構造の観点から定義されています。DNSリゾルバ/キャッシュの実装は木か他のデータ構造を使うかもしれません（MAY）。キャッシュはドメインネームスペース内のデータのサブセットであるため、そのツリー構造の観点からそれを推論し、それらの用語（下/上の名前、子孫の名前、サブツリーなど）で説明する方がはるかに簡単です。実际、[RFC1034]のDNSアルゴリズム記述はキャッシュが木構造であるという仮定さえ述べます、それで先例はすでに十分に確立されています： “次のアルゴリズムはRRが組織されると仮定します”いくつかのツリー構造では、ゾーンごとに1つ、キャッシュごとに1つです… “したがって、このドキュメントでは、ツリーまたはツリー操作について説明するたびに、モデルを参照しています。

2. 規則

反復キャッシングDNSリゾルバがNXDOMAIN応答を受信すると、それをキャッシュに格納してから、そのノード以下のすべての名前とリソースレコードセット（RRsets）を到達不能と見なすべきである（SHOULD）。そのような名前のためのその後の質問はNXDOMAIN応答を引き出すべきです（SHOULD）。しかし、リゾルバがNXDOMAINカットの下でデータをキャッシュしていた場合、クエリが受け取られたときに追加の処理が回避される可能性があるため、応答として送信し続けることができます（このキャッシュデータのTTLが期限切れになるまで）。セクション6では、これに関する詳細情報を提供しています。

もう1つの例外は、NXDOMAIN応答がDNSSECで検証された場合にのみ、検証リゾルバが「このNXDOMAINカット」動作（このセクションの最初の段落で説明）を実装することを決定してもよいことです。根拠についてはセクション7を参照してください。

サブツリーが存在しないという事実は永遠ではありません：[RFC2308]、セクション3は、NXDOMAIN応答がキャッシュされるかもしれない時間の長さをすでに述べています（「負のTTL」）。

キャッシュされた非存在によるNXDOMAIN応答がDNSSEC署名付きゾーンからのものである場合は、名前の非存在を認証する付随するNSECまたはNSEC3レコードが含まれます。元のNXDOMAIN名の子孫名の場合、同じNSECレコードまたはNSEC3レコードのセットは、子孫名が存在しないことを証明します。反復的なキャッシングリゾルバは、問い合わせにDNSSEC OK（DO）ビットが設定されている場合、トリガとなる問い合わせへの応答としてこれらのNSECまたはNSEC3レコードを返さなければならない。

警告：CNAME（またはDNAME）のチェーンがある場合、存在しない名前はチェーンの最後（[RFC6604]）であり、QNAMEではありません。キャッシュに保存されているNXDOMAINは拒否された名前用であり、必ずしもQNAME用ではありません。

これらの規則の結果の例として、存在しないドメイン ‘foo.example’を持つリゾルバに対する2つの連続した問い合わせを考えてみましょう。1つ目は ‘foo.example’（NXDOMAINにな​​ります）に対するもので、2つ目は ‘barに対するものです。 foo.example ‘（これもNXDOMAINにな​​ります）。今日の多くのリゾルバは両方の問い合わせを転送するでしょう。ただし、このドキュメントの規則（「NXDOMAINカット」）に従うと、リゾルバは最初のNXDOMAIN応答を存在しないことを示す記号としてキャッシュしてから、権限のあるサーバーに送信せずにすぐに2番目のクエリに対するNXDOMAIN応答を返します。

最初のリクエストが「bar.foo.example」に対するもので、2番目のリクエストが「baz.foo.example」に対するものである場合、最初のNXDOMAINレスポンスは「baz.foo.example」について何も伝えません。したがって、2番目のクエリは、「NXDOMAINカット」最適化を使用する前と同じように送信されます（付録Aを参照）。

3. RFCの更新

3.1. RFC 1034への更新

この文書は存在しない名前から空の非終端（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段落目には、次のように記載されています。

名前エラー（NXDOMAIN）から生じた否定的な答えは、キャッシュされた否定的な応答をもたらしたのと同じものに対する別の問い合わせに応答してそれを取り出して返すことができるようにキャッシュされるべきである。

このドキュメントでは、この段落を次のように改訂します。 名前エラー（NXDOMAIN）から発生した否定的な回答は、キャッシュされた否定的な回答をもたらした別のクエリに対する応答として取得して返すことができます。 QNAMEは元のQNAMEの子孫であり、QCLASSは同じです。

上記のセクション2では、改訂された規則について詳しく説明し、それを緩和または無視することが妥当な場合があるかどうかを指定します。

4. 利点

主な利点はキャッシュの効率化です。上記の例では、リゾルバは2つではなく1つのクエリのみを送信し、2番目のクエリはキャッシュから回答されます。権威あるネームサーバは不要なトラフィックの処理が少ないため、これはDNSエコシステム全体に利益をもたらします。

正しい振る舞い（[RFC1034]にあり、この文書ではより明確にされている）は、NXDOMAINに遭遇するとすぐにリゾルバが検索を停止することを可能にするので、QNAME最小化[RFC7816]と組み合わされると特に役に立ちます。

“NXDOMAIN cut”はまた、存在しない固定サフィックスがあるところで、ある種のランダムQNAME攻撃[joost-dnsterror]と[balakrichenan-dafa888]を軽減するのを助けるかもしれません。信頼できるネームサーバに対するこれらの攻撃では、通常は存在しない固定接尾辞（上記の記事の1つでは “daf​​a888.wf”）と要求ごとに異なるランダムな接頭辞で構成されるQNAMEのリゾルバにクエリが送信されます。 。これらの要求を受け取ったリゾルバはそれらを信頼できるサーバに転送しなければなりません。「NXDOMAINカット」を使用すると、システム管理者はリゾルバに固定サフィックスのクエリを送信するだけでよく、リゾルバはNXDOMAINを取得してからクエリの転送を停止します。（NXDOMAINレスポンス内のSOAレコードが存在しないドメインを見つけるのに十分であれば、より良いでしょう。

5. 考えられる問題

トップレベルドメイン（TLD）の例が存在するが、foobar.exampleが委任されていないと仮定しましょう（そのため、例のネームサーバは、anything.foobar.exampleに関するクエリに対してNXDOMAINと応答します）。システム管理者は、office.foobar.exampleの下で自分の組織の内部マシンに名前を付けることにし、このリゾルバのトリックを使ってこのゾーンに関する要求をローカルの権威あるネームサーバーに転送します。「NXDOMAINカット」はここで問題を引き起こします。リゾルバへのリクエストの順序によっては、存在しないことを例からキャッシュしているため、その下のすべてを「削除」した可能性があります。この資料はそのようなセットアップがまれであり、サポートされる必要がないと仮定します。

今日、別の可能性のある問題が存在します。権威あるネームサーバが通常のNODATA（[RFC7719]、Section 3）の代わりにNXDOMAINでENT（[RFC7719]、Section 6）に返答するのを見ます。

そのようなネームサーバーは間違いなく間違っていて、いつもそうです。それらの振る舞いはDNSSECと互換性がありません。「NXDOMAINカット」の利点を考えると、この動作をサポートする理由はほとんどありません。

6. 実装に関する考慮事項

このセクションは規範的ではなく、実装者に役立つかもしれない様々なものだけで構成されています。再帰的リゾルバは多くの方法でそのキャッシュを実装するかもしれません。最も明らかなものはツリーデータ構造です。これはドメイン名のデータモデルに適しているからです。しかし、実際には、他の実装や、さまざまな最適化（ツリーなど、一般的なドメイン名のインデックスで強化されたものなど）も可能です。リゾルバがそのキャッシュを（最適化なしで）ツリーとして実装する場合、セクション2の規則に従う1つの方法は以下の通りです：NXDOMAINを受け取るとき、そのノードでポジティブキャッシュエントリのサブツリーを枝刈りするか、そのノードの下の名前。それから、キャッシュ内を下方向に検索するとき、この反復キャッシュDNSリゾルバは、キャッシュされた非存在に遭遇すると検索を停止します。

いくつかのリゾルバはツリーとして組織化されていない（しかし、例えば辞書として）キャッシュを持っているかもしれません。したがって、それらにはセクション2の規則を無視する理由があります。そのため、これらの規則はSHOULDを使用しており、してはいけません。

7. セキュリティ上の考慮事項

本書では説明されたテクニックはセクション4で説明された “random qnames”と名付けられたサービス拒否攻撃に対して助けるかもしれません。

リゾルバがDNSSECで答えを検証しない場合、またはゾーンが署名されていない場合、リゾルバはもちろん偽のNXDOMAINで汚染される可能性があるため、ドメイン名ツリーの一部を「削除」します。このDoS攻撃は、このドキュメントのルールがなくてもすでに可能です（ただし、「NXDOMAIN cut」はその効果を高める可能性があります）。唯一の解決策はDNSSECを使用することです。

8. 参考文献

8.1. 規範的な参考文献

8.2. 参考情報

  • [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, http://www.rfc-editor.org/info/rfc4035.
  • [RFC7719] Hoffman, P., Sullivan, A., and K. Fujiwara, “DNS Terminology”, RFC 7719, DOI 10.17487/RFC7719, December 2015, http://www.rfc-editor.org/info/rfc7719.
  • [RFC7816] Bortzmeyer, S., “DNS Query Name Minimisation to Improve Privacy”, RFC 7816, DOI 10.17487/RFC7816, March 2016, http://www.rfc-editor.org/info/rfc7816.
  • [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, http://www.michael-joost.de/dnsterror.html.
  • [balakrichenan-dafa888] Balakrichenan, S., “Disturbance in the DNS - “Random qnames”, the dafa888 DoS attack””, October 2014, https://indico.dns-oarc.net/event/20/session/3/ contribution/3.

付録A. 返されたSOAの所有者名をそのまま使用できないのはなぜですか。

この文書では、拒否された名前が正確なドメインであるNXDOMAIN回答に対してのみ、ドメインが存在しないことを推測します。リゾルバがwww.foobar.exampleのMail Exchange（MX）レコードを要求してTLDの例のネームサーバにクエリを送信し、その後NXDOMAINを受信した場合、www.foobar.example（）という事実のみを登録できます。そしてその下にあるものはすべて存在しません。これは、付随するSOAレコードがドメインの例専用であるかどうかにかかわらず当てはまります。foob​​ar.exampleが存在しないと推論することはできません。付随するSOAレコードは、最も近い既存のドメイン名ではなく、ゾーンの頂点を示します。そのため、権限セクションにSOAレコードの所有者名を使用して “NXDOMAIN cuts”を推測することは、現在のところ間違いなくOKです。

NXDOMAIN応答でSOAからノードが存在しないことを推測することは、ランダムなqnames攻撃には確かに役立つかもしれませんが、これはこのドキュメントの範囲外です。それはこのセクションの最初の段落で述べられた問題に取り組むことを必要とするでしょう。考えられる解決策は、ツリー内で1つ以上のラベルのSOAを持つNXDOMAINを受け取るときに、QNAMEとSOAの所有者名の間にあるドメインに対する要求を送信することです。（DNSSEC検証またはQNAME最小化を行うリゾルバはとにかくそれをする必要があるでしょう。）

付録B. 関連したアプローチ

文書[NSEC]は、同じ懸念のいくつかに対処するための別の方法（存在しないドメイン名のトラフィックを減らす）を説明しています。「NXDOMAINカット」とは異なり、DNSSECが必要ですが、クエリされなかったドメインに対してNXDOMAINを合成できるため、より強力です。

謝辞

このドキュメントの主なアイデアは、[DNSRRR]、セクション3、”Stopping Downward Cache Search on NXDOMAIN”から抜粋したものです。その作者、Paul Vixie、Rodney Joffe、およびFrederico Nevesに感謝します。さらに、Tony Finch、Ted Lemon、John Levine、Jinmei Tatuya、Bob Harold、Duane Wesselsから貴重なフィードバックや提案が寄せられました。