DNS ゾーン

概要

DNS ゾーン は、特定の権威ネームサーバーが管理責任を持つ DNS 名前空間の区画です。RFC 1035（1987年）で定義された DNS の基本概念であり、ドメインの階層構造を管理上の単位に分割する仕組みとして機能します。

DNS の名前空間は巨大な木構造ですが、一つのサーバーが全てを管理するわけではありません。名前空間をゾーンという単位に分割し、各ゾーンの管理を個別の権威ネームサーバーに委ねることで、分散管理を実現しています。ゾーンには SOA（Start of Authority）レコードが必ず存在し、そのゾーンの管理情報（プライマリネームサーバー、管理者メールアドレス、シリアル番号など）を保持します。

ゾーンとドメインは似ていますが異なる概念です。ドメインは example.com のような名前空間上の位置を指し、ゾーンはその位置から始まる管理範囲を指します。example.com のゾーンには www.example.com や mail.example.com の A レコードが含まれますが、sub.example.com を別のネームサーバーに委任した場合、sub.example.com 以下はそのゾーンには含まれません。

仕組み

ゾーンファイルの構成、ドメインとゾーンの境界、ゾーン委任の仕組み、プライマリ・セカンダリ間のゾーン転送を解説します。

ゾーンファイルの構成

ゾーンの内容はゾーンファイルとして管理されます。ゾーンファイルは RFC 1035 で規定されたテキスト形式で、そのゾーンに属する全ての DNS レコードを記述します。

$ORIGIN example.com.
$TTL 3600

@   IN  SOA  ns1.example.com. admin.example.com. (
                2024010101  ; SERIAL
                10800       ; REFRESH (3 hours)
                3600        ; RETRY (1 hour)
                604800      ; EXPIRE (7 days)
                300         ; MINIMUM (5 minutes)
            )

    IN  NS   ns1.example.com.
    IN  NS   ns2.example.com.
    IN  A    93.184.216.34
    IN  MX   10 mail.example.com.

www IN  A    93.184.216.34
mail IN A    93.184.216.35

$ORIGIN はゾーンの起点ドメインを指定します。@ は $ORIGIN の値（この例では example.com.）を表す省略記法です。$TTL はレコードごとに TTL を指定しない場合のデフォルト値を設定します。

SOA レコードの各フィールドには次の意味があります。

フィールド	意味
SERIAL	ゾーンデータのバージョン番号。変更するたびに増加させる
REFRESH	セカンダリネームサーバーがプライマリに更新確認する間隔
RETRY	REFRESH の確認に失敗した場合の再試行間隔
EXPIRE	セカンダリがプライマリに到達できない場合にゾーンデータを破棄するまでの期間
MINIMUM	ネガティブキャッシュ（存在しないレコードのキャッシュ）の TTL

ドメインとゾーンの境界

example.com ドメインが一つのゾーンに収まる場合、そのゾーンには example.com 以下の全てのレコードが含まれます。しかし、サブドメインを別のネームサーバーに委任すると、ゾーンの境界が生まれます。

example.com ゾーン
├── example.com (SOA, NS, A, MX)
├── www.example.com (A)
├── mail.example.com (A)
└── api.example.com (NS) ← ここでゾーン委任
      │
      api.example.com ゾーン（別のネームサーバーが管理）
      ├── api.example.com (SOA, NS, A)
      └── v2.api.example.com (A)

この構造では、example.com ゾーンの権威ネームサーバーは www.example.com や mail.example.com のレコードを直接返せますが、api.example.com についてはNS レコード（委任情報）だけを持ちます。api.example.com の実際のレコードは、委任先のネームサーバーが管理する api.example.com ゾーンに存在します。

ゾーン委任

ゾーン委任は、親ゾーンに子ゾーンの NS レコードを設定することで行います。

; example.com ゾーン内の委任設定
api.example.com.  IN  NS  ns1.api-provider.com.
api.example.com.  IN  NS  ns2.api-provider.com.

再帰リゾルバーが v2.api.example.com を解決しようとすると、example.com の権威ネームサーバーから委任応答（referral）を受け取り、ns1.api-provider.com に問い合わせ直します。DNS の階層的な委任構造はこの仕組みの連鎖で成り立っています。ルートゾーン（.）から TLD ゾーン（.com）、そして各ドメインのゾーンへと、全ての名前解決はゾーン委任を辿る過程です。

ゾーン転送

プライマリネームサーバーからセカンダリネームサーバーへゾーンデータを複製する仕組みがゾーン転送です。

方式	内容	RFC
AXFR（Full Zone Transfer）	ゾーン全体を転送する	RFC 5936
IXFR（Incremental Zone Transfer）	前回転送からの差分のみを転送する	RFC 1995

セカンダリは SOA レコードの SERIAL 値を比較し、プライマリの SERIAL が大きければ変更があったと判断してゾーン転送を要求します。REFRESH 間隔ごとにこの確認が行われます。

ゾーン転送はセキュリティ上の配慮が必要です。ゾーンの全レコードが公開されるため、RFC 5936 では TSIG（Transaction Signature）による認証や、アクセス制御リスト（ACL）による接続元制限が推奨されています。

クラウド型 DNS サービス（Cloudflare、AWS Route 53、Google Cloud DNS）では、ゾーン転送は内部的に自動処理されるため、利用者が意識する必要はありません。

確認方法

ゾーンの管理情報は SOA レコードで確認できます。

dig SOA example.com

;; ANSWER SECTION:
example.com.  3600  IN  SOA  ns1.example.com. admin.example.com. (
                              2024010101  ; SERIAL
                              10800       ; REFRESH
                              3600        ; RETRY
                              604800      ; EXPIRE
                              300         ; MINIMUM
                          )

SOA レコードの MNAME フィールド（最初の値、ns1.example.com.）がそのゾーンのプライマリネームサーバーを示し、RNAME（admin.example.com.）が管理者のメールアドレス（@ を . に置換した形式）を示します。

ゾーン内の NS レコードを確認するには次のコマンドを使います。

dig NS example.com

;; ANSWER SECTION:
example.com.  172800  IN  NS  ns1.example.com.
example.com.  172800  IN  NS  ns2.example.com.

サブドメインに委任が設定されているかは、親ゾーンの権威ネームサーバーに直接問い合わせることで確認できます。

dig NS api.example.com @ns1.example.com

応答に NS レコードが含まれ、flags: に aa（Authoritative Answer）が立っていなければ、そのサブドメインは別のゾーンに委任されています。

外部の視点からも確認したい場合は、Labee Dev Toolbox の DNS API を使うと、外部の視点から見た結果を取得できます。

curl "https://labee.dev/api/dns?domain=example.com&type=SOA,NS"

レスポンスの records.SOA にゾーンの管理情報、records.NS に権威ネームサーバーのリストが返ります。

{
  "success": true,
  "data": {
    "domain": "example.com",
    "records": {
      "SOA": [
        {
          "mname": "ns1.example.com",
          "rname": "admin.example.com",
          "serial": 2024010101,
          "refresh": 10800,
          "retry": 3600,
          "expire": 604800,
          "minimum": 300
        }
      ],
      "NS": [
        "ns1.example.com",
        "ns2.example.com"
      ]
    }
  },
  "error": null,
  "meta": { "responseTime": 48 }
}

SOA レスポンスのフィールド名（mname、rname、serial、refresh、retry、expire、minimum）は、DNS API のソースコードで定義されたパース処理に基づいています。

よくある問題

ゾーン管理のトラブルは、SERIAL の更新忘れ、委任設定の不整合、ゾーン転送の認証エラーに集約されます。

ゾーンファイルの SERIAL を更新し忘れてセカンダリに反映されない

プライマリネームサーバーのゾーンファイルを変更しても SERIAL を増加させなかった場合、セカンダリはゾーン転送を要求しません。セカンダリが古いデータを配信し続けるため、一部のユーザーには変更が反映されない状態になります。ゾーンファイルを手動で編集する環境では、レコードの変更と同時に SERIAL の更新を必ず行います。BIND の場合、rndc reload の前に SERIAL が増加していることを確認します。

サブドメインの委任設定と委任先のレコードが不一致

親ゾーンに NS レコードで委任を設定しても、委任先のネームサーバーに SOA レコードやその他のレコードが存在しなければ SERVFAIL が返ります。委任は双方向の設定です。親ゾーン側で NS レコードを追加し、委任先のネームサーバー側でゾーンを作成して SOA レコードと必要なレコードを登録する、両方の手順を完了する必要があります。

ゾーン転送が TSIG 認証エラーで失敗する

TSIG を使ったゾーン転送認証では、プライマリとセカンダリで共有鍵の名前・アルゴリズム・値が一致している必要があります。一方だけを更新すると転送が失敗し、セカンダリのゾーンデータが古くなります。EXPIRE 期間が経過するとセカンダリはゾーンデータを破棄するため、そのセカンダリへの問い合わせは全て失敗します。鍵の更新時はプライマリとセカンダリを同時に変更します。

ゾーンの TTL 設定が DNS 移行を遅延させる

DNS プロバイダーの移行前にゾーンの $TTL やレコードの TTL を短縮しておかないと、移行後も長時間にわたって古いネームサーバーへの問い合わせが続きます。移行の24〜48 時間前に TTL を 300〜600 秒に短縮し、移行完了後に元の値に戻します。NS レコード自体の TTL は TLD ネームサーバー側で管理されるため、レジストラの設定変更にも数時間の反映時間が必要です。