家庭や小規模オフィスのルーターは、多くの場合DNSの中継役（フォワーダー）として動き、受け取った応答をTTLの間キャッシュしています。ルーターに残っているTTLは、PCからルーターのアドレスを指定して dig や nslookup -debug で問い合わせ、応答のTTLが時間とともに減るかを見れば確認できます。この記事では、ルーターがDNSを中継しているかの確かめ方、TTLの読み方、dnsmasq系ルーターでの追加の確認方法、古い値が残っているときの対処を説明します。
ルーターがDNSを中継しているか確認する
最初に、PCがどのDNSサーバーを使っているかを確認します。DHCPで配られるDNSサーバーがルーター自身のアドレス（例：192.168.1.1）なら、名前解決はルーターを経由しています。
ipconfig /allWindowsでは「DNS サーバー」の項目、macOSでは scutil --dns、Linux（systemd-resolved）では resolvectl status で確認できます。ここにプロバイダーやパブリックDNSのアドレスが直接書かれていれば、ルーターはDNSに関与しておらず、ルーターのキャッシュを気にする必要はありません。
なお、IPv6環境ではルーター広告（RA）やDHCPv6でIPv6のDNSサーバーが配られ、IPv4とは別の経路で問い合わせていることがあります。IPv4とIPv6の両方のDNSサーバーを書き出しておくと、後の切り分けで迷いません。
ルーターに直接問い合わせてTTLを見る
ルーターのアドレスを指定して問い合わせると、応答の ANSWER 欄に表示されるTTLが、ルーターのキャッシュに残っている秒数になります。
dig @192.168.1.1 www.example.com A;; ANSWER SECTION:
www.example.com. 245 IN A 203.0.113.10この例の 245 が残りのTTLです。10秒ほど待って再実行し、235 前後に減っていれば、ルーターのキャッシュから答えが返っています。digが無いWindowsでは、nslookup -debug を使うと応答の詳細に ttl = が表示されます。
nslookup -debug www.example.com 192.168.1.1PowerShellの Resolve-DnsName www.example.com -Server 192.168.1.1 -DnsOnly でも TTL 列で確認できます。
本来のTTLと比べる
キャッシュの残りTTLは、権威DNSサーバーに設定された本来のTTLと比べると意味が分かります。権威DNSサーバーは問い合わせのたびに設定値そのものを返すため、次のように直接問い合わせます。
dig www.example.com NS +short
dig @ns1.example-dns.net www.example.com A +norecurse権威側が 300 で、ルーターが 245 なら、ルーターは55秒前に取得した値を保持している、と読めます。ルーターに問い合わせるたびに常に権威側と同じ値が返る場合は、ルーターがキャッシュしていないか、キャッシュの直後に問い合わせている可能性があります。逆に、権威側のTTLより大きな値が返る場合は、ルーターやその上流が最小TTLを独自に設定し、本来より長くキャッシュしていることを疑います。
ルーターとその上流を分けて見る
ルーターは自分で権威DNSまでたどるのではなく、プロバイダーのDNSなどに中継していることがほとんどです。そのため、ルーターが返すTTLは「上流のキャッシュに残っていた時間」をそのまま引き継いでいることもあります。上流のDNSサーバーにも直接問い合わせて比べると、どこで古い値が保持されているかを切り分けられます。
dig @プロバイダーのDNSサーバー www.example.com A上流のアドレスはルーターの管理画面のWAN側の情報などに表示されていることが多いですが、表記は機種によって異なります。
dnsmasq 系のルーターで追加の確認をする
OpenWrtなど多くのルーターはdnsmasqでDNSを中継しています。dnsmasqは、特殊な問い合わせ（CHAOSクラスのTXTレコード）でキャッシュの統計を返す機能を持っています。
dig @192.168.1.1 cachesize.bind CH TXT +short
dig @192.168.1.1 hits.bind CH TXT +short
dig @192.168.1.1 misses.bind CH TXT +shortキャッシュサイズやヒット数が返れば、dnsmasqがキャッシュしていると分かります。機種によってはこの機能が無効にされていたり、dnsmasq以外のソフトウェアが動いていたりするため、応答が無くても異常とは限りません。
SSHでログインできるルーターなら、dnsmasqにSIGUSR1を送るとシステムログに統計が書き出されます（設定によってはキャッシュの内容も出力されます）。
killall -USR1 dnsmasq
logread | grep dnsmasqdnsmasqには最小・最大のキャッシュTTLを決める min-cache-ttl、max-cache-ttl という設定項目があります。権威側より長いTTLが返っていた場合は、これらが設定されていないか確認します。最小TTLを伸ばすとDNS変更の反映が遅れるため、特別な理由が無ければ設定しないほうが扱いやすくなります。
存在しない名前の否定キャッシュ
レコードを追加した直後に、ルーター経由だけ「名前が存在しない（NXDOMAIN）」と返ることがあります。追加前に誰かが問い合わせ、その否定応答がキャッシュされている状態です。否定応答の保持時間は、ゾーンのSOAレコードに設定された値で決まり、応答の AUTHORITY 欄に含まれるSOAのTTLで残り時間を確認できます。
dig @192.168.1.1 new.example.com A古い値が残っているときの対処
多くの家庭用ルーターはDNSキャッシュをメモリに持っているため、再起動すれば消えます（2026年10月現在、管理画面にキャッシュ消去のボタンがある機種は多くありません）。ただし、再起動中はネットワーク全体が止まるので、利用者が少ない時間に行います。
再起動したくない場合は、次の方法もあります。
- 残りTTLが短ければ、切れるまで待つ。
- 確認したい端末だけ、DNSサーバーをパブリックDNSなどに一時的に変更する（社内ネットワークでは管理者の方針に従う）。
- サイトの移転確認が目的なら、hostsファイルで新サーバーを指定して表示を確かめる。
ルーターのキャッシュを消しても、上流のプロバイダーのDNSが古い値を持っていれば、また古い値が返ります。消す前に「ルーター」「上流」「権威」の3か所のTTLを並べて、どこで古いかを確かめておくと手戻りが減ります。また、次回のDNS変更では、事前にTTLを短くしておくと、ルーターを含むすべてのキャッシュが早く入れ替わります。
まとめ
- PCのDNSサーバーがルーターのアドレスなら、ルーターがDNSを中継・キャッシュしている。
dig @ルーターやnslookup -debugで返るTTLは、キャッシュの残り秒数。時間をおいて減るかで確認する。- 権威DNSのTTLと上流DNSのTTLも並べると、どこで古い値が保持されているか分かる。
- dnsmasq系ならCHAOSクラスの問い合わせやSIGUSR1で統計を確認でき、
min-cache-ttlの設定も確認する。 - 多くのルーターは再起動でキャッシュが消えるが、上流が古ければ効果は無い。事前にTTLを短くしておくのが予防になる。