VPNはDNSを直したのか、それともキャッシュされた応答を使い回しただけか？

トンネルが上がって数秒後にページを開いたことは、チケットにはたいていそう書かれていますが、DNSが今機能している証拠にはなりません。その観察には問い合わせを必要とする要素がなく、名前は変更前に解決され、トンネルが触れていないキャッシュから再利用されたのかもしれません。二つの異なるテストが同じ画面を生み出します。

変更の成果とする前に、各テストが実際に何を試したのかを比較してください。

ページの読み込みは問い合わせではない

アプリケーションとリゾルバーの間の各層は、その寿命の間、応答を記憶できます。オペレーティングシステムは一つを保持し、ブラウザーは独自のものを保持し、長寿命の接続を持つアプリケーションはセッション中にもう何も解決しないかもしれません。したがって、トンネル変更後に成功した読み込みは、ルーティングではなく記憶の実演である可能性があります。障害がないことは、問い合わせがあることではありません。

この区別は、次に何をテストすべきかを変えます。新しいリゾルバーが応答することを示すのが目的なら、まだ消していないキャッシュから提供できない問い合わせが必要です。

キャッシュされた成功を、以前は到達できなかったサーバーが回復した証拠として読むのは、誤った前提でインシデントを閉じてしまうため、この誤りの最も高価な形です。

結論を出す前にキャッシュを数える

名前を挙げる価値がある四つは、アプリケーション自身の解決、オペレーティングシステムのクライアントキャッシュ、ブラウザーの内部状態、そして問い合わせが最終的に到達する再帰リゾルバーです。それぞれに別々の寿命と別々の消去方法があります。一つを消して別のものをテストするのは、人々が消去しても何も起きなかったと結論する方法です。一つの消去コマンドで問題が決着することは決してありません。

否定応答もキャッシュされます。存在しないと報告された名前は、ネットワークが修正された後も存在しないままになることがあり、それは壊れたトンネルとして読まれますが、実際には期限切れになっていないTTLです。DNS仕様は、このデータをどのように保持し再利用すべきかを説明しています。

印象ではなく出来事を記録する

何が変わったのか、つまりレコード、リゾルバーへの経路、クライアント設定のいずれかを書き留めてください。レコードの編集は独自のスケジュールで伝播し、ルート変更は再接続時に有効になり、ブラウザー設定はそのブラウザーだけに適用されます。それらを一つの前後比較にまとめると、誰も監査できないタイムラインが生まれます。

時刻、使用したリゾルバー、受け取った応答を、応答が否定である場合も含めて記録してください。それは他の誰かが確認できる事実です。

同じ方法で比較を二回行う

テストする予定のキャッシュを消し、元の観察を保ち、できるだけ多くの記憶を迂回する方法で問い合わせてください。リゾルバーを明示的に名指すと、そのリゾルバーが何を知っているかが分かりますが、アプリケーションがどのリゾルバーを選んだかは分かりません。

resolvectl flush-caches
ipconfig /flushdns
dig +noall +answer internal.example @10.44.0.53
dig +short internal.example

Windowsでは、クライアントキャッシュの消去はDNSクライアントキャッシュを消去するだけで、他には何もしません。ブラウザーの私的な状態を表すものではなく、上流サーバーを消去するものでもないため、それに基づくテストは狭く解釈するしかありません。結果を報告するときは、どのキャッシュを消したのかを必ず述べてください。

その後、新しい要求と意図したリゾルバーポリシーを有効にした状態で、実際のアプリケーションを再度テストしてください。異なるポリシーの下で生成された結果は引き継がれません。