ISPのキャッシュDNSを「プリロード」する方法｜できること・できないことと移転前の準備

ISP（プロバイダー）のキャッシュDNSに、外部から新しいレコードを書き込んだり、まとめて先読みさせたりする方法はありません。サイト側でできるのは「TTLを事前に短くしてキャッシュの入れ替えを早める」「自分の回線から問い合わせてキャッシュを温める」「訪問者のブラウザにDNSの先読み（dns-prefetch）を指示する」の3つです。この記事では、それぞれで何が期待でき、何が期待できないかを整理し、サイト移転やDNS変更の前に実際に行う準備を手順として説明します。

ISPのキャッシュDNSはどう動いているか

ISPのキャッシュDNS（フルリゾルバー）は、利用者から問い合わせを受けると、権威DNSサーバーまでたどって答えを取得し、レコードに付いたTTLの秒数だけ保持します。保持している間に同じ名前を聞かれれば、権威DNSには問い合わせずにキャッシュから返します。

ここで押さえておきたい点が3つあります。

• キャッシュは問い合わせがあって初めて作られる。 権威DNS側から「このレコードを覚えておいて」と送り込む仕組みはDNSにはありません。
• キャッシュは1台にまとまっていない。 大きなISPのリゾルバーは、同じアドレスの裏で多数のサーバーが動いていることが多く、キャッシュはサーバーごとに別々です。1回問い合わせても、次の問い合わせが同じサーバーに届くとは限りません。
• 多くのISPリゾルバーは契約者以外の問い合わせを受け付けない。 オープンリゾルバーとして悪用されないよう、そのISPの回線から来た問い合わせだけに答える設定が一般的です。

つまり「ISPのキャッシュDNSをプリロードする」と言っても、外部から操作できる範囲はかなり限られます。

プリロードで期待できること・できないこと

「プリロード」という言葉で求められていることは、多くの場合次のどれかです。

DNS変更で困るのは「古い値がキャッシュに残っていること」です。変更前にキャッシュを温めても、古い値の保持を延ばすだけです。反映を早めたいなら、次に説明するTTLの事前短縮が正攻法です。

移転前にTTLを短くしておく

レコードを変更する予定があるなら、変更日の前にTTLを短くしておきます。ISPのキャッシュが古い値を保持する時間は、そのキャッシュが作られた時点のTTLで決まるためです。

1. 現在のTTLを権威DNSサーバーに直接問い合わせて確認する。
2. TTLを300秒程度に下げる。
3. 元のTTLの時間が過ぎるまで待つ。 元が86400秒（1日）なら、少なくとも1日待ちます。待たずに変更すると、長いTTLで作られたキャッシュがまだ残っています。
4. レコードの値を新しいサーバーに変更する。
5. 新しい値が行き渡ったら、TTLを元の長さに戻す。

権威DNSサーバーのTTLは次のように確認できます。+norecurse を付けると、キャッシュではなく権威サーバー自身の設定値が返ります。

dig example.com NS +short
dig @ns1.example-dns.net www.example.com A +norecurse

注意点として、リゾルバーの中にはTTLに最小値・最大値を設けて書き換えるものがあります。TTLを300秒にしても、それより長く保持するリゾルバーが一部に残る可能性はあります。そのため、旧サーバーはDNS変更後もしばらく止めずに動かしておき、旧サーバーへのアクセスが減ったことをログで確認してから停止します。

自分のISPリゾルバーでキャッシュを確認する・温める

自分が契約している回線からであれば、ISPのリゾルバーに直接問い合わせて、キャッシュの状態を見ることができます。ISPのリゾルバーのアドレスは、ルーターの管理画面のWAN側情報や、PCのDNS設定（ルーターを経由していなければ）で確認できます。

dig @198.51.100.53 www.example.com A

ANSWER欄のTTLが、権威DNSの設定値より小さく、数秒おきに実行して減っていれば、キャッシュから返っています。

この問い合わせで「キャッシュを温める」ことはできます。ただし前述のとおり、温まるのは自分の問い合わせが届いたサーバーだけです。社内の全員が同じISPリゾルバーを使っている小規模オフィスで、朝一番の待ちを減らしたいといった限られた場面以外では、効果を実感するのは難しいでしょう。スクリプトで大量に問い合わせ続けるのは、ISPの利用規約や負荷の面から避けてください。

パブリックDNSのキャッシュは消去を依頼できる

ISPのリゾルバーと違い、主要なパブリックDNSには、特定の名前のキャッシュ消去を依頼できるページがあります（2026年10月現在）。

• Google Public DNS の「Flush Cache」ページ
• Cloudflare の 1.1.1.1 向け「Purge Cache」ページ

DNS変更後に、パブリックDNSを使っている端末だけ古い値が返る場合は、これらで消去を依頼できます。ページの場所や操作は変わることがあるため、各サービスの公式ドキュメントから辿ってください。ISPのリゾルバーについては、一般向けの消去窓口は通常ありません。TTLが切れるのを待つのが基本です。

訪問者側で先読みさせる：dns-prefetch と preconnect

サイトの表示を速くしたいという意味の「プリロード」なら、ブラウザへのリソースヒントが実際に使える手段です。dns-prefetch は外部ドメインの名前解決を先に済ませるよう、preconnect はさらにTCP・TLSの接続まで先に張るよう、ブラウザに伝えます。ブラウザが問い合わせる先は訪問者のリゾルバー（多くはISPのキャッシュDNS）なので、結果としてそのキャッシュも使われます。

WordPressでは wp_resource_hints フィルターで追加できます。テーマを直接編集せず、子テーマの functions.php か mu-plugin に書きます。

<?php
/**
 * Plugin Name: Resource hints for external hosts
 */
add_filter( 'wp_resource_hints', function ( $urls, $relation_type ) {
	if ( 'dns-prefetch' === $relation_type ) {
		$urls[] = 'https://cdn.example.com';
	}
	if ( 'preconnect' === $relation_type ) {
		$urls[] = array(
			'href' => 'https://fonts.gstatic.com',
			'crossorigin',
		);
	}
	return $urls;
}, 10, 2 );

使い方のポイントは次のとおりです。

• 対象は、ほぼ全ページで使う外部ドメインだけにする。 preconnect は接続を実際に張るため、使わないドメインを並べると無駄な通信が増えます。
• 自サイトと同じドメインには不要。 HTMLを取得した時点で名前解決は済んでいます。
• キャッシュ系やSEO系のプラグインが同じ指定を出していないか確認する。 重複しても大きな害はありませんが、管理する場所は一か所にまとめたほうが分かりやすくなります。

効果は、ブラウザの開発者ツールのネットワークタブで、外部ドメインへの最初のリクエストの「DNS Lookup」や接続時間が短くなったかで確認します。PageSpeed Insights などの数値は回線や計測条件で変わるため、改善の幅を事前に約束することはできません。

まとめ

• ISPのキャッシュDNSに外部からレコードを送り込む仕組みはなく、キャッシュはサーバーごとに分かれている。
• DNS変更の反映を早めたいなら、先読みではなく、変更前にTTLを短くし、元のTTLの時間だけ待ってから変更する。
• 自分の回線からならISPリゾルバーに dig @アドレス で問い合わせてTTLを確認できるが、温められる範囲は限られる。
• パブリックDNSには公式のキャッシュ消去ページがある。ISPはTTL切れを待つのが基本。
• 表示速度のための先読みは、WordPressの wp_resource_hints で dns-prefetch / preconnect を必要なドメインにだけ指定する。

• TTLとDNS変更の反映時間
• DNSの浸透が遅いときの確認ポイント