SOAレコードのTTLを検証するときは、「SOAレコード自体のTTL」と「SOAの最後の数値（MINIMUM）」の2つを読み、そこから実際に効いている「存在しない応答のキャッシュ時間」を確かめ、最後にすべての権威DNSサーバーで値がそろっているかを見ます。この記事では、dig を使った具体的な確認手順と、結果の読み方、値が妥当かを判断する目安を説明します。
SOAのTTLを省略・既定値に戻す方法や、SOA全体の誤設定の直し方は別の記事で扱っているため、ここでは「今の値が正しく効いているかを確かめる」ことに絞ります。
検証の対象になる3つの値
SOAに関係するTTLは、混同されやすいので最初に整理します。
- SOAレコード自体のTTL: SOAという1件のレコードを、キャッシュDNSが何秒覚えておいてよいか
- MINIMUM: SOAの値の最後の数値。現在の仕様（RFC 2308）では、「その名前やレコードは存在しない」という応答をキャッシュする時間の上限として使われる
- 実際のネガティブキャッシュ時間: 1と2のうち小さいほう。キャッシュDNSが「存在しない」という応答を覚えておく時間
日常の運用で影響が大きいのは3です。新しいサブドメインやTXTレコードを追加したのに、しばらく「存在しない」と返され続ける現象は、この時間で決まります。
ステップ1：SOAの値を読み取る
+multiline を付けると、各数値の意味を注釈付きで表示してくれます。
dig +multiline +noall +answer example.com SOAexample.com. 3600 IN SOA ns1.example.net. hostmaster.example.com. (
2026101801 ; serial
7200 ; refresh (2 hours)
3600 ; retry (1 hour)
1209600 ; expire (2 weeks)
3600 ; minimum (1 hour)
)先頭の行の 3600 がSOAレコード自体のTTL、括弧の中の最後の 3600 がMINIMUMです。この例では両方とも1時間なので、ネガティブキャッシュの時間も1時間になります。
ここで公開DNS経由の結果を見ている場合、先頭のTTLはキャッシュの残り秒数になっていることがあります。設定値を見るには、次のステップのように権威DNSに直接問い合わせます。
ステップ2：権威DNSに直接問い合わせる
まず、ドメインの権威DNSサーバーを調べます。
dig +short NS example.com表示されたサーバーを指定し、再帰問い合わせをしない設定で聞きます。
dig @ns1.example.net +norecurse +multiline +noall +answer example.com SOAこの結果のTTLは、キャッシュの影響を受けない設定値です。管理画面やゾーンファイルに書いた値と一致しているかを確かめます。BINDのゾーンファイルでは、SOAの行にTTLを書いていなければ、ファイル先頭の $TTL の値が使われます。ゾーンファイルの変更が読み込まれているかは、シリアル番号が増えているかで判断できます。
ステップ3：すべての権威サーバーでそろっているか
権威DNSが複数ある場合、そのうちの1台だけ古い値を返していると、問い合わせ先によって結果が変わります。+nssearch を使うと、各権威サーバーのSOAをまとめて確認できます。
dig +nssearch example.com各行のシリアル番号が同じなら、すべてのサーバーが同じ版のゾーンを持っています。1台だけシリアルが古い場合は、ゾーン転送が止まっているか、そのサーバーへの変更の反映が遅れています。
TTLまで比べたいときは、サーバーごとに問い合わせます。
for ns in $(dig +short NS example.com); do
echo "== $ns"
dig @"$ns" +norecurse +noall +answer example.com SOA
doneマネージドDNSでは通常、全サーバーに同じ値が配られますが、DNSサービスの移行中に旧サービスのネームサーバーがNSに残っているといった場合には食い違います。
ステップ4：ネガティブキャッシュ時間を実測する
実際に「存在しない」応答がどれだけキャッシュされるかは、存在しない名前を問い合わせると確かめられます。
dig @ns1.example.net +norecurse nonexistent-check.example.com Astatus: NXDOMAIN の応答に、AUTHORITY SECTION としてSOAが付いて返ってきます。
;; AUTHORITY SECTION:
example.com. 3600 IN SOA ns1.example.net. hostmaster.example.com. 2026101801 7200 3600 1209600 3600この行のTTLが、キャッシュDNSが「存在しない」応答を覚えておく時間です。仕様では、権威サーバーはここにSOAのTTLとMINIMUMの小さいほうを入れることになっているため、ステップ1で計算した値と一致するはずです。一致しない場合は、DNSサービスが独自の値を使っている可能性があります。
存在する名前でも、問い合わせたレコード型が無ければ同じようにSOAが付きます（status: NOERROR で回答が空になります）。すでにAレコードがある名前にAAAAやTXTを追加し、その前に問い合わせが来ていたケースは、こちらに当たります。
キャッシュDNS側でも確かめたい場合は、同じ問い合わせを公開DNSに2回送ります。
dig @8.8.8.8 nonexistent-check.example.com A | grep -A1 "AUTHORITY SECTION"2回目のTTLが減っていれば、その公開DNSに否定応答がキャッシュされ、残り時間が数えられていることが分かります。
ステップ5：値が妥当かを判断する
決まった正解はありませんが、次を目安にします。
- ネガティブキャッシュ時間: RFC 2308 では1〜3時間程度がうまく機能するとされています。長すぎると、追加したレコードが見えるまでの待ち時間が延びます
- SOAレコード自体のTTL: ほかのレコードと同程度（1時間前後）にしている運用が多く見られます
- キャッシュDNSの上限: キャッシュDNSの多くは、否定応答のキャッシュ時間に独自の上限を設けています。SOAで1日と書いても、実際にはそれより短く扱われることがあります
レコードの追加を控えている時期は、MINIMUMとSOAのTTLを短めにしておくと、追加前の問い合わせで「存在しない」がキャッシュされても早く解消します。変更する場合は、ゾーンファイルやDNSの設定をバックアップしてから行い、変更後にステップ2〜4をもう一度実行します。
マネージドDNSでは、SOAを編集できるサービスと、固定値で変更できないサービスがあります。設定可能な範囲はサービスやプランで違い、変わることもあります（2026年10月現在）。編集できない場合は、ステップ4で実際の時間を把握し、作業計画に組み込みます。
外部ツールでの補助的な確認
DNSViz や Zonemaster のような外部の診断サービスを使うと、権威サーバー間のSOAの食い違いや、値の組み合わせに関する警告をまとめて確認できます。ただし判断の根拠は、ここまでの dig の結果と、自分で書いた設定値の照合に置くのが確かです。ツールの表示や判定基準は更新で変わることがあります。
まとめ
- SOAのTTL、MINIMUM、そして実際のネガティブキャッシュ時間（両者の小さいほう）を分けて読む
- 設定値は権威DNSに
+norecurseで直接問い合わせて確かめる +nssearchで全権威サーバーのシリアルがそろっているかを見る- 存在しない名前への問い合わせで、AUTHORITY SECTION のSOAのTTLを実測する
- 1〜3時間程度を目安に、レコード追加の予定に合わせて値を見直す