DNS TTL 計算・換算ツール

TTL 計算ツールの使い方

入力欄は 3 つ、アカウント不要、計算はすべて手元で行われます。入力した値はどこにも送信されません。

1. 今の TTL を入れます。 これから変更するレコードに設定されている TTL を、秒数か 1h のような表記で入力します。読める時間への換算と、それが切り替え用・均衡・安定のどれに当たるかが出ます。
2. 変更の段取りを読みます。 作業中に使う低い TTL、それを何時間前に出しておくべきか、切り替え後にキャッシュが追随するまでの時間、そして終わったら戻す値が並びます。
3. NXDOMAIN が返っているなら SOA の数字も入れます。 dig SOA example.jp を実行し、minimum フィールドと SOA レコード自身の TTL を入力すると、RFC 2308 のネガティブキャッシュ時間——直したあと何分・何時間その否定が残るか——が出ます。

ネームサーバー変更:いつ下げて、いつ切り替えるか

TTL の秒数を調べる人が本当に知りたいのは、たいてい秒数そのものではありません。何かを移そうとしていて、その移行を短く済ませたい。そのための手順には、一つだけ直感に反する部分があります。

TTL を下げる効果は、変更より前に出しておいたときにしか出ません。しかも「古い TTL 1 本分」より前です。24 時間の TTL を切り替えの 10 分前に 300 秒へ変えても何も起きません。昨日のコピーを持っているリゾルバは、その新しい小さい値を明日まで見に来ないからです。まず古い TTL が自然に切れる必要があります。手順にすると、こうなります。

1. TTL を 300 秒へ下げる。古い TTL 1 本分より前に。余裕を見るなら 2 本分前(早めに更新するリゾルバもそうでないリゾルバもいるため)。
2. 切り替える。ネームサーバーを変更する、またはレコードの向き先を変える。
3. 低い TTL 1 本分——5 分——待つ。ここまでで、規則どおり動くキャッシュはすべて新しい答えを持ちます。
4. 安定を確認したら元の TTL に戻す。そうしないと、アクセスのたびに名前解決の代金を払い続けることになります。

唯一下げられないのが、委任そのものに付いている TTL です。あなたのネームサーバーを指す NS レコードは上位ゾーンにあり、レジストリが発行しています。jp. では 86400 秒、com. では 172800 秒です。自分のレコードを 300 秒にしても変更に長い尾が残るのはこのためで、だからこそ時計を見るより2 系統のリゾルバから委任を読むほうが情報量があります。

「浸透待ち」をやめたあとに引く、.jp の三つの数字

「DNS 浸透」という言い方が現象の説明として成り立たないことは、ネームサーバー確認ツールのページで扱いました。ここではその続きです。慣用句を捨てると、代わりに何を見ればいいのか。答えは三つの数字で、どれも .jp 固有の実測値です。以下はすべて 2026 年 9 月 4 日に権威サーバーへ直接問い合わせて確認した値で、同じコマンドで再現できます。

一つめ。.jp の委任 NS の TTL は 86400 秒(24 時間)です。JPRS のゾーンがあなたのドメインの NS レコードに付けている値で、あなたの側からは下げられません。

dig +norecurse NS example.jp @a.dns.jp
      example.jp.   86400   IN   NS   ns1.example-host.jp.

二つめ。.jp のネガティブキャッシュは 900 秒(15 分)です。jp. ゾーンが NXDOMAIN と一緒に返す SOA は、TTL が 900、minimum フィールドも 900。RFC 2308 は小さい方を採るので 900 秒です。これは主要 TLD のなかでは短い部類で、de. の 7200 秒(2 時間)の 8 分の 1 にあたります。存在しない .jp のサブドメインを一度叩いてしまっても、レコードを作れば 15 分で解消します——逆に言えば、15 分は待つ必要があります。

三つめ。よく引かれる「最大 72 時間」「48 時間」という数字は、.jp のものではありません。48 時間の出どころは com. の委任 TTL である 172800 秒で、.jp はその半分です。国内の事業者ヘルプが上限として 72 時間を書くのは、問い合わせを減らすための安全側の見積もりであって、測定値ではありません。.jp のドメインで実際に見積もるなら「自分のレコードは事前に下げれば 5 分、親の委任は最大 24 時間、存在しない名前の記憶は 15 分」の三つを足すのが正しい読み方です。

国内事業者側の値も測っておきました。各社が自社ゾーンで実際に返している値で、管理画面の既定値とは限りませんが、この市場で出会う幅は分かります。SOA の minimum は、エックスサーバーとさくらインターネットが 3600、GMO 系(お名前.com・ConoHa・バリュードメイン、いずれも Cloudflare 経由)が 1800、ロリポップが 86400。A レコードの TTL はエックスサーバーが 60、さくらが 3600 でした。この 4 社はいずれも minimum と SOA レコード自身の TTL が同じ値だったので、min() を取っても結果は変わりません——つまりこの差がそのままネガティブキャッシュの差になります。打ち間違えたサブドメインが「無い」と覚えられる時間が、事業者によって 30 分と丸 1 日ほど違う、ということです。二つの値がずれているゾーン——たとえば es. は minimum が 86400、SOA レコードの TTL が 3600——では、小さい方だけが効きます。

ネガティブキャッシュの計算:直した瞬間に直らない理由

この計算ツールの 3 つめと 4 つめの入力欄は、そのための数字です。RFC 2308 が定めるのは min(SOA の minimum, その SOA レコード自身の TTL) という一行の式で、両方の値は NXDOMAIN 応答の authority セクションに一緒に入ってきます。dig SOA example.jp を実行すれば、末尾の数字が minimum、行頭から 2 番目の数字が SOA レコードの TTL です。

この式が実務で効くのは、値が食い違うときです。たとえば es. ゾーンは minimum に 86400 を書いていますが、SOA レコード自身の TTL は 3600。minimum だけを読むと「1 日待たされる」と誤読しますが、実際の答えは小さい方の 1 時間です。逆に de. は 7200 と 7200 でどちらを読んでも同じ。式を一行で持っておくと、この読み違いをしなくて済みます。

そして、この数字の使いどころは判断の保留です。2026 年 6 月に当社が経験した委任障害(英語)では、レジストリ側の登録が 6 月 30 日 17:30 UTC に戻ったあとも、多くの利用者の環境で復旧は 7 月 1 日から 2 日でした。ネガティブキャッシュの窓の中にいたためです。実務上の結論は 2 つ。窓が明けるまで「まだ直っていない」と判断しないこと。そして窓の中で二度目の修正を入れないこと——正しい設定が、より雑な設定に上書きされる典型的な経路がこれです。

よく見る TTL の値と、それぞれの用途

設定した値ではなく、リゾルバがいま実際に持っている TTL を読むには dig example.jp +noall +answer。2 列目がそれで、キャッシュが古くなるにつれて減っていきます。Windows なら nslookup -debug example.jp で同じ欄が見えます。設定値よりはるかに小さい TTL が返るなら、想定と違う誰かがそのレコードを配信しています。逆に値がまったく減らないなら、キャッシュではなく権威サーバーを直接読んでいます。

$ npm i -g @clize/clize && clize install
$ clize domain check example.jp