エンドネットワーク機器は完全に構成でき、クラスター内の順序は完全です。トランクとアンロードされたネットワークコア機器は空の場合がありますが、DNSがうまく機能しない場合、クライアントは満足できません。
ここから簡単な結論が得られます-再帰DNSサーバーは常に利用可能であり、クライアント要求を処理できる必要があります。
生産的なDNSサーバーのセットアップに関するすべての記事は、次のようなものから始まります。「さまざまな再帰DNSサーバーのさまざまなパラメーターを測定し、それらから最適なものを選択してください。 幸福はこの方法によってもたらされると前もって言えるが、長くは続かない。
次のステップは、サーバー自体の容量を増やすことです。 この方法では、幸福も達成されますが、加入者ベースの安定した成長により、幸福はすぐに終わります。
あなたは、問題のどのような解決策が存在するか、より正確には、この状況で何をすべきかを尋ねますか？
答えは簡単です-各クライアントから特定のタイプの再帰クエリの数を制限する必要があります。 残念ながら、既存のDNSサーバーには、再帰クライアントごとに特定の種類のクエリの数を制限する手段がありません 。 このタスクをパケットフィルターに割り当てます。以下の例ではiptablesが使用されています。
ほとんどの場合、さまざまな種類のDNSクエリが、感染したクライアント、メールサーバーのIPアドレスを見つけることを目的とした膨大な数のMXクエリ、kljhajlhfqweqwe.comやioweurtisdvfso.orgなどのエキゾチックなドメインに対するタイプAクエリから発生します。
概算では、クライアントマシンの3％がすべてのDNSクエリの90％以上を生成しました。
単にクライアントに電話をかけるだけでは問題が解決しないことがあります。クライアントが自宅にいない、クライアントに資格がない、またはクライアントが単に扱われることを望んでいないからです（すべてがうまくいきます）。 また、多くの場合、クライアントポートを切断するときに、プロバイダーはDNSサーバーへのトラフィックを開いたままにして、クライアントが自分の名前で自分のアカウントにログインしてブロックの理由を確認できるようにしますが、クライアントコンピューターがDNSサーバーを「ドロップ」するため、この問題を解決する必要があります別の方法を探してください。
したがって、2つの簡単な問題を解決する必要があります。
1.処理するすべての有効なタイプのDNSクエリを決定します。
2.各クライアントからの各タイプのリクエストの適切な間隔を見つけます。
顧客からどのような種類のリクエストが送信される可能性があり、どのようなリクエストを処理すべきかを分析しましょう。
Aレコード（アドレスレコード）またはアドレスレコードは、ホスト名をIPアドレスに関連付けます。 最も「最も有用な」タイプのクエリ。 10秒で100リクエストの値は、「非常に高速」にサーフィンするクライアントでも十分に受け入れられます:)
AAAA（IPv6アドレスレコード）は、ホスト名をIPv6プロトコルアドレスに関連付けます。 IPv6は広く普及していませんが、このタイプのリクエストをDNSサーバーに任せて、各クライアントから10秒の2つのリクエストに制限し、AAAA localhostのような空のリクエストがあるようにすることができます。 DNSサーバーの動作には影響しませんでした。
CNAME（正規名レコード）または正規名レコード。 このタイプのリクエストはできるだけブロックされないように、リクエストタイプは便利です。ロックはソフトにする必要があります。 タイプAのリクエストの場合と同様に、10秒間に100リクエストが許容される値です。
MX（メール交換）レコードまたはメールエクスチェンジャーは、このドメインのメール交換サーバーを示します。 ホームクライアントの場合、これらの種類のレコードに対する激しい要求は、クライアントのコンピューターがスパムを送信するウイルスに感染していることを明確に示しています。 診断ユーティリティが機能するには、60秒で5つのクエリで十分です。
NS（ネームサーバー）エントリは、このドメインのDNSサーバーを指します。 直接、ホームインターネットサービスのユーザーはそのような要求を生成しません。ほとんどの場合、そのような要求は、nslookupなどの診断ユーティリティを介して手動で生成され、ドメインの状態などをデバッグします。
PTRレコード（ポインター）またはポインターレコードは、ホストIPを正規名でバインドします。 ホームインターネットサービスのユーザーに関して、このタイプの要求は、ダウンロード元および配布先のホスト名を解決するために、torrentまたはp2pクライアントの操作中に頻繁に受信されます。 たとえば、10秒間に50のリクエストは許容範囲内の値であり、ほとんどの場合、どのユーザーでも十分です。
SOA（権限の開始）レコードまたは初期ゾーンレコードは、このドメインに関する参照情報を保存するサーバーを示し、このゾーンの責任者の連絡先情報、ゾーン情報をキャッシュするタイミング（時間パラメーター）、およびDNSサーバーの相互作用を含みます。 このタイプのリクエストは、ホームインターネットユーザーがデバッグ目的でのみ使用できます。各クライアントが60秒で5つのリクエストを行うことを許可します。
SRV（サーバー選択）エントリは、サービス用のサーバーを指します。 このタイプのリクエストは、ホームインターネットユーザーがデバッグ目的でのみ使用できます。各クライアントが60秒で5つのリクエストを行うことを許可します。
ここでDNSレコードタイプの完全なリストを見ることができます 。
どのシグニチャで1つまたは別のDNSクエリを分類する必要があるかを理解するには、1種類のパケットでtcpdumpを「キャッチ」し、要求本文のTypeフィールドを見て、次のことを確認する必要があります。
MXタイプのリクエストには、フィールドタイプに含まれています-00 0F
タイプAAAAのリクエストには、フィールドタイプに含まれています-00 1C
タイプタイプリクエストに含まれるリクエスト-00 01
タイプPTRの要求には、フィールドタイプに含まれています-00 0C
タイプCNAMEの要求には、フィールドタイプに含まれています-00 05
タイプNSのリクエストには、フィールドタイプ-00 02が含まれます。
タイプSOAの要求は、フィールドタイプに含まれています-00 06
タイプSRVのリクエストには、フィールドタイプに含まれる-00 21
また、Typeフィールドの後のDNSクエリにはClassフィールドがあり、DNSクエリでは常に00 01であることに注意してください。 このフィールドをすべての署名に追加して、誤検知の数を減らします。
したがって、MXなどのDNSクエリをブロックするには、DNSサーバーにiptablesルールを追加する必要があります。
-A INPUT -p udp --dport 53 -m string --algo kmp --hex-string "|00 0F 00 01|" -j DROP
これらのリクエストを完全に閉じるのではなく、単位時間あたりのリクエスト数を制限して、これらのリクエストがサーバーに「送信」されないようにする必要があるため、最近のモジュールをルールに追加します。
たとえば、MXタイプのDNSクエリの受信を60秒で5クエリに制限するルールは次のようになります。
-A INPUT -p udp --dport 53 -m state --state NEW -m string --algo kmp --hex-string "|00 0F 00 01|" -m recent --set --name MXFLOOD --rsource
-A INPUT -p udp --dport 53 -m state --state NEW -m string --algo kmp --hex-string "|00 0F 00 01|" -m recent --update --seconds 60 --hitcount 5 --rttl --name MXFLOOD -j DROP
-A INPUT -p udp --dport 53 -m string --algo kmp --hex-string "|00 0F 00 01|" -j ACCEPT
他の種類のDNSクエリも同様に制限されています。
非常に多くの種類のDNSがあり、必要なすべての種類のDNSクエリを解決しているため、DNSサーバーによって処理されないように他のすべてのクエリを禁止するとよいでしょう。
-A INPUT -p udp --dport 53 -j DROP
これらの単純なルールにより、ユーザーからのDNSの操作に関する苦情なしに、DNSサーバーへの同時再帰DNSクエリの数を20倍（10,000から400）減らすことができました。