2026年9月30日
Google Public DNS（8.8.8.8）に、利用者側から特定の名前を「プリロード（事前にキャッシュへ読み込ませる）」する公式の仕組みはありません。できるのは、権威DNS側でTTLを計画的に下げておくこと、公式の「Flush Cache」ページで古いキャッシュの破棄を依頼すること、そして反映状況を dig で確かめることの3つです。この記事では、サーバー移転やDNSレコード変更のときに、8.8.8.8を使う利用者へ新しい値を早く届けるための手順を、なぜそうするのかと合わせて説明します。
1.1.1.1 で名前解決できないときの対処や、端末のDNS設定を 8.8.8.8 に切り替える手順は別記事で扱っています。この記事は、Google Public DNS のキャッシュ側の扱いに絞った内容です。
「プリロード」が思いどおりに効かない理由
自分の端末から dig @8.8.8.8 example.com を実行すれば、その名前はGoogle Public DNSのキャッシュに載ります。しかし、これで「全利用者向けに読み込ませた」ことにはなりません。
- Google Public DNS はエニーキャストで運用されており、同じ 8.8.8.8 でも、利用者の地域やネットワークによって応答するサーバー群が異なります。
- 同じ地域の中でもキャッシュは複数に分かれているため、続けて問い合わせても、返ってくる残りTTLがばらつくことがあります。
- 人気のある名前については、Google 側がTTL切れの前に再取得する仕組みを持っていると公式の解説で説明されていますが、利用者が対象を指定できるものではありません。
つまり、手元からの問い合わせは「自分の近くのキャッシュを温める」程度の効果にとどまります。新しい値を広く早く届けたいなら、次の手順のように、キャッシュが古い値を長く持たないように準備しておくことが本筋です。
手順1: 変更前にTTLを下げておく
もっとも効果が大きいのは、変更の前に権威DNSでTTLを短くしておくことです。
- 現在のTTLを確認します。権威DNSに直接問い合わせると、設定値そのものが見えます。
dig example.com NS +short
dig @ns1.example-dns.net example.com A- DNS管理画面で、変更予定のレコードのTTLを短い値（例: 300秒）に下げます。
- 元のTTL以上の時間を待ちます。元が86400秒（1日）なら、少なくとも1日待ってから本番の変更を行います。こうすると、各リゾルバーのキャッシュに残る古い値も、短いTTLのものに入れ替わっています。
- レコードを新しい値に変更します。
- 安定したことを確認できたら、TTLを元の値に戻します。
TTLを下げる作業自体も、古いTTLのあいだはキャッシュに残る点に注意してください。直前に下げても、すでにキャッシュされている古いTTLには効きません。
手順2: 権威DNSとGoogle Public DNSの応答を比べる
変更後は、権威DNSと 8.8.8.8 の両方に問い合わせて比べます。
# 権威DNSの応答（設定が反映されているか）
dig @ns1.example-dns.net www.example.com A +noall +answer
# Google Public DNS の応答（キャッシュの状態）
dig @8.8.8.8 www.example.com A +noall +answer
dig @8.8.4.4 www.example.com A +noall +answer+noall +answer を付けると、答えの行だけが表示されます。2列目の数字が残りTTLです。権威DNSが新しい値を返しているのに 8.8.8.8 が古い値を返す場合は、キャッシュが残っている状態です。権威DNSが古い値を返すなら、そもそも設定が保存されていないか、別のネームサーバーを編集している可能性があります。
IPv6で問い合わせる場合は、2001:4860:4860::8888 を指定します。
手順3: Flush Cache ページで破棄を依頼する
Google Public DNS には、特定の名前のキャッシュ破棄を依頼できる「Flush Cache」ページが公式に用意されています（developers.google.com の Public DNS のドキュメント内にあります）。
- Flush Cache ページを開きます。
- ドメイン名と、レコードの種類（A、AAAA、MX、TXTなど）を指定します。
- 画面の確認（ロボットでないことの確認）を済ませて送信します。
画面の構成や入力項目は変わることがあります（2026年10月現在）。作業の時点の表示に従ってください。破棄が反映されるまでには少し時間がかかることがあり、また破棄されるのはその名前とレコードの種類のキャッシュだけです。A と AAAA の両方を変えたなら、それぞれ依頼します。
このページは、変更を急ぐ場合の補助と考えてください。手順1でTTLを下げておけば、多くの場合は依頼しなくても短時間で入れ替わります。
手順4: 利用者側のキャッシュも考える
Google Public DNSが新しい値を返すようになっても、利用者の端末やブラウザに古い値が残っていることがあります。問い合わせを受けたときは、次の点を案内します。
- OSのDNSキャッシュのクリア（Windowsなら
ipconfig /flushdns） - ブラウザの再起動や、ブラウザ独自のDNSキャッシュのクリア
- hosts ファイルに古い記述が残っていないか
- ブラウザの「セキュア DNS（DoH）」設定で、8.8.8.8 以外のリゾルバーを使っていないか
うまく反映されないときの確認ポイント
起きやすい順に並べます。
- 元のTTLが長いまま変更した: 古い値のTTLが切れるまで待つか、Flush Cache を使います。
dig @8.8.8.8の残りTTLが減っていくのを見れば、いつ切れるかの目安が分かります。 - 変更前に問い合わせて「存在しない」がキャッシュされた: 新しいサブドメインを作る前に問い合わせると、NXDOMAINがキャッシュされます。保持時間はゾーンのSOAレコードの値で決まります。Flush Cacheで破棄を依頼するか、時間の経過を待ちます。
- DNSSECの検証に失敗している: Google Public DNS はDNSSECを検証するため、署名や DS レコードに不整合があると SERVFAIL を返します。
dig @8.8.8.8 www.example.com +cdで検証を止めた問い合わせが成功するなら、DNSSEC の設定を疑います。 - ネームサーバーそのものを変えた: レジストラでネームサーバーを変えた場合は、TLD側の NS 情報のキャッシュも関係するため、レコードの変更より時間がかかります。
まとめ
- Google Public DNS に名前を指定してプリロードする公式の手段はなく、手元からの問い合わせは近くのキャッシュを温める程度の効果です。
- 新しい値を早く届ける基本は、変更前にTTLを下げ、元のTTL以上待ってから変更することです。
- 急ぐ場合は、公式の Flush Cache ページで名前とレコードの種類ごとに破棄を依頼できます。
- 反映の確認は、権威DNSと 8.8.8.8 の応答を
digで比べ、残りTTLとフラグを見て判断します。