DNSDNSレコードインフラ

DNS SOA レコードとは｜7 フィールド入門解説

2026年5月23日ドメイン番人約 5 分で読めます

この記事でわかること

SOA レコードの役割と「ゾーンの起点」としての位置付け
7 つのフィールド（MNAME / RNAME / Serial / Refresh / Retry / Expire / Minimum TTL）の意味
dig コマンドで SOA を確認する手順
Cloudflare / Route 53 などマネージド DNS 利用時に意識すべき点

SOA レコードとは「ゾーンの戸籍」

SOA は Start of Authority（権威の開始）の略で、DNS ゾーンの先頭に必ず 1 件だけ存在するレコードです。ドメインを取得して DNS サーバーに登録した瞬間、その裏では SOA レコードが自動で作られています。

「このゾーンのプライマリ DNS は誰か」「管理者は誰か」「ゾーンデータがいつ更新されたか」を宣言する戸籍のような役割を持ち、セカンダリ DNS との同期や、上位リゾルバのネガティブキャッシュの挙動を制御します。

SOA レコードがゾーンで担う役割

普段は意識しない裏方ですが、DNS のトラブルシュート（伝播遅延 / セカンダリ同期失敗 / NXDOMAIN キャッシュ）の起点として読めるようになると、原因切り分けが一気に楽になります。

なお、SOA と密接に関わる Zone Transfer（AXFR/IXFR） の挙動については AXFR（DNS ゾーン転送）とはに詳しくまとめているので、本記事を読み終わったら合わせてどうぞ。

SOA レコードの 7 フィールド

dig SOA example.com を実行すると、SOA レコードは次のような 1 行で返ってきます。

example.com. 3600 IN SOA ns1.example.com. hostmaster.example.com. 2026052301 7200 1800 1209600 300

ホスト名のあとに 7 つの値が並んでいる構造です。ひとつずつ役割を確認しましょう。

SOA の 7 フィールド構造

1. MNAME（プライマリ DNS サーバー名）

そのゾーンの「正本」となるプライマリ DNS サーバーのホスト名。セカンダリ DNS はここを基準にゾーン転送を行います。

マネージド DNS（Cloudflare / Route 53 / Google Cloud DNS）を利用している場合、MNAME は事業者側のホスト名（例: ns.cloudflare.com）が自動設定され、利用者が変更することはほぼありません。

2. RNAME（管理者メールアドレス）

ゾーン管理者のメールアドレスを「@ を . に置き換えた形式」で書く独特の表記。hostmaster.example.com. は実際には hostmaster@example.com を意味します。

歴史的経緯で hostmaster という名前が使われることが多く、運用上は配信用エイリアスを 1 つ用意して問い合わせが届くようにしておくと安心です。

3. Serial（シリアル番号）

ゾーンデータのバージョン番号。セカンダリ DNS はこの数字を見て「自分が持っているコピーより新しいか」を判定します。

慣例として YYYYMMDDnn 形式（例: 2026052301）を使うことが多いものの、整数なら何でも構いません。重要なのは「ゾーンを編集するたびに必ず増やす」というルールです。マネージド DNS では編集時に自動でインクリメントされます。

4. Refresh（秒）

セカンダリ DNS がプライマリに対し「Serial が変わっていませんか？」と確認する間隔。一般的に 3600 秒（1 時間）〜 86400 秒（1 日）が設定されます。

5. Retry（秒）

Refresh で確認に失敗したときの再試行間隔。Refresh より短く設定するのが定石です（典型値: 1800 秒）。

6. Expire（秒）

プライマリと長時間連絡が取れなかった場合、セカンダリが「自分の持つデータを破棄するまでの猶予」。典型値は 1209600 秒（14 日）。この時間を過ぎるとセカンダリは応答停止するため、長すぎても短すぎても運用リスクになります。

7. Minimum TTL（秒、ネガティブキャッシュ TTL）

RFC 2308 で 「存在しないレコード」をキャッシュする時間 に再定義されました。NXDOMAIN（存在しないドメイン）のキャッシュ寿命を決める値です。

ここを大きくすると DNS サーバーの負荷は減りますが、新規レコード追加時に「まだ反映されない」現象が起きやすくなります。典型値は 300〜3600 秒。

dig で実際に確認してみる

ターミナルから 1 行で確認できます。

dig SOA example.com +short

出力例:

ns1.example.com. hostmaster.example.com. 2026052301 7200 1800 1209600 300

+short を外せば、TTL や応答セクションも含む完全な形が見られます。

dig SOA example.com

AUTHORITY SECTION に SOA が並んで返ってきたら、それは「該当ホストが存在しないが、ゾーン自体は存在する」というネガティブ応答であるサインです。Web 担当者が「DNS が浸透していない」と感じるケースの多くは、この ネガティブキャッシュ（Minimum TTL） に起因します。

メール認証レコード（SPF / DKIM / DMARC）の追加直後に確認が通らない場合も、同じ理屈で「以前の NXDOMAIN をリゾルバが覚えている」ことが原因の場合があります。検証手順は SPF/DKIM/DMARC の確認方法にまとめています。

マネージド DNS 利用時に意識すべきこと

Cloudflare / Route 53 / Google Cloud DNS など、いわゆるマネージド DNS を使っている場合、SOA の値は基本的に「触らなくて良い」設計になっています。

MNAME / RNAME: 事業者の標準値が自動設定。利用者が編集できないことも多い
Serial: レコード編集時に自動でインクリメント。手動操作不要
Refresh / Retry / Expire / Minimum TTL: 多くの事業者でデフォルト値が固定。UI から変更できる場合でも、デフォルトを変える前に運用要件を整理しましょう

逆に オンプレで BIND / NSD などを運用している場合は、Serial の更新忘れが「セカンダリに変更が反映されない」典型的な事故原因 になります。ゾーンファイルを編集したら必ず Serial を増やす、デプロイ自動化で必ずインクリメントするスクリプトを通す、といった運用ルールが重要です。

DNS レコード全体の種類と役割を整理したい場合は DNS レコードの種類と役割を一覧で理解するも合わせてどうぞ。

まずは現状を把握しましょう

ドメイン番人の無料ドメイン診断で、SPF / DKIM / DMARC / DNS の基本構成をまとめてチェックできます。SOA の値そのものは診断対象外ですが、ゾーンが意図通りに公開できているかを 30 秒で確認できます。

DNS 棚卸しや、マネージド DNS への移行設計を相談したい場合はお問い合わせからどうぞ。Web 担当者の人手では追いきれない大量サブドメインの整理も、棚卸しサービスで対応しています。