DNS SOA TTL の推奨値｜実務でハマらない設定
目次
この記事でわかること
- SOA レコードの 5 つの数値（Serial / Refresh / Retry / Expire / Minimum TTL）の推奨値
- RFC 1912 が示すベースラインと、現代運用での実務値
- 短すぎる / 長すぎる設定で起きる典型的なトラブル 3 パターン
- マネージド DNS とオンプレ運用での違い
SOA レコードそのものの基礎は DNS SOA レコードとは｜7 フィールド入門解説 に詳しくまとまっています。本記事は「では具体的にどの値にすべきか」に絞った実務記事です。
SOA TTL の推奨値（早見表）
実務でそのまま使える値を最初に置いておきます。
| フィールド | 推奨値 | 単位 | 根拠 |
|---|---|---|---|
| Serial | YYYYMMDDnn 形式 | 整数 | 慣例 / 自動更新推奨 |
| Refresh | 3600〜86400 | 秒（1 時間〜1 日） | RFC 1912 |
| Retry | 900〜3600 | 秒（15 分〜1 時間） | RFC 1912 |
| Expire | 1209600〜2419200 | 秒（14 日〜28 日） | RFC 1912 |
| Minimum TTL（負キャッシュ） | 300〜3600 | 秒（5 分〜1 時間） | RFC 2308 |
迷ったらこの中央値（Refresh 7200 / Retry 1800 / Expire 1209600 / Minimum 300）から始めれば、ほぼ事故りません。マネージド DNS のデフォルトもこの近辺に設定されています。
なぜ「短すぎ」も「長すぎ」もダメなのか
SOA の TTL 群は プライマリとセカンダリの同期サイクル と リゾルバのキャッシュ寿命 という 2 軸を支配します。1 つの値だけ極端に振ると、全体のバランスが崩れて運用事故につながります。
ゾーン転送（AXFR / IXFR）の挙動と SOA の関係は AXFR（DNS ゾーン転送）とは に詳述しています。
Refresh / Retry / Expire のタイムライン
通常時はセカンダリが Refresh 間隔で Serial を確認し、差分があればゾーン転送で同期します。プライマリが落ちると、セカンダリは Retry 間隔で再試行を続け、最終的に Expire を超えると保持データを破棄して応答停止します。
この 3 つの値は 「Retry < Refresh ≪ Expire」 の関係性を守るのが大原則です。
ハマりやすい設定 3 パターン
パターン 1: Retry が短すぎてセカンダリ過負荷
Retry を 60 秒（1 分）など極端に短く設定すると、プライマリ障害時にセカンダリが毎分接続を試み続け、復旧後のプライマリに対する瞬間負荷が跳ね上がります。中小企業の規模では問題が顕在化しにくいものの、監視ログが Retry 失敗で埋まり、本当の障害シグナルを見落とす という副作用が起きます。
推奨は 900〜3600 秒。Retry は「数十分」スケールで考えるのが定石です。
パターン 2: Expire が短すぎて障害時にゾーン消失
Expire を 86400 秒（1 日）など短く設定すると、プライマリが 24 時間止まっただけでセカンダリも応答停止し、ゾーン全体が SERVFAIL になります。
DNS の最終防衛線である「プライマリが死んでもセカンダリが応答し続ける」性質を活かすには、Expire は最低でも 14 日（1209600 秒）、できれば 28 日（2419200 秒）を確保しましょう。「Expire は短い方が安全」というのは誤解で、長い方が事故に強い のが SOA の特徴です。
パターン 3: Minimum TTL が長すぎて新規レコード追加が反映されない
Minimum TTL は RFC 2308 で ネガティブキャッシュ（NXDOMAIN）の TTL に再定義されています。ここを 86400 秒（1 日）に設定すると、新しく追加した DKIM レコードが「以前は存在しなかった」というリゾルバ側のキャッシュに最大 1 日阻まれて見つかりません。
SPF / DKIM / DMARC のような 新規追加が頻発するレコード を運用するゾーンでは、Minimum TTL は 300〜3600 秒に抑えるのが鉄則です。
マネージド DNS でのデフォルト値
主要マネージド DNS のデフォルト SOA 値は、おおむね RFC 1912 推奨レンジに収まっています。
- Cloudflare: Refresh 10000 / Retry 2400 / Expire 604800 / Minimum 1800
- Route 53: Refresh 7200 / Retry 900 / Expire 1209600 / Minimum 86400
- Google Cloud DNS: Refresh 21600 / Retry 3600 / Expire 1209600 / Minimum 300
Route 53 の Minimum TTL 86400 は他社より長めです。SPF / DKIM / DMARC を頻繁にいじるなら、SOA の Minimum TTL を 300〜3600 秒に下げる調整を検討しましょう（Route 53 では SOA レコードを直接編集可能）。
なお、マネージド DNS では Serial の自動インクリメント が標準動作なので、利用者が Serial を意識する場面はほぼありません。逆にオンプレで BIND / NSD を運用している場合は、Serial 更新忘れが「セカンダリにデータが伝わらない」事故の典型原因になります。
レコード単体の TTL との関係
SOA の Minimum TTL は ネガティブキャッシュ専用 の値で、A / MX / TXT といった各レコードの正のキャッシュ TTL とは別物です。
- 各レコードの TTL → そのレコード行に書かれた値（例:
A 300 IN 192.0.2.1なら 300 秒） - ネガティブキャッシュ TTL → SOA の Minimum TTL（NXDOMAIN や NODATA 応答のキャッシュ寿命）
レコード移行（IP 変更、メールサーバー移行）の直前に 各レコードの TTL を 60〜300 秒に下げて準備し、切替後に元に戻す のが定番の安全策です。DNS レコード全体の TTL 設計は DNS レコードの種類と役割 で各レコード別の典型値を整理しています。
SOA を見直すべきタイミング
普段触らない SOA ですが、次のタイミングで一度見直しましょう。
- マネージド DNS に乗り換えた直後（移行ツールが古い SOA を引き継いでいることがある）
- メール認証（SPF / DKIM / DMARC）の運用を本格化する前
- プライマリ DNS の SLA を変更したとき
- DNSSEC を有効化したとき
特にメール認証導入直前は Minimum TTL を確認しておくと、レコード追加直後の「届かない」「dig しても出てこない」というハマりを防げます。
まとめ
- SOA の TTL 群は「Retry < Refresh ≪ Expire」を守るのが大原則
- 迷ったら Refresh 7200 / Retry 1800 / Expire 1209600 / Minimum 300 の中央値で始める
- Expire は短くしない（長い方が事故に強い）
- Minimum TTL は 300〜3600 秒に抑える（メール認証導入時の必須事項）
- マネージド DNS は概ね妥当なデフォルト。Route 53 だけ Minimum TTL が長め
まずは現状を把握しましょう
ドメイン番人の 無料診断 で、SPF / DKIM / DMARC / DNS の基本構成をまとめてチェックできます。SOA 値そのものは診断対象外ですが、レコード追加が正しく公開できているかは 30 秒で確認できます。SOA や TTL の設計でお困りの場合は お問い合わせ からどうぞ。
関連記事: DNS SOA レコードとは｜7 フィールド入門解説 / AXFR（DNS ゾーン転送）とは / DNS レコードの種類と役割