ルーターのDNSキャッシュは、管理画面に一覧が無い機種がほとんどです。そこで、ルーターとその上流のDNSサーバーに同じ名前を一定間隔で問い合わせ、返ってくるTTLの推移を記録すると、ルーターがキャッシュしているか、TTLを書き換えていないか、再起動で消えるかを外から判定できます。この記事では、テスト用レコードを使った測定の手順と、記録した数字の読み方を説明します。サイト移転の前に一度測っておくと、自分の環境で古い値がどれくらい残るかを見積もれます。
準備：測定に使う3つの問い合わせ先とテスト用レコード
測定では、次の3か所に同じ名前を問い合わせて比べます。
- ルーター：PCのDNSサーバーとして配られているアドレス（例：192.168.1.1）。Windows は
ipconfig /all、macOS はscutil --dns、Linux はresolvectl statusで確認します。 - 上流のDNSサーバー：ルーターが中継している先。ルーターの管理画面のWAN側の情報に表示されることが多いですが、表記は機種によって異なります。
- 権威DNSサーバー：レコードを管理しているサーバー。
dig example.com NS +shortで調べます。
問い合わせる名前は、普段使っているレコードではなく、測定専用のサブドメインを作るのがおすすめです。たとえば自分のドメインに ttltest.example.com を作り、TTLを120秒程度にしておきます。こうすると、他の人の問い合わせの影響を受けにくく、途中で値を変えて切り替わる時間も測れます。DNSの管理画面で操作する前に、現在のゾーンの設定を控えておいてください。
IPv6のDNSサーバーが別に配られている環境では、IPv4とIPv6で別の経路を通っていることがあります。どちらで測っているかをメモしておきます。
手順1：一定間隔でTTLを記録する
ルーターと上流に同時に問い合わせ、時刻・TTL・IPアドレスを並べて記録します。macOS や Linux では次のようなループで十分です。
for i in $(seq 1 20); do
printf '%s router=[%s] upstream=[%s]\n' "$(date +%T)" \
"$(dig @192.168.1.1 ttltest.example.com A +noall +answer | awk '{print $2, $5}')" \
"$(dig @198.51.100.53 ttltest.example.com A +noall +answer | awk '{print $2, $5}')"
sleep 15
doneWindows の PowerShell では Resolve-DnsName を使います。上流の分も同じように -Server を変えて実行します。
1..20 | ForEach-Object {
$r = Resolve-DnsName ttltest.example.com -Type A -Server 192.168.1.1 -DnsOnly
'{0} ttl={1} ip={2}' -f (Get-Date -Format HH:mm:ss), $r.TTL, $r.IPAddress
Start-Sleep -Seconds 15
}15秒間隔で20回なら5分ほどで終わり、TTL120秒のレコードなら2周以上の推移が見えます。問い合わせの間隔を極端に短くしたり、長時間回し続けたりすると上流に負荷をかけるため、必要な回数にとどめます。
あわせて、1回ずつの応答時間も見ておくと判断材料になります。dig の出力の最後にある「Query time」が数ミリ秒ならキャッシュから、数十ミリ秒以上なら上流まで問い合わせに行った可能性が高いと読めます。
dig @192.168.1.1 ttltest.example.com A | grep "Query time"手順2：記録の読み方
記録したTTLの推移は、おおむね次のパターンに分かれます。
ルーターがキャッシュしている
ルーターのTTLが15秒ごとに減っていき、0付近になると、その時点で上流から取り直した値（上流もキャッシュしていればその残り時間、していなければ設定値の120）に戻る。上流のTTLとはずれた値で減っていく。この場合、ルーターは独自にキャッシュを持っており、TTLどおりに保持しています。
ルーターは中継しているだけ
ルーターと上流のTTLが毎回ほぼ同じ値になる。ルーターはキャッシュせず、上流の答えをそのまま返しています。古い値が残る場所は、ルーターではなく上流です。
TTLが本来より長く書き換えられている
ルーターのTTLが、権威DNSに設定した120秒より大きい値（例：300や600）から減り始める。ルーターやその上流に最小キャッシュ時間が設定され、TTLを引き延ばしています。DNS変更の反映がその分だけ遅れることになります。どの層で延びているかは、上流のTTLと比べて判断します。
TTLが上限で切られている
テスト用レコードのTTLを86400秒など長い値にして測ると、ルーターが3600などの値までしか返さない場合があります。これは最大キャッシュ時間が設定されている状態で、反映の面ではむしろ有利に働きます。
0で止まる、または期限切れ後も古い値が返る
TTLが0のまま返ってくる場合は、ルーターがキャッシュしていないか、上流の応答をそのまま中継しています。一方、レコードを変更した後もしばらく古い値が短いTTLで返り続ける場合は、期限切れのキャッシュを一時的に使い続ける機能（serve-stale）が上流やルーターで有効になっている可能性があります。
手順3：値を変えて、切り替わるまでの時間を測る
TTLの推移だけでなく、実際にレコードを変えたときに何秒で新しい値に切り替わるかを測ると、移転時の見積もりに直結します。
- 手順1のループを動かしたまま、DNSの管理画面でテスト用レコードのIPアドレスを別の値に変更する。
- 権威DNSサーバーが新しい値を返し始めた時刻を確認する（
dig @権威サーバー ttltest.example.com A +norecurse）。 - ルーター経由で新しい値が返るようになった時刻を記録する。
権威側で変わってからルーター経由で変わるまでの時間が、TTL（120秒）前後に収まっていれば、TTLどおりに入れ替わる環境です。大きく超える場合は、手順2で見た最小キャッシュ時間や上流のキャッシュが影響しています。
測定が終わったら、テスト用レコードは削除するか、使わない値に戻しておきます。
手順4：再起動でキャッシュが消えるか確かめる
ルーターに残りTTLが十分ある状態で再起動し、再起動直後に問い合わせます。TTLが設定値近くに戻り、Query time が長くなっていれば、キャッシュはメモリ上にあり再起動で消えると分かります。再起動中はネットワーク全体が止まるので、利用者の少ない時間に行います。
上流のTTLが変わらずに続いていれば、ルーターを再起動しても上流のキャッシュは残る、ということも確認できます。
測定結果を移転作業に生かす
測定結果は、測定した日付とルーターの機種・ファームウェアの版と一緒に、次のような形で記録しておくと次回の作業で役立ちます。ルーターの挙動はファームウェアの更新で変わることがあるため、記録は「いつ時点の結果か」が分かる形にしておきます。家庭用ルーターで、キャッシュの一覧や設定を管理画面に出す機種は多くありません（2026年10月現在）。
- ルーターがキャッシュするか、TTLを延ばすか、延ばすなら何秒か。
- 上流のDNSサーバーのTTLの扱い。
- 権威側で変更してからルーター経由で切り替わるまでの実測時間。
この結果をもとに、移転前にTTLをどこまで短くし、何時間前から短くしておけばよいかを決めます。ただし、これは自分の回線での結果です。サイトの訪問者は別のISPやルーターを使っているため、旧サーバーはDNS変更後もしばらく動かしておき、アクセスが無くなったことをログで確認してから止めます。
まとめ
- ルーター・上流・権威DNSの3か所に同じ名前を一定間隔で問い合わせ、TTLとIPの推移を記録する。
- 測定には専用のテスト用サブドメインを使うと、他の問い合わせの影響を受けず、切り替わる時間も測れる。
- ルーターのTTLが上流とずれて減るならルーターがキャッシュ、毎回一致するなら中継のみ。本来より長いTTLは最小キャッシュ時間の設定を疑う。
- 値を変更して切り替わるまでの実測時間と、再起動でキャッシュが消えるかを確かめておく。
- 結果は自分の環境の目安として記録し、移転時のTTL短縮の計画に使う。