DNSのTTLとはなんなのか

DNSのTTLとは、Time To Liveの略で、DNSレコードの情報をキャッシュしてよい最大時間を表す値です。

簡単にいうと、DNSのTTLは、

このDNS情報は、最大で〇秒間キャッシュして使ってよい

という有効期限のようなものです。

たとえば、次のようなAレコードがあるとします。

example.com.  3600  IN  A  203.0.113.10

この 3600 がTTLです。

この場合、DNSリゾルバや端末は、

example.com のIPアドレスは 203.0.113.10
この情報は最大3600秒、つまり1時間キャッシュしてよい

と判断します。

つまりTTLは、DNS情報を毎回問い合わせ直すのではなく、一定時間キャッシュして再利用するための仕組みです。

DNSとTTLの基本

Webサイトにアクセスするとき、私たちは通常、次のようなドメイン名を使います。

example.com

しかし、インターネット上の通信では、実際にはIPアドレスが使われます。

203.0.113.10

そのため、ブラウザで example.com にアクセスすると、裏側ではまず、

example.com のIPアドレスは何ですか？

という問い合わせが行われます。

このように、ドメイン名をIPアドレスなどに変換する仕組みがDNSです。

ただし、アクセスのたびに毎回DNSの大元まで問い合わせていると、時間がかかり、DNSサーバーへの負荷も増えます。

そこで、DNSでは一度取得した情報を、DNSリゾルバやOS、ブラウザなどが一時的に保存します。

この一時保存がDNSキャッシュです。

そして、そのキャッシュをどれくらいの時間使ってよいかを決めるのがTTLです。

TTLの単位

DNSのTTLは、通常秒単位で指定します。

よく使われるTTLの例は次の通りです。

TTL	時間	よくある用途
60	1分	緊急切り替え、動的な構成
300	5分	サーバー移転前、CDN切り替え前
600	10分	変更予定があるレコード
1800	30分	比較的標準的な運用
3600	1時間	通常運用のWebサイト
86400	24時間	ほとんど変更しないレコード

一般的なWebサイトでは、通常時は 3600、サーバー移転やCDN切り替え前は 300 にするケースがよくあります。

TTLは「DNSの反映時間」そのものではない

DNSのTTLで特に誤解されやすいのが、反映時間との関係です。

TTLはよく、

DNS変更が反映されるまでの時間

のように説明されることがあります。

しかし、厳密には少し違います。

TTLは、

DNS情報をキャッシュしてよい最大時間

を表す値です。

つまり、DNS変更後に「必ずTTL秒後に世界中で反映される」という意味ではありません。

たとえば、TTLが3600秒のAレコードがあるとします。

あるDNSリゾルバが10:00に古い情報を取得した場合、そのリゾルバは最大11:00まで古い情報をキャッシュする可能性があります。

その後、10:30にあなたがAレコードを変更しても、そのリゾルバは11:00までは古いIPアドレスを返す可能性があります。

つまり、DNS変更の反映は、

変更した瞬間からTTL秒

ではなく、

各DNSリゾルバが最後に情報を取得した時点からTTL秒

で考える必要があります。

具体例：TTL 3600秒でAレコードを変更した場合

たとえば、変更前のDNS設定が次のようになっていたとします。

example.com
TTL: 3600
Aレコード: 203.0.113.10

10:00に、あるDNSリゾルバがこの情報を取得しました。

10:00
example.com → 203.0.113.10
TTL: 3600秒

この場合、そのリゾルバは最大11:00まで古い情報をキャッシュできます。

その後、10:30にDNSレコードを変更したとします。

example.com
TTL: 3600
Aレコード: 203.0.113.20

しかし、10:00に旧情報を取得していたリゾルバは、11:00までは古いIPアドレスを返す可能性があります。

10:00  旧情報を取得
10:30  DNSを変更
10:45  まだ旧IPが返る可能性あり
11:00  キャッシュ期限切れ
11:01  新しい情報を取得する可能性あり

このように、DNS変更後は一時的に、

• あるユーザーは新サーバーにアクセスする
• 別のユーザーは旧サーバーにアクセスする

という状態が起こることがあります。

TTLが長い場合のメリット・デメリット

TTLを長くすると、DNS情報が長くキャッシュされます。

メリット

TTLが長いと、DNS問い合わせの回数が減ります。

そのため、次のようなメリットがあります。

メリット	内容
DNS問い合わせが減る	キャッシュが長く使われるため、問い合わせ回数が少なくなる
DNSサーバーへの負荷が下がる	権威DNSサーバーへのアクセスを抑えやすい
DNS解決が安定しやすい	キャッシュが使われるため、名前解決が速くなる場合がある
一時的なDNS障害に強くなる場合がある	キャッシュが残っていれば、しばらく名前解決できる可能性がある

デメリット

一方で、TTLが長いとDNS変更の反映に時間がかかりやすくなります。

たとえばTTLが86400秒、つまり24時間の場合、Aレコードを変更しても、古いIPアドレスが最大24時間程度キャッシュされる可能性があります。

そのため、次のような場面では注意が必要です。

デメリット	内容
サーバー移転時に切り替わりが遅い	旧サーバーへアクセスされ続ける可能性がある
緊急対応に弱い	障害時に別IPへ切り替えても、古い情報が残る場合がある
メール設定の反映が遅れる	MX、SPF、DKIM、DMARCなどの変更にも影響する
CDN切り替えに時間がかかる	古いCDNや旧サーバーへのアクセスが残る可能性がある

TTLが短い場合のメリット・デメリット

TTLを短くすると、DNS情報のキャッシュ時間が短くなります。

メリット

TTLが短いと、DNS変更が比較的早く反映されやすくなります。

たとえばTTLを300秒にしておけば、多くのDNSリゾルバでは5分程度で再問い合わせが行われやすくなります。

メリット	内容
サーバー移転がしやすい	IP変更後、比較的早く新サーバーへ向きやすい
障害対応に使いやすい	緊急時に別サーバーへ切り替えやすい
CDNやロードバランサーと相性がよい	動的な構成変更に対応しやすい
検証・移行期間に便利	DNS変更のテストや段階的移行がしやすい

デメリット

一方で、TTLを短くしすぎるとDNS問い合わせの回数が増えます。

デメリット	内容
DNSクエリ数が増える	キャッシュが早く切れるため、問い合わせが増える
DNSサーバーへの負荷が増える	高トラフィックサイトでは影響が出る可能性がある
DNS障害の影響を受けやすくなる場合がある	キャッシュが短いため、障害時に古い情報で耐えにくい
一部環境では設定どおりにならない場合がある	リゾルバ側のポリシーで最低TTLが設けられることがある

ただし、小規模〜中規模の一般的なWebサイトであれば、TTLを300秒にしても大きな負荷問題になるケースは多くありません。

大規模サイトやアクセス数の多いサービスでは、DNSクエリ数、コスト、権威DNSの耐障害性も含めて検討する必要があります。

TTLはどこでキャッシュされるのか

DNSのキャッシュは、さまざまな場所で行われます。

代表的には次のような場所です。

DNSリゾルバ

ユーザーが利用しているDNSリゾルバは、DNS情報をキャッシュします。

たとえば以下のようなものです。

8.8.8.8
1.1.1.1
プロバイダのDNSサーバー
社内DNSサーバー

TTLが3600秒であれば、リゾルバはその情報を最大1時間キャッシュする可能性があります。

OS

Windows、macOS、LinuxなどのOSもDNSキャッシュを持つことがあります。

そのため、DNSリゾルバ側では新しい情報になっていても、PC側に古い情報が残っている場合があります。

ブラウザ

ChromeやFirefoxなどのブラウザも、独自にDNSキャッシュを持つことがあります。

DNSを変更したあとに表示が変わらない場合、ブラウザの再起動やシークレットウィンドウでの確認が役立つことがあります。

アプリケーションやミドルウェア

一部のアプリケーション、プログラム、サーバー、プロキシ、CDNなども名前解決結果をキャッシュすることがあります。

そのため、TTLを短くしても、アプリケーション側のキャッシュが原因で古い向き先が使われ続けることがあります。

「DNSの浸透」という表現は正確ではない

DNS変更について、よく「DNSが浸透する」という表現が使われます。

たとえば、

DNSの浸透には24〜72時間かかります

という説明を見かけることがあります。

ただし、技術的にはDNS情報が世界中にじわじわ広がっていくわけではありません。

実際には、

各DNSリゾルバや端末に残っている古いキャッシュが期限切れになり、次回問い合わせ時に新しい情報を取得する

という動きです。

そのため、「DNSの浸透」というより、

DNSキャッシュの期限切れ待ち

と考えるほうが正確です。

クライアントや社内向けに説明する場合は、

DNS変更後は、各環境に残っているキャッシュの影響で、反映タイミングに差が出ることがあります。

と説明するとわかりやすいです。

TTLはレコードごとに設定するのか

実務上は、TTLはDNSレコードごとに設定すると考えて問題ありません。

たとえば、次のようにAレコード、CNAME、MX、TXTで異なるTTLを設定できます。

example.com.      300   IN  A     203.0.113.10
www.example.com.  300   IN  CNAME example.com.
example.com.      3600  IN  MX    10 mail.example.com.
example.com.      3600  IN  TXT   "v=spf1 include:_spf.example.com ~all"

この場合、それぞれのTTLは次のようになります。

レコード	TTL	意味
Aレコード	300秒	WebサーバーのIPを5分キャッシュ
CNAME	300秒	wwwの別名情報を5分キャッシュ
MXレコード	3600秒	メールサーバー情報を1時間キャッシュ
TXTレコード	3600秒	SPFなどのTXT情報を1時間キャッシュ

なお、より厳密には、同じ名前・同じタイプ・同じクラスのDNSレコード群、つまりRRset単位でTTLをそろえる必要があります。

たとえば、同じ example.com にAレコードが複数ある場合です。

example.com. 300 IN A 203.0.113.10
example.com. 300 IN A 203.0.113.20

この2つは同じRRsetに属します。

一般的なDNS管理画面では、このような細かい仕様を意識しなくても運用できることが多いですが、専門的には「レコードごと」だけでなく「RRset単位」という考え方もあります。

SOAレコードとネガティブキャッシュ

DNSでは、「存在するレコード」だけでなく、「存在しない」という結果もキャッシュされることがあります。

これをネガティブキャッシュといいます。

たとえば、まだ作成していないサブドメインにアクセスしたとします。

test.example.com

このときDNSが、

test.example.com は存在しません

という応答を返した場合、その「存在しない」という結果も一定時間キャッシュされることがあります。

その後すぐに test.example.com のAレコードを追加しても、過去に「存在しない」という結果を取得した環境では、しばらく存在しない扱いのままになる可能性があります。

このネガティブキャッシュには、SOAレコードの値が関係します。

より厳密には、ネガティブキャッシュのTTLは、SOAレコードのMINIMUM値やSOAレコード自体のTTLに影響されます。

そのため、新しいサブドメインや新しいTXTレコードを追加した直後に反映されない場合は、通常のTTLだけでなく、ネガティブキャッシュも原因になり得ます。

A、AAAA、CNAME、MX、TXTとTTLの関係

DNSのTTLは、レコードの種類ごとに意識する必要があります。

Aレコード

Aレコードは、ドメインをIPv4アドレスに向けるレコードです。

example.com → 203.0.113.10

Webサーバー移転やIP変更では、AレコードのTTLが非常に重要です。

AAAAレコード

AAAAレコードは、ドメインをIPv6アドレスに向けるレコードです。

example.com → 2001:db8::1

IPv6対応しているサイトでは、AレコードだけでなくAAAAレコードも確認する必要があります。

Aレコードだけ新サーバーに変更しても、AAAAレコードが旧サーバーを向いたままだと、IPv6環境のユーザーだけ旧サーバーへアクセスすることがあります。

CNAMEレコード

CNAMEは、あるドメイン名を別のドメイン名の別名として扱うレコードです。

www.example.com → example.com

または、CDNやSaaSのホスト名に向けることもあります。

www.example.com → example.cdn-provider.net

CNAMEでは、自分のDNSに設定したCNAMEのTTLだけでなく、参照先のAレコードやAAAAレコードのTTLも関係します。

たとえば次のような構成です。

www.example.com CNAME example.cdn-provider.net
example.cdn-provider.net A 203.0.113.10

この場合、www.example.com のCNAMEがキャッシュされ、さらに example.cdn-provider.net のAレコードもキャッシュされます。

そのため、CNAMEのTTLだけ見ていると、実際の切り替わりを誤解することがあります。

MXレコード

MXレコードは、メールを受信するメールサーバーを指定するレコードです。

example.com → mail.example.com

メールサーバーを移行する場合、MXレコードのTTLが重要です。

また、メールでは送信元メールサーバー側の再送制御も関係するため、WebサーバーのAレコード変更とは挙動が少し異なります。

TXTレコード

TXTレコードは、SPF、DKIM、DMARC、Google Search Console認証、各種SaaS認証などでよく使われます。

たとえばSPFは次のようなTXTレコードです。

v=spf1 include:_spf.example.com ~all

メール認証の設定変更では、TXTレコードのTTLも確認する必要があります。

TTLを短くしてもすぐ反映されない理由

TTLを短くしたのに、DNS変更がすぐ反映されないことがあります。

主な理由は次のとおりです。

変更前の長いTTLがまだ効いている

たとえば、もともとのTTLが86400秒だったとします。

10:00にあるDNSリゾルバが旧情報を取得しました。

その後、10:30にTTLを300秒へ変更しても、そのリゾルバはすでに、

この情報は86400秒キャッシュしてよい

と判断しています。

そのため、TTLを短くする操作そのものも、古いTTLの影響を受けます。

サーバー移転前にTTLを短くする場合は、元のTTL以上の余裕を持って実施する必要があります。

DNSリゾルバが独自のキャッシュポリシーを持っている

一部のDNSリゾルバや社内DNSでは、設定されたTTLとは異なるキャッシュポリシーを持つ場合があります。

たとえば、短すぎるTTLに対して最低キャッシュ時間を設けているケースがあります。

OSやブラウザにキャッシュが残っている

DNSリゾルバでは新しい情報になっていても、利用者のPCやブラウザに古い情報が残っている場合があります。

この場合、以下の対応で改善することがあります。

• ブラウザを再起動する
• シークレットウィンドウで確認する
• OSのDNSキャッシュをクリアする
• 別のブラウザで確認する
• 別回線で確認する
• 別のDNSリゾルバで確認する

権威DNSサーバー側の反映に時間差がある

DNS事業者によっては、管理画面で変更した内容が、すべての権威DNSサーバーへ反映されるまで少し時間がかかることがあります。

複数の権威DNSサーバーがある場合、あるサーバーは新しい情報を返し、別のサーバーは古い情報を返す、ということもあります。

そのため、DNS変更直後は、権威DNSサーバーごとに結果を確認すると安心です。

期限切れデータが一時的に使われる場合がある

DNSリゾルバによっては、権威DNSサーバーに問い合わせできない場合、期限切れになった古いキャッシュを一時的に返すことがあります。

これは可用性を高めるための仕組みですが、DNS変更直後には「まだ古い情報が返っている」ように見える原因になることがあります。

サーバー移転時のTTL設定

Webサイトのサーバー移転では、TTLの扱いが非常に重要です。

一般的には、次の流れで進めると安全です。

移転数日前に現在のTTLを確認する

まず、現在のAレコード、AAAAレコード、CNAMEのTTLを確認します。

たとえば、TTLが86400秒の場合、最大24時間程度キャッシュされる可能性があります。

現在のTTL: 86400秒

この状態で移転直前にDNSを変更すると、旧サーバーへアクセスされ続ける時間が長くなる可能性があります。

移転前にTTLを短くする

移転前にTTLを短くしておきます。

TTL: 86400
↓
TTL: 300

ただし、このTTL変更自体も、もともとのTTLの影響を受けます。

そのため、現在のTTLが86400秒なら、少なくとも24時間以上前、できれば1〜2日前にはTTLを短くしておくと安全です。

移転時にAレコードやCNAMEを変更する

TTLが短くなった状態で、DNSの向き先を新サーバーへ変更します。

旧IP: 203.0.113.10
新IP: 203.0.113.20
TTL: 300

TTLが300秒であれば、条件が整っている環境では、比較的短時間で新しい向き先へ切り替わりやすくなります。

ただし、すべてのユーザー環境で必ず5分以内に切り替わるわけではありません。

移転後もしばらく旧サーバーを残す

DNS変更後も、しばらくは旧サーバーへアクセスされる可能性があります。

そのため、移転後すぐに旧サーバーを停止するのは避けたほうが安全です。

目安としては、少なくとも変更前TTLの最大値以上、可能であれば24〜72時間程度は旧サーバーを稼働させておくと安心です。

特に以下のようなサイトでは注意が必要です。

• WordPressサイト
• ECサイト
• 会員制サイト
• フォーム送信があるサイト
• 予約システム
• 投稿やコメント機能があるサイト

旧サーバーと新サーバーにアクセスが分散すると、データの不整合が起きる可能性があるためです。

問題なければTTLを通常値に戻す

移転後、問題がないことを確認したら、TTLを通常値に戻します。

TTL: 300
↓
TTL: 3600

一般的なWebサイトであれば、通常時は3600秒程度で運用することが多いです。

TTL設定の目安

実務では、次のような目安で考えるとわかりやすいです。

状況	おすすめTTL
通常運用のWebサイト	3600秒
変更予定があるWebサイト	300〜600秒
サーバー移転前後	300秒
CDN切り替え前後	300秒
ロードバランサー利用	60〜300秒
メール関連レコード	3600〜86400秒
ほぼ変更しないTXTレコード	3600〜86400秒
障害対応を想定する重要サービス	60〜300秒

一般的なコーポレートサイトやオウンドメディアであれば、次のような運用が扱いやすいです。

通常時:
A / AAAA / CNAME: 3600
MX: 3600〜86400
TXT: 3600〜86400

移転・切り替え前:
A / AAAA / CNAME: 300

移転後:
A / AAAA / CNAME: 3600に戻す

Cloudflareなどを使う場合の注意点

CloudflareのようなDNS・CDNサービスでは、通常のDNSとはTTLの扱いが少し異なることがあります。

たとえば、Cloudflareでプロキシ機能が有効になっているDNSレコードは、TTLが自動設定になり、ユーザーが自由に変更できない場合があります。

また、DNS onlyのレコードであれば、プランや設定によってTTLを選択できることがあります。

そのため、CloudflareやCDNを使っている場合は、

• DNSレコードがプロキシされているか
• DNS onlyになっているか
• TTLがAutoになっているか
• CDN側のキャッシュが残っていないか
• オリジンサーバーの向き先が正しいか

も確認する必要があります。

DNSのTTLだけでなく、CDNのキャッシュ、ページキャッシュ、ブラウザキャッシュが原因で古い表示が残ることもあります。

DNS変更を確認する方法

DNSのTTLや現在の向き先は、コマンドで確認できます。

digコマンド

DNS確認では dig コマンドがよく使われます。

dig example.com A

結果の例です。

;; ANSWER SECTION:
example.com.  3600  IN  A  203.0.113.10

この 3600 がTTLです。

Google Public DNSに問い合わせる場合は、次のようにします。

dig @8.8.8.8 example.com A

Cloudflare DNSに問い合わせる場合は、次のようにします。

dig @1.1.1.1 example.com A

権威DNSをたどって確認したい場合は、次のコマンドを使います。

dig +trace example.com

権威DNSサーバーを直接指定して確認することもできます。

dig @ns1.example-dns.com example.com A

このように、どのDNSサーバーに問い合わせているかを明確にすると、DNS変更の切り分けがしやすくなります。

nslookupコマンド

Windows環境では nslookup も使えます。

nslookup example.com

ただし、TTLの確認や詳細な切り分けには、dig のほうが使いやすいことが多いです。

PowerShellでは、次のように確認することもできます。

Resolve-DnsName example.com -Type A

DNS変更時の実務チェックリスト

DNS変更やサーバー移転では、TTLだけでなく周辺設定も確認することが重要です。

DNSまわり

• AレコードのTTL
• AAAAレコードの有無
• CNAMEの向き先
• wwwあり・なし両方の設定
• MXレコード
• SPF、DKIM、DMARC
• TXT認証レコード
• DNSSECの有無
• ネームサーバー変更の有無
• 旧DNSと新DNSのレコード差分
• 権威DNSサーバーごとの応答

Webサイトまわり

• 新サーバーでサイトが正しく表示されるか
• SSL証明書が有効か
• httpからhttpsへリダイレクトされるか
• wwwあり・なしが正しく統一されているか
• 主要URLのステータスコードが正しいか
• 404や500エラーが出ていないか
• robots.txtが正しいか
• sitemap.xmlが正しいか
• canonicalが正しいか
• OGP画像が表示されるか
• CSS、JavaScript、画像が正しく読み込まれるか
• フォーム送信ができるか
• WordPress管理画面にログインできるか

よくある誤解

誤解1：TTLを300秒にすれば必ず5分で反映される

TTLを300秒にしても、すべての環境で必ず5分以内に反映されるわけではありません。

古いTTLのキャッシュ、OSキャッシュ、ブラウザキャッシュ、社内DNS、ISPのDNS、CDNキャッシュなどが影響する場合があります。

誤解2：DNS変更後にTTLを短くすれば早くなる

DNS変更後にTTLを短くしても、すでに古いTTLでキャッシュされている情報にはすぐ効きません。

TTLを短くするなら、DNS変更の前に行う必要があります。

誤解3：TTLはドメイン全体で1つだけ

TTLはドメイン全体で1つだけ設定するものではありません。

Aレコード、CNAME、MX、TXTなど、レコードの種類ごとに異なるTTLを設定できます。

ただし、同じ名前・同じタイプのレコード群では、TTLをそろえる必要があります。

誤解4：TTLを短くすればサイト表示が速くなる

TTLを短くしても、サイト表示が速くなるわけではありません。

むしろ、DNSキャッシュが早く切れるため、DNS問い合わせの回数が増える可能性があります。

サイト表示速度の改善には、DNSのTTLよりも、サーバー応答速度、画像最適化、キャッシュ設定、CDN、HTML/CSS/JavaScriptの改善などのほうが重要です。

誤解5：DNSが変わらない原因は必ずTTLである

DNS変更が反映されない原因は、TTLだけではありません。

たとえば、次のような原因があります。

• 編集しているDNSゾーンが違う
• 実際に使われているネームサーバーと管理画面が違う
• Aレコードだけ変更してAAAAレコードが残っている
• CNAMEの参照先が古い
• CDN側の設定が残っている
• ブラウザキャッシュが残っている
• SSL証明書が正しく設定されていない
• サーバー側のバーチャルホスト設定が間違っている
• DNSSECの設定に問題がある

DNS変更がうまく反映されない場合は、TTLだけでなく、DNS全体の設定とサーバー側の設定を切り分けて確認する必要があります。

まとめ

DNSのTTLとは、DNSレコードの情報をキャッシュしてよい最大時間のことです。

TTLが長いと、DNS問い合わせが減り、安定しやすくなります。

一方で、DNS変更の反映には時間がかかりやすくなります。

TTLが短いと、DNS変更が比較的早く反映されやすくなります。

一方で、DNS問い合わせが増え、DNSサーバーへの負荷が高くなる可能性があります。

特に重要なのは、TTLは、

DNS変更後に必ず何秒で反映されるか

を示すものではないという点です。

正しくは、

各DNSリゾルバや端末が、取得済みのDNS情報を最大何秒キャッシュしてよいか

を示す値です。

サーバー移転やCDN切り替えを行う場合は、変更直前ではなく、事前にTTLを短くしておくことが大切です。

一般的なWebサイトであれば、通常時は3600秒、移転や切り替え前は300秒程度を目安にすると運用しやすいです。

以上、DNSのTTLとはなんなのかについてでした。

最後までお読みいただき、ありがとうございました。