DNSキャッシュとは？TTLとの関係と名前解決を高速化する仕組み
KoAN
目次
DNSキャッシュとTTLの仕組み
DNSはインターネットを支える重要な仕組みですが、毎回すべてのDNSサーバへ問い合わせを行っているわけではありません。
もし世界中の端末がWebサイトへアクセスするたびに、ルートDNSサーバから順番に問い合わせを行っていたら、膨大な負荷が発生してしまいます。
そこで利用されているのがDNSキャッシュです。
DNSキャッシュは、一度取得した名前解決結果を一定時間保存し、再利用する仕組みです。このキャッシュ時間を制御しているのがTTL（Time To Live）です。
本記事では、DNSキャッシュの仕組みやTTLとの関係、実際の運用で注意すべきポイントについて解説します。
DNSキャッシュとは
DNSキャッシュとは、一度取得したDNS問い合わせ結果を一定期間保存する仕組みです。
例えば、ブラウザで次のサイトへアクセスしたとします。
https://www.example.com/
DNSサーバは次のような情報を返します。
www.example.com. IN A 93.184.216.34
この結果をキャッシュとして保存しておけば、次回同じドメインへアクセスする際に再度問い合わせる必要がありません。
これにより名前解決を高速化できます。
なぜDNSキャッシュが必要なのか
DNSキャッシュが存在しない場合、すべての名前解決で次の処理が必要になります。
- ルートDNSサーバへ問い合わせ
- TLD DNSサーバへ問い合わせ
- 権威DNSサーバへ問い合わせ
- IPアドレス取得
毎回この処理を実行すると、DNSサーバへの負荷が非常に大きくなります。
また、応答速度も遅くなります。
キャッシュを利用することで、過去の結果を再利用できるため、高速な名前解決が可能になります。
キャッシュされる場所
DNSキャッシュは複数の場所で保持されます。
ブラウザキャッシュ
ChromeやFirefoxなどのブラウザは独自のDNSキャッシュを持っています。
同じタブや同じブラウザ内でのアクセスを高速化します。
OSキャッシュ
WindowsやLinuxもDNSキャッシュを保持します。
OSレベルでキャッシュされるため、すべてのアプリケーションが利用できます。
キャッシュDNSサーバ
企業やISPのDNSサーバもキャッシュを保持します。
最も効果が大きいのはこのキャッシュです。
複数のユーザーが同じ名前解決結果を共有できます。
TTLとは
TTLはTime To Liveの略です。
DNSレコードがどのくらいの時間キャッシュされるかを秒単位で指定します。
例えば次の設定です。
www.example.com. 3600 IN A 93.184.216.34
3600秒は1時間です。
つまり、このDNS情報は最大1時間キャッシュされます。
TTLの動作
TTLが3600秒の場合を考えてみます。
12:00に名前解決を行った場合です。
12:00 DNS問い合わせ
↓
キャッシュ保存
↓
13:00まで利用可能
13:00までは再問い合わせを行わずにキャッシュを利用できます。
TTLが切れると再度DNS問い合わせが実行されます。
TTLが長い場合のメリット
TTLを長く設定すると次のようなメリットがあります。
- DNS問い合わせ回数を削減できる
- DNSサーバ負荷を軽減できる
- 名前解決速度が向上する
アクセス数の多いサイトでは非常に効果があります。
TTLが長い場合のデメリット
TTLが長いとDNS変更時に問題が発生します。
例えば次のようなケースです。
旧サーバ
↓
新サーバへ移行
DNSを変更しても、利用者のキャッシュには古いIPアドレスが残っています。
その結果、しばらく旧サーバへ接続され続けます。
TTLが短い場合のメリット
TTLを短くすると変更が素早く反映されます。
例えばTTLを300秒に設定した場合です。
300秒 = 5分
DNS変更後、最大5分程度で新しい情報へ切り替わります。
TTLが短い場合のデメリット
DNS問い合わせ回数が増加します。
- DNSサーバ負荷増加
- 通信量増加
- 応答時間増加
そのため常に短く設定するのが正解とは限りません。
実務でよく使われるTTL
| TTL | 用途 |
|---|---|
| 300秒 | 移行作業前 |
| 600秒 | 頻繁に変更するサービス |
| 3600秒 | 一般的なWebサイト |
| 86400秒 | ほとんど変更しないレコード |
サーバ移行時のTTL運用
サーバ移行ではTTLが重要になります。
例えば通常のTTLが86400秒の場合です。
86400秒 = 24時間
DNS変更後も24時間古い情報が残る可能性があります。
そのため移行前にTTLを短くします。
移行1週間前
↓
TTLを300秒へ変更
↓
移行実施
↓
反映確認
↓
TTLを元へ戻す
これが一般的な運用です。
DNSキャッシュによるトラブル
DNS変更が反映されない
最も多いトラブルです。
DNSレコードを変更したにも関わらず、利用者が古いサーバへ接続してしまいます。
一部の利用者だけ古い情報を参照する
キャッシュが保持されている期間が異なるためです。
利用者によって異なる結果になる場合があります。
切り替え確認ができない
管理者自身のPCに古いキャッシュが残っているケースです。
この場合はキャッシュ削除が必要です。
Windowsでキャッシュ確認
Windowsでは次のコマンドで確認できます。
ipconfig /displaydns
キャッシュ削除は次のコマンドです。
ipconfig /flushdns
Linuxでキャッシュ確認
systemd-resolvedを利用している場合です。
resolvectl statistics
キャッシュ削除です。
sudo resolvectl flush-caches
digコマンドでTTL確認
digコマンドを使うとTTLを確認できます。
dig example.com
結果の例です。
example.com. 3600 IN A 93.184.216.34
3600がTTLです。
TTLは減少していく
キャッシュされたTTLは時間経過とともに減少します。
例えば3600秒でキャッシュされた場合です。
3600
↓
3500
↓
3000
↓
1000
↓
0
0になると再問い合わせが発生します。
CDNとTTL
CloudflareやCloudFrontなどのCDNでもTTLは重要です。
DNSキャッシュだけでなく、コンテンツキャッシュにもTTLが利用されています。
適切なTTL設定によってパフォーマンスを向上できます。
DNSキャッシュポイズニングとの関係
DNSキャッシュは便利な仕組みですが、攻撃対象になることがあります。
DNSキャッシュポイズニングは偽のDNS情報をキャッシュへ登録する攻撃です。
現在ではランダムポートやDNSSECなどの対策が利用されています。
まとめ
DNSキャッシュは、一度取得した名前解決結果を再利用する仕組みです。
DNSキャッシュによって名前解決は高速化され、DNSサーバへの負荷も軽減されます。
TTLはキャッシュ保持時間を制御する重要な値であり、DNS運用において非常に重要な要素です。
TTLを長くすると性能面で有利になりますが、変更反映は遅くなります。TTLを短くすると変更は反映しやすくなりますが、DNSサーバへの負荷が増加します。
サーバ移行やDNS変更時にはTTLを意識した運用を行うことで、トラブルを最小限に抑えることができます。
