VPN クライアントの DNS レコード：所有者、TTL、クリーンアップは別物
VPN アドレス、DNS レコード、キャッシュのエントリにはそれぞれ別の所有者がいます。名前を公開できるのは誰か、どのインターフェースが登録するのか、レコードがいつ失効するのかを決めましょう。
ノート PC は接続して VPN アドレスを受け取りますが、他のシステムが解決する名前は昨日のオフィスのアドレスを指したままです。何も故障しておらず、アドレスは割り当てられ、レコードは更新されず、キャッシュは古い応答を保持しているだけです。これは所有者の異なる 三つのオブジェクトであり、VPN に属するのはそのうち 一つだけです。公開を計画するとは、名前を誰が書くのか、どのインターフェースが参加するのか、古いデータがいつ消えるのかを決めることです。
症状：誤ったアドレスを追う名前
端末側ではトンネルが上がり、VPN アドレスが応答します。同僚のワークステーションからは、同じホスト名が端末がもう持っていないプライベートアドレスに解決されるため、移動したマシンに対して接続がタイムアウトします。レコードは権威があり、かつ誤っているため、欠落よりも悪い状態です。全員がそれを信じ、誰も接続できません。
逆のケースはもっと静かで、レコードが消え、名前がまったく解決されなくなります。どちらの結果も同じ設計上の隙間から生じており、TTL を下げても直りません。キャッシュの寿命を短くしても変わるのは誤った応答が残る時間であり、書き込まれるかどうかではありません。
まず、どのオブジェクトが古いのかを問いかけてください。VPN が割り当てたアドレス、ゾーン内のレコード、リゾルバのキャッシュ内の応答は、寿命も所有者も異なります。
三つのオブジェクト、三人の所有者
VPN はアドレスの割り当てを所有し、DHCP のやり取りがノート PC に届かなくても内部プールからアドレスを渡せます。DNS ゾーンはレコードを所有し、そのセキュリティモデルが誰に作成や変更を許すかを決めます。リゾルバのキャッシュは読者が現在使っているコピーを所有し、端末側の操作ではそこに到達できません。
一つのコンポーネントが 三つすべてを行うと想定する点で設計は破綻します。管理された範囲から来たように見えるアドレスは、DHCP サーバーが登録を行った証拠にならず、登録が成功しても読者がキャッシュを更新した証拠にはなりません。
| Object | Owner | What it decides |
|---|---|---|
| VPN address | Tunnel gateway pool | Which address the device holds now |
| DNS record | Zone security model | Which name resolves to which address |
| Cached answer | Each resolver | How long a reader keeps the old answer |
誰がレコードを更新できるか
Active Directory と統合され、セキュリティで保護された動的更新を使うゾーンでは、アクセス許可はレコード自体にあります。DHCP サービスアカウントが作成したレコードは、ノート PC のコンピューターアカウントでは書き込めないことがあり、後から所有モデルを変えるのは移行であり、切り替えではありません。だからこそ 所有権の競合はクライアント側の設定をすべて超えて残ります。
Microsoft の動的更新のガイダンスは、ドメイン参加したハイブリッドエンドポイントについてクライアント側の登録を推奨しています。それを採用するとは、既存のレコードを意図的に移行することであり、VPN アダプターのチェックボックスを入れて古い所有者が譲ることを期待するだけではありません。
DHCP サービスが他のデバイスクラスのために登録する必要がある場合は、その役割でサポートされる資格情報とアクセス許可のモデルを与えます。前方と逆引きのレコードは、しばしば別のコンポーネントが維持し片方が忘れられるため、同じ計画に置いてください。
ipconfig /all
Resolve-DnsName laptop-042.corp.example -Type A
Get-DnsServerResourceRecord -ZoneName corp.example -Name laptop-042最初のコマンドは、端末がどのアドレスを保持していると認識しているか、接続がそれらを登録する設定かを示します。二番目と 三番目は、クライアントが解決する内容とゾーンが実際に保存する内容を比較し、キャッシュの問題と権威側の問題を切り分けます。
三つの時計、一つではない
公開と更新が一つ目の時計で、権限を持つ更新者がアドレスの変更を通知する時点です。キャッシュ TTL は二つ目で、リゾルバが受け取った応答を保持できる期間です。権威側のクリーンアップは三つ目で、古いレコードが登録プロセスまたはエージングとスカベンジングによって削除される仕組みです。
これらの時計は独立しており、混同すると機能しない修正が生まれます。一つの変更は他の 二つには見えません。短い TTL はキャッシュされた応答の寿命を縮めるだけで、更新の許可を与えません。スカベンジングは更新されなかったレコードを削除しますが、正しい所有者が書かなかったレコードを修復することはできません。
TTL は読者が変更をどれだけ早く見る必要があるかで決め、スカベンジングは放棄された端末が名前をどれだけ保持すべきかで決めます。どちらの数値も誰がレコードを書けるかを決めず、どの TTL 値もアドレス割り当てを DNS 管理権限に変えません。
移動する端末のために公開を計画する
どのインターフェースが登録に参加するかを決めます。自宅の Wi-Fi アドレス、VPN アドレス、古いオフィスのアドレスはそれぞれ異なる相手に役立ち、すべてを公開すると有用性の異なる複数の応答を持つ名前になります。想定した読者が実際に到達できるインターフェースだけを登録してください。
安定したコンピューター名を同一性として保ち、アドレスはその属性として扱います。端末が必要とするドメイン検出のレコードを保持し、アクセス許可の変更で直る重複レコードの問題を解決するために登録を全面的に無効にしないでください。
割り当てを行う側、更新する側、クリーンアップの所有者を 一つのレコードに書き、想定した読者を明記します。名前が再び誤ったアドレスを指したとき、そのレコードは調査をやり直す代わりに 三つのうちどれを最初に確認すべきかを教えてくれます。