セルフホスト型アプリで断続的にDNS障害が発生する原因は何ですか？

断続的なDNS障害は、アプリのリゾルバパスが変わる、タイムアウトする、過負荷になる、または一貫性のないキャッシュされた回答を返すときに発生します。

セルフホスト環境では、失敗した名前解決はアプリケーションランタイム、コンテナのDNSスタブ、ホストのリゾルバ、ルーター、Pi-holeやAdGuard Home、VPNポリシー、そして上流のパブリックまたは権威サーバーを経由する可能性があります。ホストからのブラウザテストだけではアプリが同じパスを見ているか証明できないため、診断は影響を受けたコンテナやサービス内で失敗した名前解決をキャプチャし、同時刻の成功したクエリと比較する必要があります。

影響を受けたアプリ環境内で失敗したクエリをキャプチャする

正確なホスト名、エラーテキスト、タイムスタンプ、コンテナまたはプロセス、失敗が内部名、パブリック名、または両方に影響するかを記録します。ホストレベルのテストだけに頼らず、影響を受けた環境内から繰り返し名前解決を実行してください。

Kubernetesの問題では、最初のDNSクエリがタイムアウトし、後続のクエリは成功する断続的な障害が報告されています。このパターンは、障害後の1回の成功した名前解決だけでは一時的なリゾルバ障害を説明できない理由を示しています。

クエリの所要時間、返されたサーバー、応答コード、再試行結果をログに記録します。1つの名前だけが失敗する場合はそのゾーンや権威を調査し、すべての名前が同時に失敗する場合はローカルスタブ、上流リゾルバ、またはネットワーク経路に注目してください。

ホストのDNSとコンテナやサービスのDNSを比較する

コンテナ、VM、またはアプリのサンドボックス内のリゾルバ設定を調査し、ホストのアクティブなDNSサーバーと比較します。コンテナランタイムはホストのリゾルバを直接公開せず、埋め込みスタブや生成されたresolv.confのコピーを提供する場合があります。

HashiCorpのコミュニティケースでは、ホストのsystemd-resolvedリスナーがブリッジから到達できず、コンテナ内でDNSが動作しなかったため、コンテナが問い合わせ可能なアドレスに追加のリゾルバリスナーが必要でした。

両環境から設定されたネームサーバーに直接クエリを実行します。ホストが成功しコンテナがループバックや到達不能なスタブに対してタイムアウトする場合は、アプリを繰り返し再起動するのではなく、ブリッジから見えるリゾルバパスを修正してください。

内部ゾーンの障害とパブリックDNSの障害を分離する

同じ障害期間中に安定したパブリック名と必要な内部サービス名の両方をテストします。内部のみの障害はスプリットDNS、検索ドメイン、ローカル権威レコード、または条件付き転送を示し、両方の障害は再帰的な経路の問題を示します。

Dockerフォーラムの報告では、一貫して解決されるはずのDNSがビルド中に明確なパターンなく失敗したと記述されています。したがって、アプリのネットワーク自体が到達可能でもコンテナのDNSは失敗することがあります。

パブリック名が機能し内部のアプリ名が失敗する場合は、ローカル権威サーバーに直接クエリを実行し、短い検索サフィックス名ではなく完全なドメイン名を使用してください。両方が失敗する場合は、既知のリゾルバを使ってローカルフィルターを一時的にバイパスし、障害が上流かホームネットワーク内かを特定します。

Featured

ZimaCube 2 パーソナルクラウドホームNAS

ZimaCube2

$799.00 - $2,499.00

Buy Now

リゾルバのタイムアウト、負荷、UDPとTCPの挙動を測定する

チェーン内の各リゾルバに対して繰り返しタイムドクエリを実行し、UDPとTCPを比較します。パケットロス、応答時間、SERVFAIL、タイムアウト、切り捨て、障害がバックアップジョブ、フィルタ更新、高CPU使用時に一致するかを追跡します。

断続的なDNSトラブルシューティングガイドでは、障害発生時にキャプチャし、リゾルバの不安定性とネットワーク損失を分離し、複数のDNSサーバーを同時に変更しないことを推奨しています。

1つのリゾルバがタイムアウトし他が即座に応答する場合は、アプリのパスを固定し、失敗するリゾルバを交換または修理してください。コンテナからすべてのリゾルバが同時に失敗しホストは成功する場合は、ブリッジ、ファイアウォール、conntrack、名前空間の挙動を確認します。

DHCP更新、VPNポリシー、リゾルバの時間経過による変化を確認する

DHCP更新、VPN接続の変更、ホストのスリープ、ルーター再起動、コンテナ再作成の前後でDNS設定を比較します。断続的な障害は多くの場合、リゾルバや検索ドメインを静かに置き換えるライフサイクルイベントに続きます。

Dockerユーザーは、あるランダムな問題をDHCPリース更新に、別の問題をDockerとTailscaleの相互作用に起因すると特定しました。このようなタイミングの証拠は、リゾルバがランダムに失敗すると仮定するよりも強力です。

イベントの前後でリゾルバリスト、ルート、検索ドメイン、VPN状態を保存します。DHCP、NetworkManager、systemd-resolved、VPNクライアント、コンテナランタイムなど、これらを書き換える原因を修正し、内部名に応答できないパブリックリゾルバをハードコーディングするのは避けてください。

元の障害期間を通じて修正を検証する

通常障害が発生する間隔より長く、アプリ環境内からスケジュールされた名前解決を実行します。使用したリゾルバ、遅延、応答コード、アプリレベルの結果をログに記録し、成功したコマンドラインクエリだけを記録するのは避けてください。

ZimaSpaceのNASホスト名の不一致解決ガイドは隣接するクライアント側の問題を扱っていますが、このアプリ中心のテストはコンテナとランタイムが意図したリゾルバを継続的に使用していることも証明しなければなりません。

問題は、元のアプリ操作がルーター再起動、リース更新、コンテナ再作成、VPN状態の変更を通じて完了したときにのみ解決されます。再起動が単にタイマーをリセットするだけなら、修理として受け入れず、障害発生時の状態収集を続けてください。