AXFR とは｜DNS ゾーン転送と SOA レコードの関係

この記事でわかること

• SOA レコードの 7 つのフィールドが何を意味し、どう運用に効くか
• AXFR / IXFR の違いと、セカンダリ DNS への複製プロセス
• AXFR を不特定多数に開放する設定ミスがなぜ深刻なセキュリティ問題なのか
• マネージド DNS（Cloudflare / Route53 等）を使う場合に意識すべきこと

SOA レコードとは

SOA（Start of Authority、RFC 1035 §3.3.13）は、各 DNS ゾーンの先頭に必ず 1 件だけ存在するレコードで、そのゾーンの権威情報の起点となります。dig で取得すると以下のように見えます。

example.com. 3600 IN SOA ns1.example.com. hostmaster.example.com. (
  2026051201  ; Serial
  3600        ; Refresh
  600         ; Retry
  1209600     ; Expire
  300 )       ; Minimum TTL

各フィールドの意味:

• Serial: ゾーンの版番号。慣習的に YYYYMMDDNN 形式。セカンダリは Serial が増えていれば「差分あり」と判断
• Refresh: セカンダリがプライマリへの確認間隔（秒）
• Retry: 確認に失敗した場合の再試行間隔
• Expire: プライマリ到達不能が続いた場合、セカンダリがゾーンを廃棄するまでの時間
• Minimum TTL: ネガティブキャッシュ（存在しないレコードの否定応答）の TTL（RFC 2308）

ゾーン転送（AXFR / IXFR）の仕組み

プライマリ DNS が持つゾーンデータを、セカンダリ DNS に複製する仕組みがゾーン転送です。

• AXFR（RFC 5936）: ゾーン全体を転送（フル転送）
• IXFR（RFC 1995）: 差分のみ転送（増分転送）。Serial 番号の差分から「追加 / 削除されたレコードのみ」を送る

通常はセカンダリが Refresh の間隔でプライマリへ SOA を問い合わせ、Serial が増えていれば IXFR、対応していなければ AXFR でフェッチします。

AXFR を外部に開放してはいけない

「便利なバックアップ手段だから」と AXFR をインターネットに開放してはいけません。ゾーン全体（全サブドメイン、内部システム名、メールサーバ、開発用ホスト等）が攻撃者に丸ごと開示されるためです。

確認コマンド:

dig @ns1.example.com example.com AXFR

これが転送に成功してしまうなら設定不備です。マネージド DNS では通常 IP allowlist or TSIG 鍵で制限されており、UI から「Zone Transfer 許可 IP」を確認できます。

マネージド DNS 利用時のポイント

Cloudflare DNS / Route53 / Google Cloud DNS 等を使う場合、SOA は自動管理され、ゾーン転送も外部開放されない設計です。意識すべきはむしろ:

• Serial の自動更新: 手動で SOA を弄れない代わりに、レコード変更ごとに Serial が自動加算
• NS レコードの一致: SOA のプライマリ NS と、実際に登録されている NS 群が一致しているか定期チェック
• 複数プロバイダ運用時のゾーンファイル管理: AXFR で吸い出して別プロバイダに移すケースは、移行作業時の限定的シナリオ。常時開放はしない

詳細な DNS 基礎はDNS とは（基礎編） を参照してください。

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

DNS の設定状況やゾーン情報の漏洩は無料のドメイン診断で把握できます。設定見直しが必要な場合はお問い合わせからご相談ください。SSL や DNS の単発チェックは無料ツール一覧で提供しています。

関連記事: DNS とは（基礎編） / DNS レコードの種類 / DNS CNAME Flattening 完全ガイド