ユイ
14時にDNSを変えたのに、私のPCだけ古いサイトのままです。イトのスマホには、もう新しいサイトが出ているのに。浸透って、いつ終わるんでしょう
ピコ
前のTTLが3600秒なら、古い答えが1時間ほど残る場合があるよ。ただ、全員が15時に切り替わるとは言えない。まず正式な答えが変わったか確かめよう
DNSの変更後に古い答えが残る時間は、変える前のTTLが目安になります。ただし、TTLは「全員の画面が切り替わるまでの時間」を保証する数字ではありません。 まず、権威DNSという正式な答えを持つサーバーが、新しい答えを返すか確かめます。
「浸透」という名前とは逆に、新しい答えは世界へ広がっていきません。待たれているのは、あちこちに残った古い答えが消えることです。だから、確かめる場所には順番があります。
DNS浸透はどこで確認する？正式な答えから手元まで4か所
答えの出どころに近い順に聞いていきます。正式な答えは新しいのに、別の場所から古い答えが返るなら、保存された控え（キャッシュ）や、問い合わせ先の違いを調べます。
| 順番と場所 | ここで古い答えが返るとき |
|---|---|
| 1 権威DNS（正式な答え） | 設定がまだ出ていない。キャッシュの期限を待っても変わらない。保存できているか、変えた画面が、いま使われているネームサーバーのものかを見直す |
| 2 公開DNS（Googleの8.8.8.8、Cloudflareの1.1.1.1） | 古い控えが残っている可能性がある。TTLを目安に待つか、消去の窓口で消す |
| 3 自分の回線のDNS（プロバイダーや会社） | 回線のDNSに古い控えが残っている可能性がある。TTLと問い合わせ先を確認する。新しいサイトを見たいだけなら、Wi-Fiを切って携帯の回線でも試す |
| 4 端末とブラウザー（3まで新しいのに画面が古い） | 端末やブラウザーが使うDNSと保存済みの表示を確認する。WebサーバーやCDN（配信の中継）も調査対象 |
Mac・Linuxはターミナルで、上から1・2・3の順です。
dig @ns1.example.net example.com A +short
dig @8.8.8.8 example.com A +short
dig example.com A +shortWindowsはコマンドプロンプトで、同じ順です。
nslookup example.com ns1.example.net
nslookup example.com 8.8.8.8
nslookup example.comexample.com は自分のドメイン名に、ns1.example.net はDNSを管理している会社の画面に出ているネームサーバー名に置きかえます。どれも答えを読むだけで、設定は変わりません。返ってきたIPアドレスを、新しいサーバーのものと見比べます。コマンドを使わないなら、ブラウザーで dns.google を開いてドメイン名を入れると、2の答えを見られます（Googleの公式ページ）。
digは +short を外すと、その控えの残り秒数（TTL）も出します。読み方はDNS TTLの確認方法にあります。
1で新しい答えが返れば、その問い合わせ先への反映は確認できました。確認したサーバー名と時刻をメモします。権威DNSが複数ある場合は、ほかも同じ答えを返すか確かめます。
DNSの反映はいつまで待つ？TTLは控えの有効時間の目安
TTLは、DNSの答えを保存しておく時間に関わる値です。3600秒なら1時間。たとえば13時50分に受け取った答えのTTLが3600なら、通常の有効期限は14時50分です。設定を変えた時刻から、すべての場所で同じ時計が動き始めるわけではありません。
すべての権威DNSが新しい答えを返し、通常どおり期限で更新できるなら、変更前のTTLから古い控えが残る時間を見積もれます。一方、正式な答えを取得できないときに、期限切れの答えを一時的に使う仕組みもあります（RFC 8767）。予定の時間を過ぎたら、待ち続けるだけでなく、どこがどの答えを返すかを見直します。
| 変えたもの | 確かめる情報 | 時間の読み方 |
|---|---|---|
| Aレコードなど、レコードの中身 | そのレコードの、変える前のTTL | 300秒で5分、3600秒で1時間、86400秒で1日 |
| ネームサーバー（DNSを任せる会社） | 親（.jpや.comを管理する側）と古いネームサーバーが出していた、NSレコード（ネームサーバー名を書いた行）のTTL。切替先の設定も確認する | AWSはネームサーバー情報のTTLを通常24〜48時間と説明。利用先の案内と実際の答えを確認 |
| 新しく作った名前（サブドメインなど） | 作る前にその名前を開こうとした場合だけ待つ。「その名前は無い」という答えにも期限がある | 控える側の上限は、1〜3時間が勧められている |
※ 1行目はJPRSの用語辞典、2行目はJPRSの資料とAWSの案内、3行目はJPRSの解説とRFC 2308。3行目の期限の決まり方は、DNS TTLの記事にあります。
この例でユイが変えたのは、名前とIPアドレスを対応させるAレコードです。1行目を見て、変更前のTTLと、古い答えが残っている場所を確かめます。
意外なのは、いまからTTLを短くしても間に合わないことです。古い控えは、取られたときの秒数のまま残ります（AWSも、いま変えても早くはならないと案内しています）。短くする手が効くのは、変える前だけです。逆に、保存してから時間がたっていれば、変更後すぐ切り替わる場所もあります。Google Public DNS（8.8.8.8）は、TTLがもっと長くても、ふつう6時間までしか控えません。
TTLだけでは反映全体の期限を決められません。よく聞く「24〜72時間」は、どの変更についての案内なのでしょうか。
「浸透に24〜72時間」は、どこから来た数字？
ネームサーバーを変えたときの、各社の案内です。
| 案内している会社 | 反映までの時間 |
|---|---|
| エックスサーバー | 数時間〜24時間程度 |
| AWS（Amazon Route 53） | 最長2日 |
| お名前.com | 最大72時間程 |
※ 2026年10月10日に各社の公式ページで確認。
数字がそろわないのは、「浸透にかかる時間」という決まった値が、DNSのどこにも無いからです。レコードごとのTTLに加え、変更した場所やサービス側の反映も関わります。24時間は86400秒のTTLと、2日はネームサーバーの情報が控えられる24〜48時間（AWSの説明）と重なります。72時間と重なるTTLは、確かめた資料にはありませんでした。
2011年のJPRSの資料には、当時のプロバイダーの案内として「1週間から2週間」という例も載っています。同じ仕組みに、数時間から2週間までの数字が付いてきたわけです。
数字より確かなのは、仕組みのほうです。ユイのPCだけが古い理由も、そこにあります。
なぜ人によって表示が違う？広がるのではなく、消えるのを待っている
マコト
東京から先に切り替わって、だんだん遠くへ届いていく。そういう話じゃないのか
ピコ
地図の近い順に届くわけではないよ。どのDNSに聞いたか、いつ答えを保存したかを分けてみよう
同じ名前を聞いたのに、手元の札が違う。ユイが模型で確かめます。
漫画：変えた答えが、そろわない？ 全4ページ
ユイは同じ名前の案内札なのに、手元の青い入口とピコの橙の入口が違うと気づく。権威側の新しい答えと各所の新旧の控えを見比べ、最後は場所と時刻の欄がある空の確認メモを用意して、次に何を記録するか決める。
画像を押すと拡大できます。＋／−で大きさを変え、拡大中はドラッグして読めます。
1 / 4同じ名前、違う入口
DNS案内模型の前でユイが青い入口の札を持ち、ピコが橙の入口の札を示す。どちらにも同じ名前がある。
1ページ目のセリフ
- 案内札の名前「ラボ」
- ユイ「変えたのに、違う答え？」
2 / 4正式な答えの場所
上段の大きなコマでユイが権威DNSの模型を開き、新しい橙の答えを確認する。下段の二つの反応コマでユイとピコがその答えを見る。
2ページ目のセリフ
- 場所の札「権威DNS」
- 答えの札「新」
3 / 4別の場所に残る控え
上部にユイとピコ、下部に大きな比較ボード。上下の二つのキャッシュに旧い青と新しい橙の答えを置き、TTLの時計を旧い答えのそばへ示す。
3ページ目のセリフ
- 控えの役割「キャッシュ」
- 答えの札「旧」・「新」
- 時間の札「TTL」
4 / 4場所と時刻を付けて確かめる
ユイは場所と時刻の欄がある空の確認メモを持つ。結果はまだ書かず、どこでいつ調べたかを残すと決める。
4ページ目のセリフ
- メモの札「場所」・「時刻」
- ユイ「どこで、いつかも、残します。」
扉の絵は宛先の違いを表す模型で、実在サイトのDNS変更やIPアドレスを観測した結果ではありません。描くのはキャッシュが残る一例で、古い答えなら必ず待てば直るとは限りません。変更先や委任、権威DNSの状態も確認します。TTLは世界共通の切り替え時刻や画面更新の保証ではなく、WebやCDN、ブラウザの表示キャッシュも別の原因候補です。リゾルバの先取り更新など個別の動作をすべて描いた図ではありません。
権威DNSの札は「新」。キャッシュには「旧」と「新」が並び、「旧」のそばにTTLの時計がありました。
キャッシュDNSは、有効な控えを使って返事をすることがあります。期限前に取り直す実装もあるので、いつも同じ動きとは限りません。JPRSは2011年の資料で、DNSにはもともと「浸透」という考え方がなく、起きているのは「古いデータの消滅待ち」だと説明しています。権威DNSとキャッシュDNSの役割は、DNSの仕組みで図にしています。
ユイは変える直前の13時50分にも、確認のためにサイトを開いていました。そのときラボの回線のキャッシュDNSが取った控えは、14時50分まで有効です。イトのスマホは携帯の回線で、14時を過ぎてから初めて聞きに行きました。だから新しい答えです。
| この例の確認先 | 13時50分 | 14時の変更後 | 14時50分以降の問い合わせ |
|---|---|---|---|
| ラボのDNS | 旧IPを保存・TTLは1時間 | 保存した旧IPを返す | 期限後に聞き直し、新IPを取得 |
| 携帯回線のDNS | 控えなし | 初めて聞き、新IPを取得 | 有効な控えを利用 |
この表は、14時に権威DNSへの反映が済み、再取得も成功する例です。時刻は実測値ではありません。
変えた本人ほど、直前までサイトを開いています。本人の画面だけが古いというユイの状況は、こうして起きます。
14時50分まで待てないときは、控えのほうを消しに行きます。
待たずに切り替えたい。自分で消せるDNSキャッシュはどれ？
消せるのは、自分の端末の控えと、消去の窓口がある公開DNSの控えです。
| どこの控え | 消し方 |
|---|---|
| Google Public DNS（8.8.8.8） | Flush Cacheで、ドメイン名とレコードの種類を指定する。ドメインの持ち主である証明は要らない |
| Cloudflare（1.1.1.1） | Purge Cacheにドメイン名を入れ、レコードの種類を選ぶ |
| Windowsの端末 | コマンドプロンプトで ipconfig /flushdns |
| Macの端末 | 再起動する。再起動できないときは、ターミナルで sudo killall -HUP mDNSResponder |
| プロバイダーや会社の回線のDNS | 自分では消せないことが多い。残り時間を見て、必要なら管理元へ相談する |
※ Macのコマンドは、Appleのサポート記事（OS X 10.10.4以降向け。いまは更新を終えた記事）にあるものです。
ネームサーバーを変えた直後にGoogleの窓口を使うなら、先に example.com、次に www.example.com の順で消します。逆にすると、古いネームサーバーから古い答えを取り直してしまいます（Googleの案内）。
端末の控えを消しても、聞き直す先は回線のDNSです。最初の表の3が新しくなってから消すのが、効く順番です。
ここまでは、古い控えが通常の期限で更新される例でした。次は、古い問い合わせ先から答えを取り直す場合を見ます。
ネームサーバーを変えたのに、古い答えを取り直すのはなぜ？
レコードの書きかえは台帳の中身を直す作業、ネームサーバーの変更は台帳を置く担当ごと替える作業です（違いはネームサーバーとはに）。このとき、古い担当の台帳を古い内容のまま残すと、落とし穴になります。
古い担当の名前を控えているキャッシュDNSは、答えの控えが切れるたびに古い担当へ聞きに行き、古い答えを取り直します。作りによっては、担当の名前を控える期限まで巻き戻ります。JPRSは、これを「浸透しない」と言われてきた現象の正体として挙げています。
同じ資料で説明されている移行の考え方です。実際の変更は、利用するDNSサービスとドメイン管理会社の手順に合わせます。
- 新しいネームサーバーに、すべてのレコードを用意する（メールのMXやTXTも。DNSレコードの種類で確かめられます）
- 古いネームサーバー側のレコードも、新しい内容に書きかえる
- レジストラ（ドメインを登録した会社）の画面で、ネームサーバーを切り替える
- 親と古い側のNSレコードのTTLが両方過ぎるまで、古いネームサーバーを止めない
2ができない契約なら、4の時間が過ぎるまで、古いサーバーのサイトとメールを消さずに動かしておきます。
確認メモ：場所と時刻を付けて残す
漫画の最後でユイが用意したメモです。DNSの答えは、どこで、いつ聞いたかで変わります。この2つが無い報告は、あとで比べられません。
- 変えたもの: Aレコード / ネームサーバー / 新しい名前
- 変更前のTTLと、次に確認する時刻: ＿＿秒 ／ ＿＿時＿＿分（全員の切替期限ではありません）
- 確かめた場所（1〜4）と時刻: ＿＿＿＿
- 返ってきた値と、残りのTTL: ＿＿＿＿ / ＿＿＿＿秒
人に伝えるときは、「14時30分、権威DNSは新しいIP、ラボの回線は古いIPで残り1200秒」と書きます。残り1200秒は、その回線の控えが14時50分に切れるという意味で、全員が20分後に切り替わる予告ではありません。
ミニクイズ：DNS浸透を3問で
Q1. 「DNS浸透」とは、何が起きている状態ですか？
A. キャッシュDNSや端末に残った古い答えが、期限切れで消えるのを待っている状態です。新しい答えが広がっているのではありません。
Q2. DNSを変えたあと、いつまで待てばいいですか？
A. 変更前のTTLは、古い控えが残る時間の目安です。3600秒なら1時間ですが、全員の切替を保証する時間ではありません。権威DNSへの反映、問い合わせ先、古い答えが残る場所を確認します。
Q3. DNSの反映は、どこから確認しますか？
A. 権威DNS、公開DNS、自分の回線のDNS、端末の順です。権威DNSが古い答えなら、キャッシュの期限を待っても変わらないので、設定を見直します。
14時50分、ユイのPCも新しいサイトになった
この架空の例では、13時50分に保存した答えが14時50分に期限を迎え、次の問い合わせで新しい答えを受け取りました。ユイのPCも新しいサイトを開けました。
次にDNSを変えたら、「浸透を待つ」と言う前に、権威DNSの答えと、変える前のTTLを見てください。古い控えが残る時間を見積もる手がかりになります。前もってTTLを300秒に短くし、以前のTTLが過ぎていれば、通常の控えの更新を5分程度に短くできます。ただし設定反映全体の5分保証ではありません。何時間前に短くするかは、DNS TTLの記事に手順があります。
待つ以前に、エラーの画面が出てサイトが開かないときは、DNSエラーとはが次の入口です。イトがDNSへ、名前から住所を問い合わせる場面は、物語の第41話にあります。
この記事について
LAB WHITEBOARD
DNS浸透を一文で説明してみよう
「DNSを変えたあとに待つ時間を、変えたものと変える前のTTLから見積もり、権威DNS・公開DNS・自分の回線・端末の順に、古い答えがどこに残っているかを確かめられるようになる。」を、いまの自分の言葉で一文にしてみてください。途中の説明でも大丈夫です。
