DNS TTLとは？3600秒は60分（1時間）。秒数の早見表と確認方法

ユイ

あしたの朝9時に、ラボのサイトを新しいサーバーへ移します。DNSの管理画面に「TTL 3600」とあるのですが、これは何分ですか？

ピコ

60分だよ。このままだと、切り替えたあとも最長60分は、古いサイトへ行く人が残る。きょうのうちに、打てる手があるよ

DNSのTTLは、DNSの答えを覚えておいてよい時間を、秒で表した値です。3600なら60分（1時間）、300なら5分、86400なら24時間（1日）です。

60で割ると分、もう一度60で割ると時間になります。意外なのは、ふだんの回線で確かめると、3600より小さい数字が返ってくること。故障ではなく、残り時間です。

TTL 3600は何分？秒数を分・時間に直す早見表

TTLは Time To Live の略です。DNSの管理画面でも、確認のコマンドでも、単位は秒。よく出る数字を並べました。

※ 3列目の出どころは、0がRFC 1035、60・120・3600・86400・172800がAWS（Route 53）、300がCloudflare、10800がBIND 9、604800がRFC 8767です（2026年10月10日確認）。

表にない数字も、60で割れば分になります。2700なら45分。86400は、1日をそのまま秒にした数です（60秒×60分×24時間）。

表で読めるのは、設定した時間です。自分のドメインがいま何秒なのかは、コマンド1行で確かめられます。

DNS TTLを確認する方法｜dig・nslookup・Resolve-DnsName

道具は、パソコンの種類で決まります。どれもDNSの答えを読むだけで、設定は変えません。

※ example.com を調べたい名前に、A（IPv4の住所）を調べたいレコードの種類に置き換えます。下の出力の数字と住所は、読み方を示すための例です。

digでは、答えが1行で返ります。

example.com.  3000  IN  A  192.0.2.10

+noall +answer は、答えの行だけに絞る指定です。何も出ないときは、TTLが0なのではなく、答えの欄が空だったということ。指定を外して dig example.com A と打ち、status の行を確かめます。同じ出力の SERVER の行には、答えたDNSサーバーが出ます。

Resolve-DnsNameは、答えが表の形で返り、列の名前がそのまま「TTL」です。

nslookupは、-debug を付けると、送った問い合わせと返ってきた答えの中身をくわしく表示します。TTLは、その答えの欄にあります。

ユイがdigを打つと、返ってきたのは3000でした。管理画面は3600のままです。

設定は3600なのに、3000と返ってきた。なぜ数字が違う？

漫画：同じTTLなのに、数字が違う？ 全4ページ

ユイは設定3600秒と返答3000秒の違いを模型で比べる。ピコと10分経った例をたどり、次に設定だけ300秒へ短くしても元から残っていた控えが同時に変わるわけではないと見る。最後に設定と返答をボードの別の欄へ分け、空の確認メモを持って、どこの値かも残すと決める。

先に本文の解説を読む ↓

画像を押すと拡大できます。＋／−で大きさを変え、拡大中はドラッグして読めます。

1 / 4設定と返答の数字が違う

ラボのDNS模型でユイが設定の3600秒と、控えの返答の3000秒の札を比べる。 設定と返答の見出しをそれぞれの札に添える。

1ページ目のセリフ

• 値の役割「設定」・「返答」
• 模型の設定「3600秒」・返答「3000秒」
• ユイ「設定と、数字が違う？」

2 / 4残りの時間を読んでいる

ユイとピコが一枚の大きなボードを見る。例の3600秒から10分経った残り3000秒を縦の経過矢印で示す。

2ページ目のセリフ

• 架空の経過の札「例」
• 初めの札「3600秒」
• 経過の札「10分」
• 残りの札「3000秒」
• 残り時間の札「残り」

3 / 4設定を変えても、控えは別

上段でユイが設定の青い札を300秒へ替える。下段ではピコが先に保存した控えの橙3000秒と砂時計を示す。

3ページ目のセリフ

• 設定の札「設定」・「300秒」
• 保存済みの札「控え」・「3000秒」

4 / 4別の欄へ残す

上段でユイがボードの設定と返答の別の欄へ青と橙の空札を分ける。下段では空の確認メモを持ち、どこの値かも残すと決める。

4ページ目のセリフ

• メモの欄「設定」・「返答」
• ユイ「どこの値かも、残します。」

横にスワイプして次のページへ。画像を押すと拡大できます。

数字と砂時計はTTLの読み方を示す架空の例で、実在ドメインの設定や観測結果ではありません。3600秒から10分経った残り3000秒は単純化した一つのキャッシュの例です。TTLは世界中の利用者が一斉に切り替わるカウントダウンではなく、問い合わせ先や更新、各実装の方針で返る値が変わります。設定変更は既存キャッシュの期限を遡って一斉に書き換える操作ではありません。DNS以外の表示キャッシュやエラーの原因は別に確認します。

本文の解説へ ↓

閉じる ×

← 前

−

100%

＋元の大きさ

次 →

拡大中はマウスや指でドラッグできます。100%では左右スワイプ・左右キーでページ送り。

違うのは、聞いた相手です。ふだんの回線で聞くと、答えるのはキャッシュDNS。一度調べた答えの控えを取っておき、同じ質問にはその控えで答える係です。台帳そのものを持つのは権威DNS（そのドメインのネームサーバー）で、管理画面の3600は、こちらに書かれています。

キャッシュDNSは、権威DNSから答えを受け取った瞬間に、3600秒の砂時計をひっくり返します。あとは聞かれるたびに、残りの秒数を付けて控えを返します。受け取ってから10分（600秒）たっていれば、3600 − 600 ＝ 3000。digを打つたびに数字が減るのも、同じ砂時計を見ているからです。砂が落ちきった控えは捨てられ、次に聞かれたときに権威DNSへ聞き直すので、数字はまた3600から始まります。

設定した値そのものを見たいときは、権威DNSに直接聞きます。

dig example.com NS +short
dig @ns1.example.net example.com A +noall +answer

1行目で出たネームサーバーの名前を、2行目の @ のあとに入れます（ns1.example.net は例）。台帳には砂時計が付いていないので、何度聞いても3600です。Windowsでは、Resolve-DnsName に -Server を足して、聞く相手を指定します。

※ flags の行は、+noall +answer を外すと出ます。aa は、台帳を持つサーバー自身の答えだという印です。

3000は、そのキャッシュDNSが持つ控え1枚の残り時間です。世界中が切り替わるまでの秒読みではありません。別の回線のキャッシュDNSは、別の時刻に控えを受け取り、別の数字を返します。人によって見えるサイトが違うときの確かめ方は、DNSを変えたあと、表示がそろわない理由で扱っています。

砂時計の大きさは、管理画面で決められます。3600のままがよいのか、もっと小さくするのか。

TTLはどれくらいに設定すればいい？公式の目安

決まった正解はありません。AWS（Route 53）の案内も「正しい値は無い」と書いたうえで、変更が行きわたるのをどれだけ待てるかで決めるよう勧めています。公式の資料に、よく選ばれる値として出てくる数字は、次のとおりです。

※ 2026年10月10日に各社の公式ページで確認。Cloudflareの範囲は、プロキシを通さないレコードのもの（Enterpriseプランの下限は30秒）で、プロキシを通すレコードは300秒で固定です。自分のDNSサービスの初期値と選べる範囲は、管理画面で確かめます。

長くするほうには天井があります。聞く側は、長すぎる値を7日（604800秒）で頭打ちにするよう勧められていて（RFC 8767）、DNSサーバーのソフト BIND 9 の初期値も1週間です。TTLは「ここまでは覚えてよい」という上限で、聞く側はもっと早く捨ててかまいません（RFC 2181）。

昔は、もっと長いのがふつうでした。DNSの決まりを書いた1987年の文書（RFC 1034）は、ふつうのホストなら「日の単位」がよいとしています。いまは、公式の案内に5分や1分が並びます。

TTLを短くしすぎると何が起きる？

ユイ

ずっと60秒にしておけば、移転のたびに悩まずに済みませんか？

マコト

砂時計が小さいと、ひっくり返す回数が増えるんだ。そのたびに、台帳の持ち主まで聞きに行くことになるよ

起きることは3つあります。

1. 聞き直しが増えます。1台のキャッシュDNSが、控えが切れるたびに聞き直すと、86400秒なら1日1回、300秒なら288回、60秒なら1,440回です※。AWSは、問い合わせの量と費用が増えると案内しています。
2. 名前を引くのに時間がかかる場面が増えます。控えがあれば、その場で答えられるからです。
3. 権威DNSが止まると、すぐに引けなくなります。TTLが300秒なら、止まって5分でどの控えも切れ、聞き直す先がありません。

※ 86400をTTLで割っただけの計算です。実際の回数は、その名前を聞く人の数と、キャッシュDNSの数で変わります。

3つめをふさぐため、2020年のRFC 8767は、聞き直せないときに限り、期限の切れた控えを使ってよいと決まりを改めました。ただし、使うかどうかは聞く側が決めます。

だから、短くするのは変更の前後だけ。残る問いは、いつ短くするかです。

サーバー移転の前、TTLはいつ短くする？6つの手順

切り替える時刻から、いまのTTLぶん以上さかのぼって短くします。いまが3600なら1時間以上前、86400なら24時間以上前です。

直前では間に合いません。設定を300に書き換えても、その前に3600で配られた控えの砂時計は縮まず、最長で1時間そのまま使われます。漫画の3ページ目で、設定の札を300に替えても、控えの札が3000のままだった場面です。

Cloudflareは、DNSの移行では24〜48時間以上前、できればいまいちばん長いTTLに合わせて短くするよう勧めています。迷ったら、丸1日以上前に済ませます。

いまのTTLが3600で、あしたの朝9時に切り替える例です。

前もって短くし、終わったら戻す。このやり方は、1987年のRFC 1034にもう書かれています。

手順のあいだ、メモは欄を分けて書きます。漫画の最後でユイが決めたとおり、どこに聞いた値かも残します。

• 名前とレコードの種類: ＿＿＿＿（A / CNAME / MX / TXT）
• 設定したTTL（権威DNSに聞いた値）: ＿＿＿＿秒
• 返ってきたTTL（残り）と、聞いた相手・時刻: ＿＿＿＿秒 / ＿＿＿＿
• TTLを短くした時刻 / 行き先を変えた時刻: ＿＿＿＿ / ＿＿＿＿

手順どおりに進めても、落とし穴がひとつ残ります。新しく作った名前が、自分の回線でだけ引けないことがあるのです。

作ったばかりの名前が引けない。「無い」という答えにも期限がある

キャッシュDNSは、「その名前は無い」「その種類のレコードは無い」という答えも控えます。ネガティブキャッシュと呼ばれるしくみです。レコードを足す前にその名前を引くと、「無い」の控えが残り、足したあともしばらく「無い」と返ります。

MINIMUM は、dig example.com SOA +noall +answer で出る行の、最後の数字です。新しい名前は、レコードを足してから引きます。先に引いてしまったら、「無い」の期限が切れるのを待ちます。

ミニクイズ：TTLの数字を読める？

Q1. TTL 3600は何分ですか？

A. 60分（1時間）です。TTLは秒で書くので、60で割ると分、もう一度60で割ると時間になります。300は5分、86400は1日です。

Q2. DNSのTTLは、どうやって確認しますか？

A. MacやLinuxでは dig example.com A +noall +answer の2番目の数字、WindowsのPowerShellでは Resolve-DnsName -Name example.com -Type A の「TTL」の列を見ます。ふだんの回線で返るのは残り時間で、設定した値は権威DNSに聞くと分かります。

Q3. サーバー移転の前、TTLはいつ短くしますか？

A. 切り替える時刻から、いまのTTLぶん以上前です。3600なら1時間以上前、86400なら24時間以上前。直前に短くしても、先に配られた控えの期限は縮みません。

あしたの9時に切り替えるなら、きょうのうちに300へ

ユイは、管理画面の「3600」の横に「60分」と書き、メモに一行足しました。きょうのうちに、TTLを300へ。行き先はまだ変えない。これで、あしたの切り替えのあとに古い控えが残る時間は、最長60分から5分に縮みます。

いまなら「TTL 3600は何分？」に答えられ、digで返った3000を残り時間と読め、短くする時刻を逆算できます。

切り替えたあと、人によって古いサイトが見えたら、待つのか設定を見直すのかをDNS変更後の確かめる順番で分けられます。キャッシュDNSが権威DNSまで聞きに行く道のりはDNSの仕組みに、調べ終えた答えにTTLの時計を付けて棚へ置く場面は物語の第42話にあります。