resolvectl の出力からリンクごとの VPN DNS ルーティングを読む方法
resolvectl status はリンクごとにサーバー、ドメイン、デフォルトルートを示します。まとめて読み、次に名前を問い合わせて、どのリンクが応答したかを記録します。
resolvectl status を実行すると、リンクごとのブロックが壁のように並び、それぞれに独自のサーバーと独自のドメイン行があります。ルーティングを決めるのはドメイン一覧であり、ネームサーバーのアドレスではなく、ローカルのスタブがその名前を主張するリンクへ問い合わせを転送するからです。回答を読む前にそれらの主張を読み、次に名前を問い合わせて、どのリンクがそれを生成したかを確認します。正しいリンクからの誤った回答は、誤ったリンクからの正しい回答とは別の問題です。
リンクごとの各ブロックが示すもの
各ブロックは、リゾルバーがそのインターフェースに使うサーバー、ドメイン一覧、そしてそのリンクがデフォルトルートかどうかを示します。ドメイン一覧は主張の集合であり、リゾルバーは最長サフィックス一致を適用するので、host.corp.example への問い合わせは、デフォルトルートだけを持つリンクより先に、corp.example を持つリンクが主張します。同じサフィックスを主張する二つのリンクは結果を優先度と順序に委ねるため、重複にまず注意を向ける価値があります。現在のサーバー行は、一覧のうちどれがその時点で使われているかを示します。
/etc/resolv.conf の 127.0.0.53 のようなスタブアドレスは、スタブが前面にあることだけを告げます。応答した上流を名指ししないため、resolv.conf だけに基づく診断は行き詰まります。
三種類のドメインエントリを正しく読む
| エントリ | 何を主張するか | よくある誤り |
|---|---|---|
| corp.example | ルーティングドメインと検索サフィックス: その下の名前はこのリンクへ送られ、その文字列は裸の名前に付加されます | ルーティングはどのみち動くように見えるため削除された |
| ~corp.example | ルートのみ: その下の名前はこのリンクへ送られるが、サフィックスは付加されない | ルーティングに必要だと想定された |
| ~. | デフォルトルート: 他のどのリンクも一致しない問い合わせを主張する | 分割プロファイルで有効なまま残され、公開名がトンネルを通る |
チルダは検索の挙動を変えるのであり、ルーティングは変えません。チルダのないエントリはルーティングドメインと検索ドメインの両方であり、その下の名前はそのリンクへ送られ、単一ラベルの名前にはサフィックスが付加されます。チルダ付きのエントリは同じサフィックスをルーティングしつつ、検索一覧から外します。だからチルダを外すとどの裸の名前が解決されるかが変わり、だからチルダの欠落は分割 DNS の失敗ではなく検索の問題です。
デフォルトルートのエントリは、他のどのリンクも一致しないすべてを主張します。フルトンネルのプロファイルは通常それを望み、分割プロファイルは通常望みませんが、それは公開名が私設リゾルバーへ渡り、そこで失敗しうるからです。フラグをプロファイル間でコピーするのではなく、プロファイルの意図に照らして表を読んでください。二つのリンクが同じサフィックスを主張するときは、他を編集する前に優先度の問いを決着させてください。
名前を問い合わせて、どのリンクが応答したかを見る
query サブコマンドは、アドレス、プロトコル、そして回答を生成したリンクまたはスコープを出力します。私設サフィックスが主張すべき名前を一つと、普通の公開名を一つ試し、報告された出所を比べます。私設の名前が無線リンクから応答するなら主張が欠けているかトンネルが落ちており、分割プロファイルで公開名がトンネルから応答するならデフォルトルートが広すぎます。この二つの失敗はブラウザーでは同じに見え、この出力では逆に見えます。
resolvectl status
resolvectl query host.corp.example報告されるプロトコルにも注意してください。キャッシュや hosts ファイルからの回答は、どの上流にも問い合わせずに届くことがあり、キャッシュからの回答は、その名前がいつか解決したことを示すだけで、現在のポリシーが正しくルーティングしていることは示しません。
名前のルーティングとパケットのルーティングを分けて考える
リゾルバーの判断は経路を作りません。選ばれたサーバーには依然としてそのアドレスへの経路が必要で、返されたアドレスには依然として私設ネットワークへの経路が必要なので、正しい DNS ポリシーは、決して開かない接続と共存しえます。名前が解決してもアプリケーションが失敗するときは、DNS を再び変えるのではなくアドレスと経路を調べてください。名前解決と到達性は、異なる持ち主を持つ二つの問いです。
アプリケーションは独自のセキュア DNS 設定や同梱のリゾルバーによって、システムのリゾルバーを完全に迂回できます。resolvectl の結果はシステムの経路を述べるものであり、それを無視するブラウザーはあなたの行うあらゆるテストと食い違います。ポリシーが壊れていると結論する前に、その設定を確認してください。
名前が解決した先のアドレスを、リンクと並べて記録します。誤ったアドレスを指す正しい名前は、ルーティングではなくレコードの問題です。
リンクが変わった後に再確認する
再接続や無線の切り替えはリンクの状態を作り直し、ネットワークマネージャーは手動で設定したものの上に自分のドメインとサーバーを再インストールすることがあります。その後で同じ二つの名前を問い合わせ、記録した基準線と比べてください。手動の編集が消えていたなら、修正は接続プロファイルに属します、シェルコマンドではありません。前後を記録することが、それを可視化します。
内部サフィックスはトポロジーを明かすので、報告に必要な名前とサーバーの文脈だけを共有してください。ドメインルーティングについての systemd-resolved の文書は最長一致の規則とチルダの挙動を扱っており、一度読めば上の表の誤りのほとんどを防げます: systemd-resolved の問い合わせルーティング。