/etc/hosts のエントリが VPN の DNS に届かない理由

/etc/hosts に名前を追加し、VPN に接続すれば、そのレコードが全員に見えるはずだと考えました。そうはならず、驚きはたいてい二つ目の症状を伴います。名前は自分のマシンでは解決するのに同僚のマシンでは失敗し、壊れた VPN DNS サービスのように見えますが、実際には hosts ファイルが設計どおりに動いているだけです。hosts ファイルはローカルな名前解決の設定であり、ゾーンの更新ではなく、通常の VPN 接続でそれがアップロードされることはありません。

hosts はローカルの上書きであり、ゾーンの更新ではない

このファイルは、名前サービスライブラリが DNS サーバーに問い合わせる前に、あるいはその代わりに参照する対応表です。10.40.0.20 build.corp.example のような一行は、その一台のマシン上のアプリケーションが下す結論を変えます。レコードを作るわけでも、トンネルを通るわけでもなく、トンネルが指す DNS サーバーはその存在を一切知りません。

だから失敗は非対称になります。あなたのクライアントはファイルから答えを得ます。別のクライアントは VPN の DNS サーバーに問い合わせ、サーバーは何も返さず、アプリケーションは名前が存在しないと報告します。どちらのマシンも正しく動いており、片方だけがもう片方の知らない上書きを持っているのです。

二つのコマンド、二つの異なる部品

この議論を止める最短の方法は、違いを二つのコマンドで見える形にすることで、どちらも hosts のエントリがあるクライアントで実行します：

getent ahosts build.corp.example
dig @10.40.0.53 build.corp.example A

一つ目はシステム自身の参照経路に問い合わせるもので、一般的な glibc システムでは DNS より先にローカルファイルを読みます。二つ目はそのアドレスのサーバーに DNS クエリを直接送り、ローカルファイルは一切参照しません。一つ目があなたのエントリを返し、二つ目が NXDOMAIN を返せば、レコードが DNS に存在せず、あなたのマシンがローカルの上書きから答えていることが証明されます。

順序は設定可能で、特定のディストリビューションについて何かを結論づける前に /etc/nsswitch.conf の hosts: 行を見て確認する価値があります。hosts: files dns はファイルを先に参照します。順序を変えるためだけにその例を動作中の設定にコピーしないでください。実際のシステムは、例にない追加のソースや条件付きのサービスエントリをしばしば列挙するからです。

systemd-resolved はテストを曖昧にする

systemd-resolved を使うシステムでは、ローカルのスタブも hosts データベースの名前を提供します。そのため 127.0.0.53 への問い合わせは、DNS クエリのように見え、そう振る舞っても、リモートサーバーの独立したテストにはなりません。リゾルバーが何を知り、どのサーバーに問い合わせるかは、次で確認できます。

resolvectl query build.corp.example
resolvectl status

status の出力はリンクごとの DNS サーバーを示すので、VPN リンクがそもそもリゾルバーを受け取ったかどうかが分かります。この問いは hosts のエントリとは別で、プライベート名が一人ではなく全員で失敗するときに問う価値のあるものです。

アプリケーションはさらに別の層を加えられます。独自の DNS-over-HTTPS 設定を持つブラウザー、独自のリゾルバー設定を持つコンテナー、プロセスの生存期間中ずっと参照結果をキャッシュするランタイムは、それぞれシステムとは違う答えを返せます。一つのコマンドがマシン上のすべてのプログラムを説明すると仮定せず、気にしているアプリケーションを実際に試してください。

VPN をまたいで名前を共有するのは何か

プライベート名が全員に対して機能する必要があるなら、全員のリゾルバーが到達できる所有者が必要です。きれいな答えは、レコードを管理ゾーンに公開し、そのゾーンを意図した VPN DNS 経路で解決可能にすることです。そうすればレコードには単一の真実の源、監査証跡、ライフサイクルが生まれ、どのノート PC がローカルの上書きを抱えているかを覚えておく必要はありません。

hosts ファイルを配布することは正当な代替手段であり、それは名前サービスではなくエンドポイント管理です。それを選ぶなら、ファイルはフリートを管理する何かによって配備・版管理・削除される必要があり、設計でもそのように記述すべきです。「VPN がやってくれる」はそのプロセスの説明ではありません。

動的 DNS 登録は三つ目の仕組みで、独自の権限、更新の認証、レコードの寿命を持ちます。それは hosts のエントリから生じるものではなく、クライアントが単につなぐことからも生じません。サーバーとクライアントの両方がそのように設定されている場合を除きます。ひとりでに現れるレコードは、誰かが安全な更新を有効にし、クライアントが自分自身を登録している証拠であり、その設定はトラブルシューティングのスレッドではなく設計記録に属します。その設定の所有者を誰も言えないなら、自動レコードは未検証として扱い、管理ゾーンを真実の源として保ってください。

解決した名前は経路ではない

名前解決と到達可能性は別のもので、古いローカルの対応づけはそれらを混同する典型的な方法です。移動したアドレスを指す hosts のエントリは、DNS が修正されたずっと後まで古いホストを選び続け、症状は問題なく解決する名前のルーティング障害のように見えます。

ですから「名前は解決するがサービスに到達できない」という報告のときは、システムの参照と VPN の DNS サーバーへの明示的なクエリを比べ、次に得たアドレスをサービスが実際に使っているアドレスと照合してください。systemd-resolved のリファレンスは、それが参照するローカルのソースを文書化しており、その比較に必要な地図はこれです。

そのうえで、上書きをその所有者を通じて直してください。自分の hosts ファイルから一行を消しても、配備スクリプトから同じ一行を受け取った十二台のノート PC には何の効果もありません。人々が実際に抱えているのはこの問題のその版なのです。