web-dev-qa-db-ja.com

DNSサーバーが不明なドメインのクエリにREFUSEDと応答することを推奨するRFCは何ですか？

この質問は、非常に不明なドメイン要求に応答するためにDNSサーバーに要求するRFC に似ています==しかし、私は尋ねるべきだと考えました新しい質問として。

権限のあるDNSサーバーは、サーバーが権限のないドメイン名のクエリに対してrcode REFUSEDで応答するのが標準的な方法であるようです。例えば：

$ Dig @ns1.google.com yahoo.com A | grep status
;; ->>HEADER<<- opcode: QUERY, status: REFUSED, id: 53533

ここで、アプリオリに意味のあるいくつかの代替動作があります。

  • クエリ全体をブラックホール化する
  • 権限のないNXDOMAIN応答を返します
  • 権限のないNOERROR応答を返します（これはばかげていますが、完全を期すために言及します）
  • ルートネームサーバーへの既定の参照を返します（これはさらに愚かです）

「この場合はREFUSEDを返さなければならない」というRFCまたは同様のドキュメントはありますか？

RFC 1034セクション4.3.1および4.3.2 でこの状況についての議論が見られると思いますが、私はそうではありません。

domain-name-systembinddns-zone
4
Quuxplusone

それは本当に簡単です、RFC1035セクション4.1.1 RCODE 5

Refused - The name server refuses to perform the specified operation 
for policy reasons.  For example, a name server may not wish to
provide the information to the particular requester, or a name server 
may not wish to perform a particular operation (e.g., zone transfer) 
for particular data.

システムの管理者は、何もせずにREFUSED応答を返すようにシステムを構成することを決定しました。

5
user9517

この特定のシナリオにどのように対処するかについて、標準ドキュメント（少なくとも元のDNS RFCではない）に完全な声明があるとは思いません。
とはいえ、長年にわたって、コンセンサスは多かれ少なかれREFUSEDが私たちが利用できるツールの中で最良のオプションであるということになってきました。

以下に、いくつかの異なるオプションについての考えを概説します。

質問で説明されているオプション

クエリ全体をブラックホール化する

これは、信頼できるサーバーのオペレーターにとっては悪いことです。このアプローチでは、サーバーがダウンしているように見え、QNAMEに関係なく、再帰サーバーが繰り返しクエリに応答せずに完全に諦めるシナリオが発生するシナリオが開かれます。

また、すぐにエラーが発生するのではなく、タイムアウトの期限が切れるまで待機する可能性があるため、クライアントの観点からも問題があります。

（私はこれを最悪の選択肢と考えます。）

権限のないNXDOMAIN応答を返します

これは、NXDOMAINの使用方法とは異なります。 NXDOMAINは、-名前が存在しないことを知っているであることを示すために使用されます。名前について何も知らないではありません。

権限のないNOERROR応答を返します（これはばかげていますが、完全を期すために言及します）

まず第一に、「ルートへの参照」の代替案は、これの特別なケースであることに注意します。

NXDOMAINに対する引数は、NODATA（権限セクションのNOERROR + SOA）にも適用され、わずかな調整のみが行われます。それはそのようなRRsetがないことを知っているであることを示すために使用されるステータスであり、知識が不足しているではありません。
さらに、NODATAは、この名前が何らかの形または形式で存在することを知っていることを示しています（たとえば、他のタイプのレコードがあるか、空の非終端記号である可能性があります）。

NOERRORは、クエリが有効で応答可能であると見なされたため、何らかの形式の応答が存在する必要があることを示します。これが答えられないクエリである場合、NOERRORは適切ではないようです。

ルートネームサーバーへの既定の参照を返します（これはさらに愚かです）

これは、これまでこれに対処するための非常に一般的な方法でした。回答の内容自体は役に立ちませんが、少なくとも照会されたサーバーがその名前を認識していないことを明らかにするのは、有効に形成された参照応答です。

（これはおそらく、このコンテキストでのNOERRORの使用の最も愚かな形式ではないと思います。）

別のオプション

ステータスREFUSED

REFUSEDは一般的に最良のアプローチと見なされ、サーバーがこのクエリに応答しないように構成されていることを示します。この特定のケースで使用する必要があることを明示的に要求されていないかどうかにかかわらず、全体的に適切です。

ステータスSERVFAIL

一部のサーバー実装でも使用されます。
回答が意図的でないことを明確に示していないという点で、REFUSEDよりも明確ではありません。 SERVFAILは通常、有効なクエリの処理中に発生した予期しないエラーに使用されます。

5
Håkan Lindqvist

これが このDynDNSブログの投稿 で始まる部分的な回答です。

ネームサーバーの観点からは、構成された応答能力（DNS pun！）以外の質問に答えるよう求められています。そのドメイン名のゾーンファイルがないため、応答するものはありません。次の RFC 1035 、準拠ネームサーバーは、RCODE 5（REFUSED）応答を発行する必要があります。これは、「ネームサーバーは、ポリシー上の理由で指定された操作の実行を拒否しました。」.

原則として、ネームサーバーが権限のない名前のクエリを受信するのは奇妙なことです。結局のところ、親からネームサーバーを委任するまさにその行為は、NSレコードによって名前が付けられたネームサーバーが正しいネームサーバーであると主張する（権威ある）ことです。 、歴史的に、多くのネームサーバーはルートへの紹介で応答しました。

今日、この回答はDNSオペレーターによって広く非難されているようです（一部は増幅攻撃に使用できるためです）、最近の多くのネームサーバーはエラーを返します。ネームサーバーがポリシー上の理由で指定された操作の実行を拒否したという理由で、エラーは多くの場合RCODE 5（REFUSED）です。 たまに、RCODE 2（SERVFAIL）が表示されます。これは、ゾーンがネームサーバーによってロードされている途中のときと同じ理由で表示されます。サーバーはまだクエリに実際に応答できず、応答できるかどうかもわかりません。

「ルートへの参照」をグーグル検索すると、DNS-OARCの出版物 "有害な上方参照"と見なされます ：

最近、ホスティング会社のISPrimeが、スプーフィングされたソースアドレスを使用したDNSベースのDDoS攻撃の犠牲になりました。 クエリ "。IN NS"がかなり小さい（47オクテット）一方で、上方参照応答が少し大きい（256オクテット）ため、これを増幅攻撃と呼ぶ人もいます。...攻撃によって古い議論が再び明らかになります：回答できないクエリに対する権威あるネームサーバーの適切な応答は何ですか？構成および/または一部の権威ネームサーバーを実装すると、ルートゾーンへの上方参照が返されます。いくつかの理由により、この動作を推奨しません。

  • 上向きの紹介は一般的に役に立たない。空間を反復しているリゾルバは、どこから始めればよいかをすでに知っています。
  • 適切な反復リゾルバーは、「bailiwickから」の上方参照を考慮し、とにかくデータを無視する必要があります。
  • 権限のあるネームサーバーのルートゾーンの「ヒント」は、適切に維持されていないと、時間の経過とともに古くなり、廃止されたルートサーバーアドレスにクエリが配信される可能性があります。
  • 上方参照は「参照ループ」を引き起こし、何百もの無駄なクエリを引き起こすことが知られています。

REFUSED応答コードは、上方参照よりも優れていると感じています...

また、 RFC 7719 （2015年12月発行）には次のように記載されています。

歴史的に、権限のないサーバーの多くは、権限のない名前を照会されたときにルートゾーンへの照会で応答しましたが、この方法は拒否されました。

したがって、「ルートへの参照」は明らかに恐ろしい考えですが、公平に言うと、それはすでに「最も愚かな」代替手段でした。権限のないNXDOMAINなどの何が問題になるのか、まだわかりません。この答えは後で更新するかもしれません。

3
Quuxplusone