DNSサーバーが不明なドメイン要求に応答することを要求するRFC

現在、ドメインレジストラーとDNSは、不明なドメインへのDNS要求を無視します。無視するということは、ブラックホールを意味し、応答しないことを意味します。これにより、DNSクライアントとリゾルバライブラリは再試行、バックオフ、最後にタイムアウトします。

dig @NS3.DNSOWL.COM somedomainthatdoesntexist.org
...
;; connection timed out; no servers could be reached

他の一般的なドメインネームサービスを調査すると、他のプロバイダーは5（拒否）のRCODEを返すため、この動作は非常にユニークです。

dig @DNS1.NAME-SERVICES.COM somedomainthatdoesntexist.org
dig @NS-284.AWSDNS-35.COM somedomainthatdoesntexist.org
dig @NS21.DOMAINCONTROL.COM somedomainthatdoesntexist.org

すべて次のようなものを返します。

;; ->>HEADER<<- opcode: QUERY, status: REFUSED, id: 64732

または

;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 31219

サーバールームのフロアにリクエストを単にドロップするのではなく、返すREFUSEDかNXDOMAINすぐに返すことが適切です。

サーバーが応答しないことについてプロバイダーに不平を言うと、サーバーが違反しているというRFCを引用するように頼まれます。サーバーがすべての要求に応答する必要があることを証明するように彼らが私に求めているのは奇妙ですが、それはそうです。

質問：

• 私の規定では、リクエストIDが重複していないか、何らかのDOS応答がない限り、サーバーは常にリクエストに応答する必要があります。これは正しいです？
• 規定をサポートするには、どのRFCと特定のセクションを引用すればよいですか？

私にとって、DNSクエリに応答しないのは悪いことです。ほとんどのクライアントはバックオフし、同じクエリを同じDNSサーバーまたは別のサーバーに再送信します。クライアントの速度が低下するだけでなく、権限のあるネームサーバーとNSエントリに応じて、独自のサーバーまたは他のサーバーによって同じクエリが再度実行されます。

ではRFC 1536および2308 Iは、パフォーマンス上の理由と同じクエリの停止、再送信にネガティブキャッシュに関する多くの情報を参照してください。で4074私は、クライアントが空の応答の別の一例であるAのRRについて質問させなければならないのIPv6情報がありません知っているので、0のRCODEとの空の答えを返すの情報を参照してください。

しかし、おそらく暗示されているために、DNSサーバーが要求に応答する必要があるというRFCが見つかりません。

特定の問題は、ドメイン（および関連するDNSレコード）をサーバーに移行するとき、または新しいドメインをサービスに登録してから最初のX分後に発生します。権限のあるネームサーバーが変更されるまでに時間がかかります（最近ではかなり高速です）が、サーバーがDNSレコードの提供を開始します。この遅延時間中、DNSクライアントはサーバーが信頼できると考えますが、たとえリクエストがあったとしてもリクエストに応答しませんREFUSED。ラグは大丈夫ですが、DNS要求に応答しないという決定には同意しません。記録のために、私は彼らのシステムのこれらの制限を回避する方法を理解していますが、私は彼らとサービスを改善してDNSプロトコルとより一致するように彼らと協力しています。

助けてくれてありがとう。

編集：

これを投稿して私のプロバイダーにフォローアップしてから数ヶ月以内に、彼らNXDOMAINは未知のドメインに戻るようにサーバーを変更しました。

シェーンのアドバイスは正しい。カットオーバーを開始する前に、ある権限のあるサーバーから別の権限のあるサーバーにデータを移行できなかった場合、停止が発生します。その時点から何が起こったとしても、これはNSレコードを振った人によって開始された停止です。これは、より多くの人々があなたのプロバイダーにこの苦情をしない理由を説明しています。

そうは言っても、これはまだ興味深い質問であるため、ここでクラックを取ります。

DNSサーバーの基本機能は、RFC 1034およびRFC 1035のドキュメントでカバーされており、これらが集合的にSTD 13を形成しています。答えは、これら2つのRFCから得られるか、それを更新する後のRFCによって明確にされる必要があります。

続行する前に、ここで呼び出す必要があるDNSの範囲外に大きな落とし穴があります。これらのRFCはどちらも、BCP 14（1997）より前、MAY、MUST、SHOULDなどの言語を明確にした文書です。

• この言語が正式化される前に作成された標準は、明確な言語を使用している場合がありますが、いくつかのケースでは使用されていません。これにより、ソフトウェアの多様な実装、大量の混乱などが発生しました。
• STD 13は、残念ながらいくつかの分野で解釈的であるという罪を犯しています。言語が運用分野でしっかりしていない場合は、明確なRFCを見つけることが頻繁に必要です。

邪魔にならないように、RFC 1034§4.3.1の説明から始めましょう。

• サーバーの最も単純なモードは、ローカル情報のみを使用してクエリに応答できるため、再帰的ではありません。応答には、エラー、応答、または他のサーバーへの「より近い」参照が含まれます。すべてのネームサーバーは、非再帰クエリを実装する必要があります。

...

再帰サービスが要求されていないか利用できない場合、非再帰応答は次のいずれかになります。

• 名前が存在しないことを示す正式な名前エラー。

• 一時的なエラー表示。

• 以下の組み合わせ：

  質問に答えるRRと、データがゾーンから来ているのか、キャッシュされているのかを示す指標。

  応答を送信するサーバーよりも名前に近い祖先であるゾーンを持つネームサーバーへの紹介。

• ネームサーバーがリクエスタにとって有用であると考えるRR。

ここの言語はかなりしっかりしています。「あるべき」ではありませんが、「あるべき」です。つまり、最終結果は、1）上記のリストで定義されているか、2）機能を修正する標準トラック上の後の文書​​で許可されている必要があります。私は、要求を無視するために存在するそのような言い回しを認識していません。私は、研究を反証する言語を見つけるために開発者に責任があると言うでしょう。

ネットワークの悪用シナリオでDNSが頻繁に果たす役割を考えると、DNSサーバーソフトウェアがフロア上のトラフィックを選択的にドロップするためのノブを提供しないと言わないでください。ただし、これらはデフォルトの動作ではないか、非常に保守的なデフォルトです。両方の例は、ソフトウェアに特定の名前をドロップするように要求するユーザー（rpz-drop.）、または特定の数値のしきい値を超えている（BINDのmax-clients-per-query）場合です。私の経験では、ソフトウェアが標準に違反する方法ですべてのパケットのデフォルトの動作を完全に変更することはほとんど前例のないことです。ここではそうではありません。

要するに、このRFCはオペレーターの裁量で違反される可能性がありますが、通常、これは何らかの方法で行われます。特に専門家のコンセンサス（例：BCP 16§3.3）が誤ってDNSシステム全体に不必要な負荷をかけるのが望ましくない場合に、標準のセクションを完全に無視することは非常にまれです。信頼できるデータが存在しないすべての要求をドロップすることによる不必要な再試行は、これを念頭に置いて望ましくありません。

更新：

当然のことながら、クエリをフロアにドロップすることは望ましくないことについて、@ Alnitakは、現在このトピックを詳細にカバーするドラフトBCPがあることを共有しました。これを引用として使用するのは少し時期尚早ですが、コミュニティのコンセンサスがここで表現されているものと一致することを強化するのに役立ちます。特に：

ネームサーバーが攻撃を受けていない限り、次の委任の結果として、そのネームサーバーに向けられたすべてのクエリに応答する必要があります。さらに、コードは、ゾーンにサービスを提供するように構成されていなくても、サーバーへの委任がないと想定するべきではありません。壊れた委任はDNSでよく発生し、サーバーが構成されていないゾーンのクエリを受信して​​も、サーバーが攻撃を受けていることを示すとは限りません。親ゾーンのオペレータは、委任NSレコードが委任ゾーンのレコードと一致していることを定期的にチェックし、そうでない場合はそれらを修正することになっています[RFC1034]。これが定期的に行われている場合、壊れた委任のインスタンスははるかに低くなります。

この回答は、このドキュメントのステータスが変更されると更新されます。

ドメインの信頼できるDNSを新しいプロバイダーに移動するときは、ドメイン登録（whois）情報を変更する前に、常に（常に！）新しいプロバイダーに対して明示的にテストする（そして、正確な構成済みレコードを送信していることを確認する）必要があります新しい信頼できるDNSサーバーを指すようにします。

大まかに言うと、実行する手順は次のとおりです。

1. 新しいDNSプロバイダーですべてを設定します。すべてのゾーンを作成して設定する必要があります。

2. 新しい権限のあるサーバーが正しく機能していることを確認してください。それらを明示的に照会します。

   dig @new-ns.example.com mydomain.com
   

   あなたの質問から、彼らはこれらのクエリに応答していないように思えますか？しかし、あなたは「未知のドメイン」と言ったが、それはこの時点ではないはずであり、システムで完全に構成する必要がある（そして構成したレコードで応答する）。

   ただし、システムでドメインを既に構成している場合、この時点で正しいレコードで応答する必要があります。そうでない場合は、ゾーンを適切にホストしていないため、大声で叫ぶ必要があります。設定されていないドメインに応答するかどうかは重要ではありません。（あなたが言っていることをまだ何らかの形で見逃しているなら、私に知らせてください）。

3. 権限のあるネームサーバーをドメインレジストラー（whois）に切り替え、トラフィックがヒットしなくなるまで（少なくとも24時間）古いDNSプロバイダーを稼働させます。

切り替えを行う前に新しいプロバイダーがレコードを完全に作成できない場合、それらの応答方法は実際には重要ではありません-クエリを完全に拒否する権限のあるユーザーをユーザーにポイントすると、ドメインのダウンタイムが発生しますまったく応答がありません。