プロキシコンテナが DNS コンテナを自動的に使わない理由

プロキシと DNS サーバーを同じ Docker ホストで動かしても、両者の DNS 経路はつながりません。重要なのは三つの別々の関係です。

• ネットワーク到達性。 別々の Compose プロジェクトは通常、別々の既定ネットワークを持ちます。サービスは適切な共有ネットワークに置きます。同一プロジェクト内でも、プロジェクト間で明示的に共有するネットワークでもかまいません。
• サービスディスカバリ。 カスタム Docker ネットワークの組み込み DNS はコンテナ名を解決できます。これによりアプリケーションは隣接サービスを発見できますが、その隣接サービスを DNS リゾルバとして自動的に選ぶわけではありません。
• リゾルバの選択。 プロキシコンテナ内で使われるリゾルバを特定します。Compose の dns フィールドは DNS サーバーのアドレスを受け取ります。アプリケーション内で解決できる dns.local のような名前は、そのフィールドの有効な値にはなりません。

クエリをプロキシコンテナから設定済みのリゾルバアドレスまで追跡します。そのアドレスに経路と DNS リスナーがあることを確認します。ホストのポート 53 を公開するとホスト側のアクセス経路ができますが、コンテナにそれを使えと指示するわけではありません。ネットワークを共有するコンテナは、代わりに直接通信できる場合があります。

設定が DNS コンテナのアドレスを参照しているなら、互換性のある IPAM 設定のもとで安定させてください。昨日のコンテナからコピーした動的割り当てアドレスは、再作成時に失敗することがあります。リゾルバの上流経路も確認してください。応答のないクエリを自分自身へ転送すると、到達不能なリゾルバとは別の障害になります。

最後に、宛先を誰が解決するのかを特定します。CONNECT 名を解決する HTTP プロキシはこのコンテナ経路を使えますが、ローカルで解決する SOCKS クライアントは使えないかもしれません。ホストでの検索はホストの経路を示すのであって、プロキシプロセスの経路を示すものではありません。