VPN で DNS が誤答？ 権威サーバーが 一台だけ古い可能性

VPN に接続すると、一つのホスト名が昨日のアドレスに解決される、あるいは何にも解決されない。切断するとまた動く。反射的にはトンネルが押し付けたリゾルバーを疑いたくなるが、より一般的な原因は、ゾーン更新を受け取らなくなった公開ネームサーバーである。新しい経路が、キャッシュされた応答の出どころとは別の権威に届いただけのことだ。

症状はリゾルバーによって変わる

再帰リゾルバーは権威が答えた内容を返し、その応答を TTL の間保持する。トンネルが別のリゾルバーを押し付けたり、古いリゾルバーに到達できなくなるよう経路を変えたりすると、クライアントは別の権威に問い合わせ、別の応答を受け取る。その瞬間にドメインが変わったのではなく、あなたの見え方が変わったのだ。

だから同じ名前が一つのオフィスでは動き、ホテルからは失敗し、ローカルキャッシュを消しても効くのはときどきなのも同じ理由だ。キャッシュを消すと、問い合わせは再び同じ権威に送られる。

見分けるための試験は、公開された各サーバーへの直接クエリだ。

各権威に直接問い合わせる

覚えているリストではなく、委譲から始める。親に NS セットを尋ね、そのセットの各名前に対して必要なレコードを問い合わせる。同じ名前を別々の権威に 二回問い合わせれば、ゾーンが一貫しているかどうかがすぐに分かる。

dig +short NS example.com
dig @ns1.dns.example app.example.com A
dig @ns2.dns.example app.example.com A

ゾーンの頂点の NS レコードについても同じことをするのは、移行後に親の委譲とゾーン自身の NS セットが食い違うことがあるからだ。次に比べるのは SOA のシリアル番号で、大きく遅れているセカンダリは応答の問題ではなく転送の問題である。

そのクエリは、自分のデスクからだけでなく、失敗するネットワークから実行する。

意図されたビューと壊れたビューを分ける

リージョンやリゾルバー群によって意図的に異なる応答を返すドメインもあり、スプリットホライズンの構成は企業ネットワークでは普通だ。

問題は、その違いが文書化され安定しているかどうかだ。意図しないビューは見え方が違い、ある権威には他のサーバーが決して受け取らなかったレコードがあり、あるいは全員が共有するレコードが欠けている。RFC 2182 の選択と配備の指針は権威の可用性を共同責任として扱っており、ここでもそれが正しい枠組みだ。冗長性は、公開された各サーバーが意図されたデータで応答できるときにだけ存在し、ポート 53 で接続を受け付けるだけでは足りない。

SERVFAIL を返すサーバーは、自信を持って誤って答えるサーバーより診断しやすい。

移行はキャッシュが隠していたものを暴く

プロバイダーの移行では、二つの権威の場所が変わる。親の委譲とゾーン自身の NS レコードで、どちらも更新が必要であり、どちらもそれぞれの TTL の間キャッシュされる。古いサーバーが動き続けて以前のゾーンを配信し続けると、そのサーバーに問い合わせるリゾルバーを使うクライアントは、切り替えが完了したように見えたずっと後まで古い応答を受け取り続ける。

長命なキャッシュが隠しているのは、まさにこの状態だ。一週間ずっと動いていたワークステーションは、新しい権威からの新しい応答を持つリゾルバーと話していたが、古いサーバーは他の全員に古いデータを配り続けていた。

ノート PC のリゾルバーを変えても、そのノート PC が直るだけで他は何も変わらない。

直すべきはゾーンで、リゾルバーではない

どのサーバーがそのゾーンの権威であるべきかを見極め、管理対象ゾーンまたは委譲を修正して、そのすべてが意図されたデータを配信するようにし、計画した冗長性を保つ。VPN の出口が一つ奇妙な応答を得たからといってネームサーバーを削除すると、可用性が下がり、不整合はそのまま残る。

その後、両方のネットワークから直接クエリを再実行し、変更したレコードの TTL が切れるのを待つ。

各権威からの応答が安定していることを確認し、意図されたビューをゾーンの文書に書いておけば、次に違いが出たときに分類しやすい。