DNSサーバーが不明なドメイン要求に応答することを要求するRFC
現在、ドメインレジストラーとDNSプロバイダーは、不明なドメインへのDNS要求を無視しています。無視とは、ブラックホールを意味し、応答しないことを意味します。これにより、DNSクライアントとリゾルバーライブラリが再試行し、バックオフし、最終的にタイムアウトします。
Dig @NS3.DNSOWL.COM somedomainthatdoesntexist.org
...
;; connection timed out; no servers could be reached
他の一般的なドメインネームサービスを調査すると、他のプロバイダーがRCODE 5（REFUSED）を返すため、この動作はかなりユニークであることがわかります。
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をすぐに返すことは、リクエストをサーバールームのフロアにドロップするだけではなく、適切なIMHOです。
サーバーが応答しないことについてプロバイダーに不満を言うと、サーバーが違反しているというRFCを引用するように求められます。彼らのサーバーがすべてのリクエストに応答する必要があることを証明するように彼らが私に頼んでいるのは奇妙なことですが、そうです。
質問：
- 要求IDが重複していないか、何らかのDOS応答がない限り、サーバーは常に要求に応答する必要があるというのが私の規定です。これは正しいです？
- 私の規定をサポートするために、どのRFCおよび特定のセクションを引用する必要がありますか？
私にとって、DNSクエリに応答しないことは悪いことです。ほとんどのクライアントは、バックオフしてから、同じクエリを同じDNSサーバーまたは別のサーバーに再送信します。これらはクライアントの速度を低下させるだけでなく、信頼できるネームサーバーとNSエントリに応じて、自分または他のサーバーによって同じクエリが再度実行される原因になります。
RFC 1536 および 2308 では、パフォーマンス上の理由から、および同じクエリの再送信を停止するために、ネガティブキャッシングに関する多くの情報が表示されます。 4074 では、RCODEが0の空の応答を返すことに関する情報が表示されるため、クライアントは、空の応答の別の例であるA RRについてクライアントに問い合わせる必要があるipv6情報がないことを認識します。
しかし、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は現在、このトピックを詳細にカバーする Draft BCP があることを私たちに伝えました。これを引用として使用するのは少し時期尚早ですが、コミュニティの合意がここで表現されているものと一致することを強調するのに役立ちます。特に：
ネームサーバーが攻撃されていない限り、次の委任の結果として、ネームサーバーはそれに向けられたすべてのクエリに応答する必要があります。さらに、コードは、サーバーがゾーンを提供するように構成されていない場合でも、サーバーへの委任がないと想定してはなりません。壊れた委任はDNSでよくあることであり、サーバーが構成されていないゾーンのクエリを受信しても、必ずしもサーバーが攻撃を受けていることを示しているわけではありません。親ゾーンのオペレーターは、委任するNSレコードが委任されたゾーンのレコードと一致していることを定期的にチェックし、それらが[RFC1034]でない場合は修正する必要があります。これが定期的に行われている場合、壊れた委任のインスタンスははるかに低くなります。
この回答は、このドキュメントのステータスが変更されると更新されます。
ドメインの権限のあるDNSを新しいプロバイダーに移動する場合、ドメイン登録（whois）情報を変更する前に、常に（常に！）新しいプロバイダーに対して明示的にテストする必要があります（そして、プロバイダーが正確で構成されたレコードを送信していることを確認してください）。新しい権限のあるDNSサーバーを指すようにします。
おおまかに言うと、実行する手順は次のとおりです。
- 新しいDNSプロバイダーですべてを設定します。すべてのゾーンを作成して設定する必要があります。
新しい権限のあるサーバーが正しく機能していることを確認します。それらを明示的にクエリします。
Dig @new-ns.example.com mydomain.comあなたの質問から、彼らはこれらのクエリに応答していないというのはどのように聞こえますか？しかし、現時点では存在しないはずの「不明なドメイン」と言ったので、システムで完全に構成されているはずです（構成したレコードで応答しているはずです）。
ただし、haveがすでにシステムでドメインを構成している場合、この時点で正しいレコードで応答している必要があります。そうでない場合、彼らはゾーンを適切にホストしていないので、あなたは彼らに怒鳴るべきです。構成していないドメインに応答するかどうかは重要ではありません。 （まだ私があなたの言っていることが何とか欠けている場合は、私に知らせてください）。
- 権限のあるネームサーバーをドメインレジストラー（whois）に切り替えて、古いDNSプロバイダーを、トラフィックに影響がなくなるまで（少なくとも24時間）稼働させておきます。
新しいプロバイダーが切り替え前にレコードを設定できない場合、それらがどのように応答するかは実際には問題になりません-クエリを完全に拒否する権限を持つユーザーをユーザーに指示すると、ドメインと同じようにダウンタイムが発生します。まったく応答がない。