DNSのレコードにはどれもTTLが付くため、SOAレコードのTTLを「無し」にすることはできません。実際にできるのは、ゾーンファイルでSOAの行からTTLの数字を省いてゾーン全体の既定値（$TTL）を使わせること、またはマネージドDNSで独自に変えたTTLを既定の値に戻すことです。この記事では、SOAに関係する2つのTTLの違いを整理したうえで、BINDのゾーンファイルとマネージドDNSのそれぞれで「TTLを削除したい」という目的をかなえる手順と、変更後の確かめ方を説明します。
「SOAのTTL」は2つある
SOAレコードの話でTTLというと、次の2つのどちらかを指しています。どちらを消したい（戻したい）のかで、やることが変わります。
- SOAレコード自体のTTL: 他のレコードと同じく、キャッシュDNSがSOAレコードを保持してよい時間です。ゾーンファイルではレコードの名前の後ろ、
INの前に書きます - SOAの最後のフィールド（MINIMUM）: 現在は「その名前やレコードは存在しない」という答えをキャッシュする時間（ネガティブキャッシュTTL）の上限として使われます（RFC 2308）
ネガティブキャッシュの保持時間は、この2つのうち短い方です。そのため、SOAレコード自体のTTLを変えると、「追加したレコードがしばらく見えない」状態がどれだけ続くかにも影響します。
もう1つよくある誤解が、「MINIMUMはゾーン全体の既定TTLだ」というものです。古い仕様（RFC 1035）ではそう読める書き方でしたが、RFC 2308で意味が変わり、既定TTLは $TTL で指定するようになりました。MINIMUMを消しても（そもそもフィールドは省略できません）、他のレコードのTTLは変わりません。
なぜTTLを「無し」にできないのか
DNSの応答では、すべてのレコードにTTLの値が入ります。ゾーンファイルの書式ではTTLを省略して書けますが、それは「値が無い」という意味ではなく、「別の場所で決めた値を使う」という意味です。BINDでの扱いは次のとおりです。
$TTLが書かれていれば、TTLを省略したレコードにはその値が使われる$TTLが無い場合は、直前のレコードに明示したTTLが引き継がれる$TTLが無く、最初のレコード（ふつうはSOA）にもTTLが無い場合、BINDはSOAのMINIMUMを既定値として使い、警告を出す
最後のケースでは、読み込み時に「TTLの指定が無いのでSOAのMINIMUMを使う」という趣旨の警告がログに出ます。動作はしますが意図が読み取りにくいため、$TTL を明示するのが一般的です。
BINDでSOAのTTLを省略する手順
作業の前に、ゾーンファイルをコピーしてバックアップを取ります。可能なら検証用のサーバーで同じ操作を試してから本番に反映します。
変更前は、SOAの行にTTLが明示されているとします。
$TTL 3600
@ 86400 IN SOA ns1.example.com. hostmaster.example.com. (
2026101801 ; serial
3600 ; refresh
900 ; retry
1209600 ; expire
3600 ) ; negative cache TTLこの 86400 を削除し、シリアル番号を増やします。
$TTL 3600
@ IN SOA ns1.example.com. hostmaster.example.com. (
2026101802 ; serial
3600 ; refresh
900 ; retry
1209600 ; expire
3600 ) ; negative cache TTLこれでSOAレコードのTTLは $TTL の3600秒になります。注意したいのは、SOAの行で明示していたTTLが、その後ろのTTLを省略したレコードに引き継がれていた可能性があることです。$TTL がある場合は $TTL の値が使われますが、$TTL が無いゾーンでSOAのTTLを消すと、後続のレコードのTTLまで変わることがあります。消す前に、ゾーンの先頭に $TTL があるかを確かめてください。
編集したら、構文を検査してから再読み込みします。
# 構文とSOAの値を検査（警告やエラーが出たら反映しない）
sudo named-checkzone example.com /etc/bind/zones/db.example.com
# 対象ゾーンだけ再読み込み
sudo rndc reload example.comnamed-checkzone が OK と新しいシリアル番号を表示すれば、構文上の問題はありません。セカンダリを運用している場合は、シリアル番号を増やしたことでゾーン転送が行われ、セカンダリのSOAのTTLも変わります。
PowerDNSのようにデータベースでゾーンを管理するDNSサーバーでは、ゾーンファイルの書式ではなく、レコードごとにTTLを持つ形になっています。この場合は pdnsutil edit-zone example.com などでSOAのTTLを目的の値に書き換えます。「省略」という操作は無く、値を決めて入れることになります。
マネージドDNSの場合
Amazon Route 53 や Cloudflare などのマネージドDNSでは、SOAレコードはサービスが自動で作成し、利用者が削除することはできません。TTLやSOAの一部のフィールドを編集できるかどうかは、サービスやプランによって異なります（2026年10月現在）。
- 編集できるサービス: 以前に変えたTTLを既定の値に戻すのが「削除」に相当します。既定値はサービスの資料に載っていることが多いので、作成直後の別のゾーンと見比べるのも手です
- 編集できないサービス: そもそもTTLを変えられないため、利用者側で消す・戻す作業はありません。ネガティブキャッシュの長さが問題になっている場合は、サポートに相談します
レンタルサーバーやドメイン会社の付属DNSでは、SOAが画面に表示されないことも多くあります。その場合も、表示されていないだけでSOAレコードとTTLは存在しています。
変更後の確認
権威サーバーに直接問い合わせると、TTL欄には設定した値そのものが表示されます。
# 権威サーバーが返すSOAのTTLを確認（2列目がTTL）
dig @ns1.example.com example.com SOA +norecurse +noall +answer
# 全権威サーバーのシリアル番号がそろったかを確認
dig example.com +nssearch一方、公開DNSに問い合わせたときのTTL欄は「キャッシュがあと何秒残るか」です。変更前のTTLでキャッシュされていた答えは、その時間が過ぎるまで古いTTLのまま残ります。公開DNSで新しい値になったかを確かめるのは、変更前のTTLの分だけ時間を置いてからにします。
ネガティブキャッシュの長さも、あわせて確かめておくと安心です。存在しない名前を問い合わせ、AUTHORITYセクションに出るSOAのTTLを見ます。
dig @ns1.example.com no-such-name.example.com A +norecurseここで表示されるTTLが、SOAレコードのTTLとMINIMUMのうち短い方になっていれば、意図どおりに動いています。
TTLを決め直すときの目安
TTLを消したい理由が「長すぎて変更が反映されにくい」ことであれば、省略して既定値に任せるよりも、目的に合った値を明示した方が後から読みやすくなります。SOAレコード自体のTTLは、ゾーンの既定TTLと同じ数十分〜1時間程度にしておく例が多く見られます。サブドメインの追加が多い運用では、ネガティブキャッシュが長いと困るため、SOAのTTLとMINIMUMの両方を数分〜1時間程度に抑えておくと扱いやすくなります。
まとめ
- SOAレコードのTTLは「無し」にはできない。できるのは省略して
$TTLを使わせるか、既定の値に戻すこと - SOAにはレコード自体のTTLとMINIMUM（ネガティブキャッシュTTL）があり、ネガティブキャッシュには両方の短い方が使われる
- BINDでは
$TTLがあることを確かめてからSOAの行のTTLを消し、シリアル番号を増やしてnamed-checkzoneとrndc reloadを行う - マネージドDNSではSOAは削除できず、TTLを編集できるかはサービスやプランによる
- 変更後は権威サーバーで設定値を、公開DNSでは古いTTLが切れた後の値を確かめる