ホストではDNS名前解決が機能するのに、コンテナ内では失敗するのはなぜですか？
ホストのDNSは機能しているのにコンテナのDNSが失敗する場合、コンテナが異なるリゾルバ経路、名前空間、ファイアウォールルート、またはDockerのフォワーディング状態を使用している可能性があります。
ホームサーバーでは、ホストがルーター、Pi-hole、またはVPNリゾルバに直接問い合わせる一方、ブリッジネットワーク上のコンテナはDockerの組み込みリゾルバやコピーされたresolv.confを介してリクエストを送信することがあります。最も早い診断方法は、まずIPアドレスをテストし、次に問題のあるコンテナから各リゾルバへ明示的に問い合わせることです。これにより、DNS障害を一般的な外向き接続障害と混同せずに済みます。
DNS障害と一般的なネットワーク障害を切り分ける
問題のあるコンテナから、ホスト名をテストする前に、既知の外部IPアドレスと、使用するDNSサーバーのIPアドレスをテストします。ルート、パケット損失、TCPおよびUDPの53番ポートに到達できるかどうかを記録します。
Manjaroコンテナの事例では、逆の結果が示されました。直接IPへの通信も失敗し、問題がDNSより広範囲に及んでいることが判明しました。この直接IP接続テストにより、リゾルバの変更によって壊れたブリッジ、NAT、またはファイアウォール経路が隠れてしまうのを防げます。
IP接続が失敗する場合は、まずコンテナのネットワークを修復します。IP接続は機能するものの名前解決に失敗する場合は、リゾルバの設定と問い合わせ経路を確認します。
コンテナ内のリゾルバ設定を確認する
コンテナ内の/etc/resolv.confを読み取り、ホストと比較します。ネームサーバーのアドレス、検索ドメイン、オプション、ネットワークモード、再作成後にファイルが変更されるかどうかを確認します。
OpenMediaVaultの事例では、ランタイム更新後にDockerの組み込み127.0.0.11リゾルバ経由のコンテナ内名前解決が失敗すると報告されました。この組み込みリゾルバ経路は、ホストでは名前解決に成功していても、異なる動作をする場合があります。
実行中のコンテナ内で生成されたファイルを恒久的に編集しないでください。意図したDNSサーバーと検索ドメインは、再作成後も維持されるよう、Composeまたはプラットフォームの設定に記述します。
Docker DNSと上流リゾルバを個別に問い合わせる
Dockerの組み込みリゾルバ、ルーターまたはローカルDNSサーバー、そしてポリシー上許可される場合は既知の外部リゾルバに対して、同じ名前解決を実行します。タイムアウト、拒否、NXDOMAIN、返されたアドレスを比較します。
TrueNASコミュニティの事例では、他のホスト通信が機能していたにもかかわらず、ルーターのアクセスプロファイルがコンテナからのリクエストをブロックしていたことが、コンテナだけで発生するDNS障害の原因でした。決定的な観察結果は、無効なホスト名ではなくコンテナ経路のDNSブロックでした。
上流リゾルバへの直接問い合わせは成功するのに組み込みリゾルバが失敗する場合は、Dockerのリゾルバとネットワーク状態を再起動または修復します。すべてのDNSサーバーがタイムアウトする場合は、53番ポートのルーティング、ファイアウォール、VPN、応答トラフィックを確認します。
ローカルDNSループと誤った内部応答を確認する
コンテナが、同じホスト上のDNSサービス、別のコンテナ、またはリバースプロキシ経由で自身に戻るホスト名へ問い合わせようとしていないか確認します。すべての名前解決が成功しているとは限らないため、返された応答を確認します。
Traefikコミュニティの事例では、あるコンテナがカスタムドメインを意図した接続先ではなく、自分自身へ解決していました。このコンテナ側の誤ったDNS応答は、基本的な名前解決テストには合格しましたが、API接続は失敗しました。
同じネットワーク上のコンテナ間通信にはサービス名を使用し、パブリックホスト名には、意図した戻り経路がある場合に限ってスプリットDNSを使用します。明示的にテストしていない限り、ローカルの依存サービスへ接続するためにコンテナからパブリックプロキシを経由するヘアピン経路は避けてください。
UDP応答、NAT、ネットワーク分離を確認する
コンテナのインターフェースとホストのブリッジで、53番ポートのトラフィックをキャプチャします。問い合わせが送信され、リゾルバが受信し、クライアントが想定するアドレスから応答が返っていることを確認します。
Pi-holeのユーザーからは、予期しない変換元から応答が返るため、同一ホスト上のコンテナからの問い合わせがタイムアウトする事例が報告されています。この予期しないDNS応答元により、応答を返さないリゾルバの問題と、応答経路の問題を区別できます。
リクエストと応答が異なるDockerネットワークを通過する場合は、すべてのサービスをホストネットワークに移すのではなく、正しい共有ネットワークまたはルートを追加します。ブリッジのサブネットがホストアドレスと異なる扱いを受ける可能性があるため、ファイアウォールゾーンとVPNポリシーを確認します。
ネットワーク状態を再作成して修正を検証する
リゾルバ、ファイアウォール、またはネットワーク定義を修正した後、意図したネットワーク上にテスト用コンテナを1つ再作成し、IP、直接リゾルバ、組み込みリゾルバ、サービス名、パブリック名のテストを繰り返します。
ZimaSpaceのアドレス障害と名前解決障害の切り分けガイドでは、ホスト側に隣接する診断の境界を確認できます。
DNS設定がコンテナの再作成と再起動後も維持され、内部サービス名と許可されたパブリック名が意図したアドレスを返し、同じネットワーク経路を通じてアプリケーション通信が成功して初めて、問題は解決したと判断できます。Dockerの更新後にのみ障害が再発する場合は、ランタイムの回帰が発生した境界を特定できるよう、バージョンとデーモンログを保存してください。
おすすめ商品
サポートとヒント
もっと読む
Plexは別のDockerコンテナとGPUを共有できますか？
Plexと別のコンテナは同じGPUにアクセスできることが多いですが、ドライバーのサポート、デバイスマッピング、ビデオエンジンの負荷、メモリ、復旧動作をテストする必要があります。
Plexのエラーがクライアント側とサーバー側のどちらに起因するかを見分ける方法
別のクライアントで同じ項目を再現し、セッションパスを比較してから、スコープによって障害の実際の所在が特定された後にのみサーバーの証拠を収集してください。
Plexのキャッシュとトランスコード用一時ストレージを設定する方法
永続的な Plex の状態を保護しつつ、トランスコードの一時ファイルを適切なローカルストレージに配置し、クリーンアップ、空き容量、再起動時の動作を確認します。
