DNSの変更が反映されないときの対処法

DNSの変更が反映されないように見える状況は、日々のインフラ作業で最も多いストレスの原因の1つです。その背景にある仕組み（レコードごとに有効期限を持つ分散キャッシュ）は、意識して調べない限り目に見えないためです。

故障を疑う前に順番に確認する

1. 変更が権威側で実際に保存されたことを確認します。一般のパブリックリゾルバーではなく、ドメイン自身の権威ネームサーバーに直接問い合わせて、保存が黙って失敗していないか、プロバイダー自身のインフラ内でまだ同期されていないかを切り分けます。
2. そのレコードの以前のTTLを確認します。たとえば86400秒（24時間）に設定されていた場合、変更の数分前に古い答えをキャッシュしたリゾルバーは、最長で丸1日、再び問い合わせてきません。
3. ブラウザーやOSレベルのDNSキャッシュの可能性を除外します。これらは設定したリゾルバーよりも手元に近く、リゾルバーとは独立して答えを保持できます。
4. 変更したレコードが、意図したレコードであることを確認します。ステージング用や本番以外のDNSゾーンを誤って更新してしまうミスは、意外とよくあります。
5. 複数の観測地点から確認します。1つのリゾルバーが古い答えを示していても、ほかの場所に変更が伝播したかどうかは分かりません。

見落としやすい原因：遅れているセカンダリ（スレーブ）ネームサーバー

規模の大きなDNS構成では、実際に変更を行うプライマリ（「マスター」）ネームサーバーと、ゾーン転送によってそこから定期的にゾーンをコピーする、1台以上のセカンダリ（「スレーブ」）ネームサーバーを運用することがよくあります。転送スケジュールの設定ミス、プライマリとセカンダリ間のネットワークの問題、あるいは単に転送間隔が経過していないといった理由で、セカンダリが最新の転送をまだ取り込んでいない場合、そのセカンダリにたまたま問い合わせたリゾルバーは、プライマリが完全に最新で、すべてのリゾルバーのTTLによるキャッシュが失効していても、古い答えを受け取り続けます。単純なキャッシュに比べるとまれな原因ですが、パブリックリゾルバー同士が食い違うときだけでなく、同じドメインの権威ネームサーバー同士が食い違うときには、特に確認する価値があります。

事前に計画すれば、ほとんど避けられる

移行、プロバイダーの切り替え、切り替え作業といった計画的な変更では、1～2日前にTTLを下げておくことが、最も効果の大きい対策です。クエリ量がわずかに増える代わりに、変更が最悪で丸1日かかるところ、数分で伝播するようになります。TTLを下げ、元のTTLの期間が完全に過ぎるのを待ち、変更を行い、すべて問題ないことを確認してからTTLを元に戻します。

手元のローカルキャッシュが本当に原因のとき、それをクリアする

権威ネームサーバーと、確認したすべてのパブリックリゾルバーがすでに新しい答えで一致しているのに、特定の1台のマシンだけが古い答えを示す場合、残る容疑者はそのマシン自身のローカルキャッシュです。

これらを試すのは、権威側がすでに正しいことを確認した後にしてください。実際のレコードがまだ更新されていないのにローカルキャッシュを消去しても、同じ古い答えの新しいコピーが得られるだけで、消去に失敗したのと見分けがつきません。