DNSサーバーのCPU使用率を理解するにはどうすればよいですか？
私は読んで理解しました キャパシティプランニングを手伝ってくれませんか？ ですが、DNSサーバーのシナリオでの次のステップが何であるかがわかりません。 I think CPUの負荷が高いか、クエリを削除し始めている可能性がありますが、アクションを実行する前に、サーバーの負荷をよりよく理解したいと思います。インフラストラクチャをDDoS負荷にスケーリングすることは戦いに負けていることは一般的な知識であるため、これは特に私にとって懸念事項です。
私の環境を理解するために何を分析する必要がありますか？
Serverfaultでは、通常、キャパシティプランニングを支援できないとお伝えします。これには正当な理由があります。私たちはあなたの環境の詳細を知りません、そしてそれを測定する方法に関する答えはほとんど同じです。残念ながら、DNS容量の測定は十分に理解されていないトピックであり、ほとんどの管理者は、CPU使用率が高いということは、容量の追加を検討する時期であると想定します。これは本当に、本当に悪い考えであり、DNS DDoSにスケーリングすると、必然的にネットワークデバイスが窒息することになります。 （さらに悪いことに、法務部門に連絡する人）
サーバーログとパケットキャプチャは、ほとんどの管理者が最初に活用しようとするものですが、単純な真実は、SNMPがログよりもはるかに多くの環境について教えてくれるということです。ignoreログとパケットキャプチャは行わないでください。ただし、SNMPは通常、問題の存在をより早く発見するのに役立ちます。
SNMP監視ツールによって提供されるデフォルトのシステム統計（CPU負荷、インターフェイスごとのスループットとパケットカウンター、ディスクI/Oなどを含む）を追跡することに加えて、次のOIDを追加することをお勧めします。
- DP-MIB
- キューエラーを受信する：
udpInErrors（怒っている赤い色を強くお勧めします） - UDPデータグラムカウンター：
udpInDatagrams、udpOutDatagrams - （オプション）予期しないデータグラム：
udpNoPorts
- キューエラーを受信する：
- TCP-MIB
- TCPセグメントカウンター：
tcpInSegs、tcpOutSegs
- TCPセグメントカウンター：
グラフの解釈
これらのグラフは、問題を示すメトリックと、問題の診断に役立つメトリックの2つのカテゴリにまとめることができます。
インジケーター
- 高いCPU使用率は悪いです。これは当然のことですが、それが発生した場合は、それを関連付けるために他のメトリックを探す必要があります。高いCPU使用率がアウトバウンドネットワーク使用率（スループットまたはパケット数のいずれか）の急上昇に対応している場合、DDoS攻撃で使用されている可能性はかなり高くなります。攻撃の性質を解釈する方法の詳細は、次のセクションにあります。
udpInErrorsは、容量の問題の主な兆候です。このカウンターは、アプリケーションがトラフィックを十分に高速に処理していないため、カーネルがUDPデータグラムをドロップするたびに増加します。これは、DNSサービスが過負荷になり、着信トラフィックに追いつくことができないことを意味します。- ほとんどのネットワークパフォーマンスガイドでは、受信キューのサイズを増やすことは正しい解決策ではないと説明しています。通常は正しい解決策です。他のグラフを確認するか、ログを分析して、whyサーバーが過負荷になっている理由を見つけてください。
- 会社がDNSBLテーブルを使用するメールサーバーを運用している場合は、 スノーシュー攻撃 がlegalDNSトラフィックに短いスパイクを作成してスペースを使い果たす可能性があることに注意してください受信キューにあります。これは、ソケット受信キューのサイズを増やす価値がある場合の1つです（これは既知の一時的な状態であるため）が、一般に、遅延を抑えるために、問題に対してより多くのハードウェアを投入することをお勧めします。
これらのメトリックの増加をシステム上の他のパフォーマンスの問題と関連付けることができない場合は、おめでとうございます。容量に合法的に近づいているか、容量を超えているので、サーバーを追加します。私が感銘を受けたと考えてください。 :)
診断
これはDNS固有のアイテムのみを対象としています。ここで頭を使ってください。これがすべてを含むとは思わないでください。 （例：ディスクI/Oの飽和はDNSに固有の問題ではありません）
- ビジーな再帰サーバーでは、アウトバウンドスループットは入力の2倍近くにとどまる必要があります。これは、通常、返信が関連するクエリよりもはるかに大きいためです。このレベルを大幅に超える持続的なスパイクは、サーバーが 増幅攻撃 に参加していることを示します。ほとんどの場合、 オープンリゾルバ を操作しています。
- 再帰DNSサーバーであっても、パケットインはパケットアウトとほぼ同じである必要があります。タイムアウトのためにクエリを再送信する必要がある場合がありますが、これはそれほど頻繁には発生しないため、グラフに大きな偏りが生じます。送信パケットの大幅な増加は、ネットワークの問題、または信頼できるネームサーバーに対する攻撃でクラスターが使用されていることを示しています。これは、必ずしもオープンリゾルバーを操作していることを示唆しているわけではありません。他のDNSサーバーが、キャッシュできないクエリを転送している可能性があります。
- インターフェイスごとのグラフに加えてUDP + TCP I/Oをグラフ化することをお勧めするのは冗長に思えるかもしれませんが、これらのグラフはインターフェイスに関連付けられておらず、十分な経験がある場合は進行中の攻撃の性質についての洞察も得られます。ネームサーバーソフトウェア。
補足：udpNoPortsはreally容量メトリックではありませんが、キャッシュポイズニングの試みを識別するのに役立ちます。このカウンタは、予期しないポートでUDPパケットが検出されるたびに増加し、通常の動作中にこれらの壁が持続する場合は、誰かが応答を偽造しようとしていることを示している可能性があります。 （それ、またはリスナーの1つが実行されていません：それをfooに戻します '！）
DNSサーバー（実際にはあらゆるタイプのサーバー）では、構成の誤り（おそらく他の場所）が要求量を増幅している場合に備えて、DNSサーバーから行われている要求を調べて分析する必要がある場合があります（たとえば、 WindowsDNSサーバーを繰り返し参照） SERVFAIL応答を受け取ったときにゾーン内のレコードを要求する ）。クエリと応答の比率を調べてから、正常性を確認するためのコンパレータを見つけてください。