DNS SOAレコードとは？仕組みと設定方法を解説

DNS
著者:

ドメインのDNSレコードをdigやオンラインツールで調べたことがあれば、SOAレコードを目にしたことがあるでしょう。それが何のためにあるのかはっきりわからなかったかもしれません。しかしこれはDNSゾーンの中で最も重要なレコードのひとつです。そのゾーンの権威が誰にあるか、セカンダリDNSサーバーがどのように同期すべきか、プライマリがダウンした場合にデータがどれくらい有効であり続けるかを定義します。

SOAレコードの内容

SOAはStart of Authority（権威の開始）の略です。すべてのDNSゾーンは必ず1つのSOAレコードを含まなければなりません。常にゾーンの頂点に位置し、7つの個別フィールドを含んでいます。典型的なSOAレコードはこのようになります。

example.com.  3600  IN  SOA  ns1.example.com. admin.example.com. (
                          2025052901  ; Serial
                          7200        ; Refresh
                          3600        ; Retry
                          1209600     ; Expire
                          86400 )     ; Minimum TTL

各フィールドを見ていきましょう。

  • MNAME (ns1.example.com.)：ゾーンのプライマリ権威DNSサーバー。セカンダリサーバーが更新を取得するために接続するサーバーです
  • RNAME (admin.example.com.)：ゾーン管理者のメールアドレス。ただし@の代わりにドットを使います。ここでは[email protected]に相当します。ローカルパートにドットが含まれる場合はバックスラッシュでエスケープが必要です（名前\.姓.example.com.）
  • Serial (2025052901)：ゾーンのバージョン番号。変更のたびにこの番号を増やす必要があり、さもないとセカンダリが更新を検出しません。一般的な形式はYYYYMMDDNN（日付＋日次カウンター）です
  • Refresh (7200)：セカンダリサーバーが確認を行う間隔（秒）。ここでは2時間ごと
  • Retry (3600)：Refreshチェックが失敗した場合の再試行までの待機時間。ここでは1時間
  • Expire (1209600)：セカンダリがプライマリに接続できなくなった場合、ゾーンの応答を停止するまでの時間。ここでは14日。この期間を過ぎるとセカンダリはデータを期限切れとみなし、ゾーンのサービスを完全に停止します
  • Minimum TTL (86400)：RFC 2308以降、このフィールドはネガティブレスポンス（NXDOMAIN）のキャッシュ期間を定義します。ここでは24時間。存在しないサブドメインを問い合わせると、リゾルバーは「存在しない」という応答を24時間キャッシュします

シリアル番号がなぜ重要か

Serialは実務上おそらく最もトラブルを引き起こすフィールドです。セカンダリサーバーがRefreshサイクル中にプライマリに接続すると、自分のローカルシリアル番号とプライマリのものを比較します。プライマリの方が高ければ、セカンダリはゾーン転送（AXFRまたはIXFR）を開始して自身を更新します。変わっていなければ何もしません。

典型的なミス：プライマリでDNSレコードを変更したのにserialを増やさないこと。結果としてプライマリは正しいバージョンを持っていますが、セカンダリは何時間も何日も古いバージョンを返し続けます。ユーザーは問い合わせるサーバーによって異なる応答を受け取り、SOAを確認することを思いつかなければ問題の診断は困難です。

YYYYMMDDNN形式は慣例であり必須ではありません。Serialは32ビット整数なので、0から4,294,967,295までの任意の値が機能します。しかし日付形式は推奨されます。ミスが可視化されるためです。serial 2025052901は明らかに2025年5月29日の最初の変更です。

Refresh、Retry、Expireの連携

この3つの値はDNSゾーンの耐障害性システムを形成します。Refreshは通常の同期リズムを設定します。Retryは失敗時に作動します。Expireは最後の安全策です。この期間プライマリと連絡が取れないと、セカンダリは古い可能性のあるデータを提供するよりも、まったく応答しないことを選びます。

標準的なドメインにはRFC 1912が推奨する値があります。

  • Refresh：3,600〜86,400秒（1時間〜24時間）
  • Retry：600〜3,600秒（10分〜1時間）
  • Expire：1,209,600〜2,419,200秒（2〜4週間）
  • Minimum TTL：3,600〜86,400秒（1時間〜24時間）

ゾーンが頻繁に変更される場合（CDNや動的ロードバランシングのインフラなど）、Refreshを300または600秒に下げてください。安定しているなら86,400で十分であり、プライマリサーバーの負荷も軽減されます。

ドメインのSOAレコードを確認する方法

LinuxとmacOSではdigコマンドが最も手軽です。

dig SOA example.com

Windowsではnslookupを使います。

nslookup -type=SOA example.com

応答にはSOAの7つのフィールドすべてが表示されます。特にserialに注目してください。古く見えたり固定されているようなら、DNS変更が正しく伝播しない原因であることが多いです。

よくあるSOAのミス

実務で定期的に遭遇するいくつかの問題です。

  • RNAMEがドットではなく@を使っており、構文が壊れている。[email protected]はSOAではadmin.example.com.と書かなければなりません
  • バックアップ復元後にserialが誤って減少する。セカンダリはプライマリのserialが自分のローカル値を再び上回るまで同期を拒否します
  • Expireが短すぎる（数時間）。週末にプライマリがダウンすると、誰かが対応できる前にセカンダリが応答を停止します
  • Minimum TTLが0に設定されている。つまりリゾルバーがネガティブレスポンスをキャッシュしません。存在しないサブドメインへのクエリのたびにフルラウンドトリップが発生し、スキャンや攻撃時にDNSサーバーが過負荷になる可能性があります
SOAレコードはドメイン設定時に最初に編集するレコードであることは稀ですが、「DNSが伝播しない」理由を説明するのはこのレコードであることが多いです。複雑な原因を探す前に、serialが正しく増えているか、RefreshとExpireの値が用途に合っているかを確認してください。