DNSキャッシュ(TTL)と伝搬時間

インターネットの世界で通信の基礎となるDNSは、全世界のネットワーク利用者から利用されるため、DNSサーバには膨大な負荷がかかります。

そんなDNSサーバに対して、負荷を軽減し、更には利用者への回答速度を向上する仕組みが、DNSのキャッシュです。

前の「権威DNSとキャッシュDNS」にて、キャッシュDNSサーバの解説をしましたが、今回は「キャッシュ」にフォーカスをして解説していきます。

重要な要素でありながら、DNSサーバの管理を行う側からするとトラブルの素で厄介な存在だったりします。

きちんと仕組みを理解して、管理できるようにしましょう。

DNSキャッシュとは、一度行われた名前解決の結果を一時的に保存し、再利用する仕組みのことを言います。

インターネット上の名前解決において、負荷軽減と迅速な回答利用を目的に実装された仕組みです。

基本的に名前解決では、権威DNSという名前解決において正解を回答できるDNSサーバがいます。

この権威DNSへ問い合わせを行うことで名前解決を行うのですが、都度都度問い合わせを行うと権威DNSサーバやその途中にいるルートDNSサーバ等に大きな負荷がかかってしまいます。

そこで、DNSのレコードというのはそこまで頻繁に変更されるものではないということで、一定期間については回答を問い合わせ側に記憶しておいてもらって都度問い合わせしなくてよいということにしました。

これがDNSのキャッシュという仕組みです。

権威DNSよりもらった回答を一時的にキャッシュにて記憶しておきますが、ずっとその回答を使い続けられてしまうと、権威DNS側でレコードの変更が入ったときに対応ができません。


このような問題が起きないように、権威DNS側でクライアントが保存する回答の期間を設定することができます。

これがDNSキャッシュの保持期間設定で「TTL」という設定です。

TTLは、「Time To Live」の略で、直訳すると「生存時間」という意味です。

言葉の意味の通りで権威DNSからもらった回答の有効期間を意味するもので、この時間を過ぎた回答については再利用不可となり、再度、権威DNSサーバまで問い合わせを行う必要があります。


このTTLを設定することで、権威DNSサーバ側でのレコード変更時に利用者全員へきちんと設定がいきわたるようにコントロールができるのです。

DNSのキャッシュ時間をコントロールするTTLの設定には少し癖があります。

TTLは長く設定するほど権威DNSサーバへの負荷を軽減することが可能です。

例えば、TTLを1秒などにしてしまうとDNSキャッシュの意味がまるでありません。

ただ、逆にこのTTLを長くしすぎると変更が反映しづらくなります。

例えば、TTLを30日に設定したとします。

このレコードは30日間はクライアントは再度問い合わせしてきませんので、この期間内にレコードを変更してしまうとクライアントが接続できなくなってしまいサービス影響が発生します。

また、TTLを30日に設定したレコードを変更のために、より短く5分に変更したとしても、クライアントにはすぐにTTLの変更は反映されない点に注意が必要です。

細かく見てみましょう。

最初のTTL30日の状態で回答を得たクライアントは、30日間は権威DNSに聞きに行く必要はなくなります。

この状態で、権威DNS側のレコード設定でTTLを5分に変えたとします。

ただ、クライアントは30日間は聞きに行く必要がないので、TTLを5分に変えたとしても設定は反映されないのです。

設定変更したTTLは前回の回答の期限が切れた後にようやく反映されます。


このような注意点があるため、TTLは長すぎても管理がしづらいという特性があるため、一般的に5分~1時間程度、長くても24時間程度が多いと思います。

TTLによるDNSキャッシュには、もう一つ注意点があります。

DNSをキャッシュする機器というのは実は複数あり、ここでも階層構造が作られています。

なので、実際にレコードの変更が反映されるまでには、TTLで設定した期間以上に時間が必要になるケースがあります。

このケースがDNSの設定変更などでは複雑なため把握していない人が多く、トラブルになりやすい点です。

DNSのキャッシュは、実は複数の場所で行われており、主に以下のポイントでキャッシュされています。

これらの各ポイントで、DNSのキャッシュを行っているのです。

この複数のポイントでキャッシュを行っている関係でレコードの変更が伝搬されるまでの時間がTTLの設定以上にかかることがありますので、詳細に解説します。

まず、クライアントPCは、ChromeやFirecoxなどのブラウザにURLを入力して、アクセスするときに名前解決が行われます。

実際にはOSに名前解決するように指示を出し、OSはキャッシュDNSサーバに問い合わせを行うという流れです。

さて、この時にそれぞれが回答をキャッシュする期間を見てみましょう。

まずは、キャッシュDNSが権威DNSより回答を得て、レコードをキャッシュしているとします。

その後、権威DNSはレコードに変更を加えました。

29日後に、今度はクライアントから名前解決の問い合わせがあり、キャッシュDNSがキャッシュから回答します。


もう1日経過(30日目)すると、キャッシュDNSはTTLが切れるので、権威DNSサーバに問い合わせすることになります。

ここでようやく、権威DNSサーバのレコード変更がキャッシュDNSサーバに伝搬しました。


更に29日経過(59日目)すると、クライアントがキャッシュしているレコードのTTLが切れるので、キャッシュDNSサーバに問い合わせに行くことになります。

クライアントにもようやく、権威DNSサーバで変更したレコードが伝搬しました。


重要な点なので細かく見てきましたが、上記のようにTTLは30日にも関わらず、クライアントに届いたのは59日経過してからでした。

キャッシュするポイントが複数あるということはこのようなTTLの予期せぬ長期化を生むことがあります。

これに引っかかってしまうと、計画した期間以上にDNSのレコードが反映されず、トラブルに発展してしまうことがあるのです。

これまでDNSキャッシュに関する説明を行ってきましたが、メリットとデメリットを整理します。

観点	メリット	デメリット
応答速度	• 頻繁に使われるドメインの名前解決が高速化 • ウェブサイトなどのアクセス時間が短縮 • ユーザー体験が向上	• キャッシュが肥大化すると検索時間が増加する可能性
ネットワークトラフィック	• 権威DNSサーバへのリクエスト数が減少 • インターネット全体のトラフィックを削減 • ネットワーク帯域幅の節約	• 特になし
負荷分散	• 権威DNSサーバの負荷を軽減 • ルートサーバなど重要インフラへの依存を減らす	• 特になし
信頼性	• 権威サーバが一時的に不通になってもサービス継続可能 • DNSサービスの可用性向上	• 古いキャッシュデータに依存してしまう可能性
データ鮮度	• TTL（Time To Live）で鮮度管理可能	• DNSレコード更新後も古い情報が使われ続ける • TTLが長いと変更の反映に時間がかかる • DNSの変更伝播に遅延が生じる
運用コスト	• サーバリソースの効率的な利用 • 外部DNSサーバへのクエリ数減少によるコスト削減	• キャッシュ管理に追加リソースが必要 • キャッシュサーバの運用・保守コスト
障害対応	• 一時的なDNS障害の影響を緩和	• キャッシュ自体に問題が生じた場合、影響が広範囲 • 誤ったキャッシュデータのトラブルシューティングが複雑

DNSのキャッシュに関して、解説を行いました。

今回の内容は実際の現場においてもよく発生するトラブルに基づいて、事前に知っておいていただきたい点を重点的に説明しています。

TTLによるレコードの伝搬遅延などが最たる例となります。

知識があれば、事前に防げるものになりますので、今のうちに覚えておきましょう。