VPN の DNS レポート：再現できるように載せるべき内容

「DNS が壊れている」は結論であり、助ける人が行動できる結論ではありません。レポートの役に立つ部分は、どの名前が、どのリゾルバーを通り、どんな応答だったのかという失敗の形です。三つの詳細があれば不具合は再現可能になり、非公開の部分を置き換えたうえでなら三つとも安全に共有できます。以下は、誰かが助けられるようになる前に VPN の DNS レポートが必要とする最小限です。

名前の分類であって、判決ではない

名前そのものから始めて、公開、内部、短縮、完全修飾、あるいは特定のサフィックスで提供されるもの、のいずれかに分類します。公開名は解決するのに内部名が失敗するなら、到達性ではなくリゾルバーの選択が原因です。すべての名前が失敗するなら、リゾルバーへの経路の問題であり、これは別の証拠を持つ別の調査です。分類が診断を担い、正確な文字列は伏せられます。

失敗がトンネルの起動を必要とするのか、切断後に起きるのかを書き添えます。VPN が有効な間だけ壊れる名前はリンクごとの設定を示し、切断後に壊れる名前は残った状態を示します。レポートはたいていこれを省き、最初の提案が効かない理由を不思議がります。

リゾルバーの経路を記録する

明示的に選んだサーバーへの問い合わせと、アプリケーションの通常の名前解決は別の実験なので、どちらが失敗を生んだのかを書きましょう。動作するサーバーへの手動問い合わせは、そのサーバーが動くことしか証明しないからです。下のコマンドは、システムの経路と直接の問い合わせを分けます。

resolvectl status --no-pager
getent hosts host.internal
dig +short host.internal @10.20.30.53

status の出力はリンクごとのサーバーとルーティングドメインを示し、これは 分割 DNS が決まる場所です。getent の呼び出しは nsswitch の順序も含め、アプリケーションと同じ経路をたどります。直接の問い合わせはその両方を迂回し、一つのサーバーだけを切り離して試します。三つのうちどれが失敗しどれが成功したかを書けば、読み手は経路を推測せずに済みます。

統制された比較を書く

一つの変数だけを変え、何が変わったかを書きます。公開名は解決するのに内部名が失敗するのは選択の問題、すべての名前がタイムアウトするのは経路の問題、私的な名前が公開アドレスに解決するのは誤ったリゾルバーへの漏れです。この三つのうち二つは、トンネルが起動しているかどうかとは無関係です。すべての問い合わせが壊れていると主張するレポートには、たいてい一度も実行されていない比較が含まれています。

解決と配信を分けます。名前は解決するのにサイトが失敗するなら、DNS の段階は成功したのであり、レポートはそう書くべきです、次の手はリゾルバーではなくルートかリスナーだからです。この一つの区別だけで、どんなログ抜粋よりも頻繁に質問の一往復を省けます。

名前空間は伏せ、関係は残す

内部名は、置き換えが構造を保つかぎり置き換えてかまいません。異なるサーバーとサフィックスをそれぞれ安定したラベルに対応づけ、その対応表は共有する写しの外に置きます。すべての内部ホストを同じプレースホルダーに置き換えると、レポートが必要とする証拠をまさに壊します、あるサフィックスは解決し、別のものはしなかった、ということが読み手に見えなくなるからです。同じ規則はアドレスにも当てはまり、プレフィックスの関係は保ち、方針が求めるならホストのビットを変えます。

記録は検証済みの経路で送り、診断に決して不要なものは載せません。パスワード、秘密鍵、無関係な会社名は DNS の問い合わせの一部ではありません。読み手が必要とするのは、失敗の分類、リゾルバーの経路、正確なエラー、そして実行した一つの比較です。