BIND / DNSMASQクエリはUbuntu Server 14.04.1で中断されます。

BIND / DNSMASQクエリはUbuntu Server 14.04.1で中断されます。

私はVPSでBINDとDNSMASQの設定をテストしています。多数のクエリ(1秒あたり約10〜20個)を送信するプログラムを実行すると、DNS応答はランダムに戻りません。毎秒3つのクエリが送信されると、クエリはロックされません。

たとえば、

  • 45秒間照会して応答を受け取ることができます。しかし、突然5秒間返事が来ませんでした。
  • 15秒間質問して回答を受け取ることができます。それから突然10秒間返事を見ることができませんでした。

私は次のことを見て、何が起こっているのかを調べようとしています。

  • メモリ使用量
  • CPU使用量
  • バインドデバッグのシステムログエントリ
  • IPTABLESパケットストリームを観察して、iptablesが過度に多くのパケットを同時に処理できないことを確認してください。 (DNS要求が私のIPからのみ出るように制限し、すべてのポートの他のすべてのIP要求をブロックするiptablesルールがあります)
  • BIND と DNSMASQ をテストしました。

私が見るもの:

  • BIND と DNSMASQ にも同じ問題があります。
  • メモリ使用量は正常とマークされ、サーバーはプロセスを終了して再起動しません。
  • システム全体のCPU使用率は0.7%を超えません。
  • バインディングキャッシュサイズを制限しても、目立つ違いは発生しません。
  • 適切なルールでIPTABLESを観察すると、DNSクエリが応答を停止し、DNSログのローリングが停止すると、IPTABLES受信パケットが正常にストリーミングされることがわかりました。ただし、DNSログの停止中にIPTABLESに表示されるのは、IPTABLESルールの特定のIPに送信されたパケットが固定され、受信パケット全体が引き続きローリングされ、SSH端末ウィンドウが確実に更新され続けることです。全体として、着信パケットの数が増えることがわかります。
  • その後、すべてのIPTABLESルールの更新をテストし、iptablesルールを更新した後も問題がまだ存在することを確認しました。ところで、着信パケットの数を見ると、ルールがあるときと同様に、総数が増え続けることがわかります。

iptablesが着信パケットを十分に高速に処理できないかどうかはまだ100%不明ですか? (ルールがすべてフラッシュされても?)

この停止の原因は正確に何ですか?次は私をとても混乱させます。

  • SSH端末は、クエリが中断されている間にコンソール画面の更新/コマンドの実行に問題はありません。
  • クエリが中断されている間、他のプログラム(top / htopなど)も更新され続けます。
  • IP カウンタの独立したルールが大きくならない間、iptables 受信パケット カウンタ全体は引き続きローリングされます。

同時に、両方のIPでクエリ転送を試してテストすることはできませんでした(これは私が送信するDNSトラフィックを中断するISP /ルーターが原因である可能性があることを知っていますか?)。しかし、パブリックIPを介してルーティングされるネットワーク上の2つの異なるクライアントコンピュータからデータを送信しています。私はこれが可能な問題だとは思わない。

BIND と DNSMASQ は同じタイプの構成設定で同じ問題を抱えているため、問題がどこにあるかを把握することは困難です。バインディング/ dnsmasqの問題ですか、それともシステムのパケット処理の問題の種類ですか?

また、Google DNS 8.8.8.8を指すテストを行いましたが、同じ問題が発生しました。これは私のISP /ルーターと関係があるかもしれません。質問は、このように少ないトラフィックでルータ/ ISPがダウンする可能性がありますか?リクエストが早すぎる場合は、Google DNSがリクエストをブロックしていますか?

どんなアイデアがありますか?

私のVPSは、CPUコア1個、256MB RAM、10GB SSDです。システム使用量は通常約130〜160MBです。

ベストアンサー1

選択したDNSフォワーダ(ISPとGoogle)のレート制限です。

ルータ(状態保存ファイアウォール)の接続追跡により、テーブルがいっぱいになり、新しいDNS要求がNATテーブルのエントリに割り当てられず、転送されない可能性があります。ところで、VPSがあればNATを使わないようですね?

iptables非常に多数のパケットに問題はありません。毎秒数千の要求を持つ4Gbit / s以上のトラフィックを持つ非対称ルーティング設定に使用されています。conntrackテーブルが十分に大きいことを確認net/nf_conntrack_max = 524288してくださいsysctl.conf

外部フォワーダに依存しないように、BIND を独自の IP 用の再帰フォワーダとして設定すると便利です。次に、NATに役立つ可能性がある2つから3つではなく、さまざまなDNSサーバーにDNS要求を送信します。

おすすめ記事