予期しない RCODE(SERVFAIL) により bind がクラッシュしますか?

Question

2 日おきに、サーバーがサービスにまったく応答しなくなります。ping は実行できますが、SSH は使用できないため、ホストのコントロール パネルを開いてリセットする必要があります。

再起動すると、/var/log/messages 内のクラッシュ前の最後のログ エントリは次のようになります。

名前付き[3493]: 予期しない RCODE (SERVFAIL) が '3.39.148.159.in-addr.arpa/PTR/IN' を解決しました: 193.0.0.193#53

これは DoS 攻撃の一部でしょうか? このサーバーではバインドを設定していませんし、設定する必要はないと思いました (それがいかにナイーブなことであっても)。

Answer 1

まず質問です。実際にバインドを外部からアクセス可能にする必要がありますか? そうでない場合は、DNS ポートの着信トラフィックをブロックするだけで準備完了です。

しかし、間接的にはこれは「攻撃」の一部です。おそらく、メール サーバーは「ユーザーが見つかりません」というメールを偽のサーバーに返送しようとしているからです。

また、あなたのマシンでは spamassassin が動作していますか? スパムの波に見舞われ、perl spamassassin がすべてのメールを処理しようとすると、運の悪い構成ではシステムがダウンする可能性があります。

Answer 2

その syslog エントリは、おそらく、マシンが接続したばかりのホストの IP を検索しようとしているものです。IP からホスト名へのマッピングに使用されるツリー193.0.0.193の一部に対して権限を持つ RIPE の DNS サーバーの 1 つです。in-addr.arpa

それは極めてありそうにないこれらの DNS クエリがマシンのクラッシュの原因である可能性は低いです。むしろ、間接的に DNS ルックアップを引き起こしている受信トラフィックによるリソースの浪費である可能性の方がはるかに高いです。

サーバーが外部に提供している受信サービスを確認し、それらの受信接続ごとに DNS ルックアップをリアルタイムで実行する必要があるかどうかを判断することが最も役立ちます。

たとえば、これが Web サーバーである場合、ログファイルにホスト名を保存せず、リモート IP アドレスのみを保存します。その後、必要に応じてオフラインでホスト名を追加します。

Answer 3

bind のバージョンは何ですか? また、サーバーの tcpdump を実行して、クエリが到着したときにそれをキャッチすることは可能ですか? bind がマシン全体を強制終了していたとしたら驚きですが、ログ内の上記のエントリの前に何か興味深いものはありますか?