MagicDNS がデバイスを解決してもオフィスのホスト名を解決しない理由

MagicDNS は tailnet 内の各デバイスに、そのマシン名と tailnet の DNS ドメインから導いた名前を与えます。その名前は Tailscale が作成し、Tailscale のリゾルバー経路で応答されます。files.office.example のようなオフィスのホスト名は、Tailscale が一度も書いたことのないゾーンに属するため、デバイスの名前を変えても作成できません。二つの名前空間は共存しており、所有者が違うだけです。

その仕組みは非常によくある報告の背後にあり、Tailscale のホストは応答するのに、ファイルサーバーは依然として解決エラーを返すというものです。

二つの名前空間、二人の所有者

デバイス名はマシン自身のホスト名から生成され、衝突は Tailscale が解決し、結果は tailnet ドメインの下に存在します。オフィスゾーンはオフィスのリゾルバーを運用する人が維持し、レコードは管理者または動的登録によって作成されます。短い名前は違いを隠します：files はオフィスの DNS が応答する検索サフィックスの展開かもしれず、tailnet のデバイスかもしれず、何でもないかもしれません。完全な名前を問い合わせれば、どのシステムが実際に応答したかが分かります。

サブネットルーターのマシン名を変えてもオフィスゾーンには何の効果もありません。Tailscale のデバイスを一つ改名するだけで、オフィスサーバーのレコードは手つかずのままなので、改名して再試行しても決して一致しません。

オフィスゾーンをそのリゾルバーに向ける

Tailscale の分割 DNS は、選んだドメインの問い合わせを指定したネームサーバーへ送り、それ以外は残りのポリシーに従います。追加するのは、オフィスのリゾルバーが実際に提供するドメインであり、たまたま入力した検索サフィックスではありません。検索サフィックスはクライアントに何を付けるかを伝えますが、リゾルバーにどこを見るかは伝えません。この二つの設定はコンソールでは似て見えますが、まったく違う動作をします。

制限されたネームサーバーは、関連付けられたドメインに対して権威を持つ必要があり、そうでなければ応答はアドレスではなく委任になります。

到達性は解決より先に来る

クライアントはそのネームサーバーにも到達しなければなりません。プライベート LAN 上のリゾルバーなら、サブネットルートを広告して受け入れ、アクセスポリシーが問い合わせを許可し、戻り経路が存在する必要があります。管理コンソールの正しい DNS アドレスは、設定が保存されたことだけを証明します。パケットがリゾルバーに届かない場合の症状はタイムアウトで、そのようなレコードはないという権威ある応答とは見え方が違います。

その違いは診断的です。タイムアウトはルーティングかポリシーを指し、即座の否定応答はレコードかゾーンを指します。どの DNS 設定を変える前に、どちらが返るかを読み取ってください。

名前の失敗とサービスの失敗を切り分ける

リソースがプライベートアドレスでは応答するがホスト名では応答しないなら、調査は DNS にとどまります。どちらも動かないなら、到達できないアドレスに解決する名前は前進ではないので、まずルーティングかサービスを直してください。完全な名前を問い合わせ、どのサーバーが応答したかを記録してください。 macOS では一部のコマンドラインツールが通常のアプリケーションと別の経路をたどるため、ターミナルの dig とブラウザーが同じ名前について食い違うことがあります。

デバイスの通常のモードがそれなら、出口ノードを選んだ状態でテストを繰り返してください。出口ノードの DNS 処理は出口なしの構成とは異なり、一つのモードだけで試すと、利用者が実際に見る失敗を見逃すことがあります。

ゾーン、リゾルバーのアドレス、問い合わせを運ぶルートを記録してください。この三つがあれば、もう一度改名を繰り返さなくても、MagicDNS の驚きのほとんどを説明できます。