DNS浸透という言葉を使うのをやめた話

2025-12-21

DNS浸透

「DNS浸透待ちですね」。インフラエンジニアなら一度は言ったことがあるセリフ。自分も使っていた。でもこの言葉は技術的に不正確で、使うのをやめた。

「DNS浸透」の何が問題か

「DNS浸透」という表現は、DNSの変更が世界中のサーバーに「染み渡る」ようなイメージを与える。まるで水が紙に浸透するように、時間をかけてゆっくり広がるイメージ。

でも実際のDNSはそうは動かない。DNSは「浸透」しない。キャッシュが「期限切れ」になるだけ。

この誤解が根強いのは、「DNS propagation」という英語表現の影響もある。propagation を「伝播」「浸透」と訳したことで、変更が能動的に広がっていくような印象が定着した。実際にはDNSに変更をプッシュ配信する仕組みは存在しない。各リゾルバが個別にキャッシュを保持し、TTLの期限切れ後に新しい情報を取得しに行くだけ。受動的な仕組みであって、能動的な「浸透」ではない。

DNSの名前解決の流れを正確に理解する

「浸透」が誤りだと言うだけでは不十分なので、DNSの名前解決がどう動くかを整理する。

ブラウザで example.com にアクセスすると、まずOSのスタブリゾルバがローカルキャッシュを確認する。キャッシュになければ、設定されたフルサービスリゾルバ（ISPやパブリックDNSなど）に問い合わせる。

フルサービスリゾルバは再帰的に名前解決を行う。まずルートDNSサーバーに .com のネームサーバーを聞き、次に .com のTLDサーバーに example.com のネームサーバーを聞き、最後に example.com の権威DNSサーバーにIPアドレスを聞く。この一連の問い合わせ結果を、各レコードのTTLに従ってキャッシュする。

重要なのは、フルサービスリゾルバは自分のキャッシュが有効な間は権威サーバーに問い合わせないという点。TTLが3600秒なら、最後の問い合わせから3600秒間はキャッシュされた古い値を返し続ける。

つまり、権威サーバー側でレコードを変更しても、各リゾルバのキャッシュが切れるまでは古い値が返る。これが「反映に時間がかかる」ように見える原因。「浸透」ではなく、単に世界中のリゾルバのキャッシュ有効期限がバラバラなだけ。

DNSキャッシュの仕組み

TTLの仕組みと落とし穴

TTL（Time To Live）はDNSレコードに付与される秒数で、キャッシュの有効期間を指定する。値が小さいほどキャッシュの寿命が短く、変更が速く反映される。

ただし、TTLには注意すべき落とし穴がいくつかある。

リゾルバがTTLを守らないケース。RFC上、リゾルバはTTLに従ってキャッシュを破棄すべきとされている。しかし一部のISPのリゾルバは、サーバー負荷軽減のためにTTLを無視して長くキャッシュすることがある。TTLを60秒に設定しても、特定のISP経由では数時間キャッシュが残る、という事態が起こりうる。

NSレコードのTTLは別管理。ドメインのネームサーバー自体を変更する場合、Aレコードなどの個別レコードのTTLではなく、NSレコードやグルーレコードのTTLが関係する。これらはTLD側で管理されており、自分では制御できないことがある。ドメイン移管やネームサーバー変更時に時間がかかるのは、この仕組みが原因。

ネガティブキャッシュの存在。存在しないレコードへの問い合わせ結果（NXDOMAIN）もキャッシュされる。この有効期限はSOAレコードのMinimum TTLフィールドで決まる。新しいレコードを追加する前に問い合わせが発生していた場合、ネガティブキャッシュが残って「レコードを追加したのに見えない」という状況が起きる。

なぜ「浸透待ち」が問題か

「DNS浸透待ちですね、24〜48時間かかります」。この回答は便利だけど、問題がある。

原因の特定を放棄している。「浸透待ち」と言えば、待てば解決するように聞こえる。でも実際には、設定ミスやTTLの理解不足が原因で反映されていないケースがある。「浸透待ち」で片付けると、本当の原因を見逃す。

対処法がない。「浸透」という曖昧な現象に対しては、待つ以外の対処法がない。でもキャッシュの問題なら、TTLを事前に短くする、キャッシュをクリアする、直接権威サーバーに問い合わせるなど、具体的な対処ができる。

障害対応が遅れる。本番環境でDNS切り替えが反映されない時、「浸透待ち」で済ませると対応が止まる。実際にはゾーンファイルの記述ミスやレジストラ側の反映漏れなど、すぐに修正すべき問題が隠れていることがある。

正しいトラブルシューティング

DNS変更後に反映されない時のチェックリスト。

権威DNSサーバーに直接問い合わせる: dig @ns1.example.com example.com で権威サーバーの応答を確認。ここで古い値なら設定ミス。これが最初の切り分けポイントになる。
TTLを確認する: dig example.com の応答に含まれるTTL値を見る。変更前のTTLが86400（24時間）なら、最大24時間はキャッシュが残る。
ローカルキャッシュを確認する: OS、ブラウザ、アプリケーションそれぞれにDNSキャッシュがある。macOSなら sudo dscacheutil -flushcache && sudo killall -HUP mDNSResponder でOSのキャッシュをクリアできる。Chromeなら chrome://net-internals/#dns からブラウザキャッシュをクリアする。
ネガティブキャッシュを確認する: 存在しないレコードへの応答もキャッシュされる（SOAのMinimum TTL）。dig example.com SOA でMinimum TTLを確認する。
複数のパブリックDNSで確認する: dig @8.8.8.8 example.com や dig @1.1.1.1 example.com で、Google Public DNSやCloudflare DNSから確認する。特定のリゾルバだけ古い値を返しているのか、全体的に古いのかを切り分ける。

「浸透待ち」ではなく、このチェックリストに沿って原因を特定する方が、早く解決する。

DNS切り替えの正しい手順

DNSレコードを変更する予定がある場合、以下の手順を踏む。計画的にやれば「浸透待ち」は発生しない。

ステップ1: 現在のTTLを確認する。dig example.com でTTL値を確認。86400（24時間）のような長い値になっていることが多い。

ステップ2: TTLを短縮する。変更予定の24〜48時間前に、TTLを60〜300秒に短縮する。この時点ではレコードの値は変えない。元のTTL分の時間が経過すれば、短いTTLが全リゾルバに行き渡る。

ステップ3: レコードを変更する。TTL短縮が行き渡った後に、レコードの値を変更する。TTLが60秒なら、最大60秒で新しい値に切り替わる。

ステップ4: 動作確認する。権威サーバーへの直接問い合わせ、複数のパブリックDNS、実際のブラウザアクセスで確認する。

ステップ5: TTLを元に戻す。問題なければTTLを元の値に戻す。TTLが長いほうが権威サーバーへの問い合わせ頻度が下がり、応答速度も上がる。

DNS変更の正しい手順

言葉が理解を歪める

「DNS浸透」に限らず、不正確な技術用語は理解を歪める。

「クラウドに保存」→ 実際には誰かのサーバーに保存。「AIが考える」→ 実際には統計的なパターンマッチング。「サーバーレス」→ 実際にはサーバーはある。

技術用語を正確に使うことは、正確な理解につながる。正確な理解は、正確なトラブルシューティングにつながる。

「DNS浸透」という言葉を使うのをやめてから、DNS関連のトラブル対応が速くなった。原因を正しく理解しているから、正しい対処ができる。「浸透待ちですね」と言う代わりに、「TTLが86400秒なので、最大24時間はキャッシュが残ります。事前にTTLを短縮しておけば回避できました」と具体的に説明できるようになった。