VPN 経由の NXDOMAIN はトンネル障害ではない

名前が十分前に機能していたこともあり、失敗したルックアップを一つ見てトンネルが崩壊した証拠と読むのは誘惑的です。応答はそうは言っていません。NXDOMAIN は、問い合わせた名前が存在しないとリゾルバーが宣言した完了済みの DNS トランザクションであり、壊れたトンネルは通常、沈黙、タイムアウト、または誤ったサーバーへの解決の試みを生みます。wireshark を使わない版の議論は、一つのクエリ、一つの応答者、一つの応答コードであり、設定を変える前にこの三つ組を記録する価値があります。

応答が実際に証明すること

DNS は、クライアントがしばしば一つの失敗にまとめてしまう結果を分けています。存在しない名前は NXDOMAIN コードを伴う否定応答を生み、存在するが要求されたタイプのレコードがない名前は、空の回答セクションを伴う成功応答を生みます。どちらもアプリケーションには役に立たないものに見えますが、名前が間違っていることを意味するのは一方だけです。

その違いが、修理をどこに置くべきかを決めます。A レコードを持つホストに AAAA レコードがないことはホストがないことではなく、それを追って証明書を再発行したりトンネルを再構築したりするのは、唯一得られていた手がかりを無駄にします。この区別は後続の形も決めます：名前の問題はゾーンで直し、タイプの問題は正しいレコードを尋ねるか、アドレスファミリーが単に存在しないことを受け入れることで直します。

神話：プライベート名がないことはトンネルの失敗を意味する

この神話が生き残るのは、二つの出来事が非常に頻繁に一緒に起きるからです。クライアントが VPN に接続し、オペレーティングシステムはすでに信頼していたリゾルバーを保持し、今必要になった内部名は、プライベートゾーンを聞いたことのないサーバーに問い合わせられます。そのサーバーは正直に、否定的に答えます。トンネルはパケットを運んでおり、応答は、応答者が提供していない名前空間についてのものにすぎません。

スプリットホライズンの構成ではこれが日常になります：同じゾーン名が公開側と内部側に異なる内容で存在し、プライベートレコードを知っているのは内部リゾルバーだけです。したがって、権威があるように見える否定応答を得ることは、どのリゾルバーが答えたかの証拠であり、インターフェースの状態の証拠ではありません。

結果を決める設定の詳細が二つあります。トンネルは内部リゾルバーを押し出すか選択しなければならず、クライアントはその選択を、検索される名前に適用しなければなりません。入力したレコードとわずかに異なるサフィックスを指定するドメインごとのルールは、クエリを公開側の経路に送り、応答は正しくても役に立たなくなります。

正しい名前で正しいリゾルバーに尋ねる

判定を記録する前に応答者を記録します。どのサーバーが答えたかを示さないルックアップは、ポリシーの問題と名前空間の問題を区別できず、両者の修正は無関係です。

resolvectl query vpn.internal.example
resolvectl status | grep -A3 'DNS Servers'
dig +search app.intranet.example A
dig @10.8.0.1 app.intranet.example A

最初の二行は、ローカルリゾルバーが何を決め、誰に尋ねるかを示します。+search のルックアップは、アプリケーションが検索サフィックスを付けたときに行うことを再現しており、診断ツールに入力したものではなく、実際のクエリであることがよくあります。最後の行はクライアントのポリシーを迂回して内部サーバーに直接尋ねますが、これが成功して通常のルックアップが失敗するなら、ゾーンは正常で、クエリの経路が正常ではありません。

否定キャッシュが修正後の遅れを説明する

否定応答は設計上キャッシュされ、RFC 2308 は否定キャッシュの寿命がゾーンの権威レコードからどう導かれるかを説明しています。したがって、レコードやリゾルバーのルールを直してもクライアントに即時の変化が保証されるわけではなく、キャッシュされた応答を返し続けるルックアップを再試行しても新しいことは何も証明できません。別の応答者、別の名前、または消去されたキャッシュだけが新しい証拠を生みます。

ローカルキャッシュを消去し、それから同じ応答者に対して同じクエリを繰り返します。ローカルリゾルバーサービスを使うシステムではそれは一つのコマンドで、そうでない場合はサービスの再起動かプラットフォームのユーティリティで、具体的なツールよりも、その後で同一のテストを繰り返すことのほうが重要です。

名前と経路を切り分ける

名前が期待したプライベートアドレスに解決されたら、DNS は話題として終わり、次はアプリケーションの経路が問題になります。ルックアップには答えるが接続を拒むホストには別の問題があり、正しい応答の後もリゾルバーを調整し続けるのは、インシデントが無関係な三つの変更を抱え込む道です。二つが一致すると仮定する前に、解決されたアドレスと、サービスが実際に待ち受けているアドレスを比較してください。

記録を残してください：クエリ、応答者、コード、解決されたアドレスです。その記録は後日の報告を検証可能にし、診断と、遅く見えたトンネルについての物語との違いになります。