DNS ゾーン

DNSゾーンとは?

DNSゾーンはDNS名前空間の明確な部分で、特定の組織または管理者によって管理されます。ゾーンには1つ以上のドメインのDNSレコードが含まれ、権威nameserverによって提供されます。ドメインがDNS木内の名前であるのに対し、ゾーンはどのnameserverが応答の責任を負うかを定義する管理上の境界です。

ドメイン vs ゾーン

区別を理解することは重要です:

ドメイン

DNS階層内の名前:

example.com（ドメイン）
  └── www.example.com（サブドメイン）
  └── blog.example.com（サブドメイン）
  └── api.example.com（サブドメイン）

ゾーン

レコード上の管理制御:

example.com ゾーンに含まれる:
  - example.com
  - www.example.com
  - blog.example.com
  - api.example.com

管理: ns1.example.com、ns2.example.com

example.com ゾーンに含まれる:
  - example.com
  - www.example.com
  - 委譲: api.example.com → 異なるnameservers

api.example.com ゾーン（個別）に含まれる:
  - api.example.com
  - v1.api.example.com
  - v2.api.example.com

管理: ns1.apihost.com、ns2.apihost.com

ゾーン構成要素

ゾーンファイル

ゾーン内のすべてのDNSレコードを含むテキストファイル:

; example.com ゾーンファイル
$TTL 3600
@   IN  SOA ns1.example.com. admin.example.com. (
            2024010101  ; シリアル
            7200        ; リフレッシュ
            3600        ; リトライ
            1209600     ; 有効期限
            3600        ; 最小TTL
        )

; nameserverレコード
@       IN  NS      ns1.example.com.
@       IN  NS      ns2.example.com.

; Aレコード
@       IN  A       203.0.113.50
www     IN  A       203.0.113.50
blog    IN  A       203.0.113.51

; MXレコード
@       IN  MX  10  mail.example.com.
mail    IN  A       203.0.113.52

; CNAMEレコード
ftp     IN  CNAME   www.example.com.

; TXTレコード
@       IN  TXT     "v=spf1 include:_spf.google.com ~all"

SOAレコード（Authority Start）

各ゾーンは正確に1つのSOAレコードを持つ必要があります:

example.com.  IN  SOA  ns1.example.com. admin.example.com. (
                       2024010101  ; シリアル
                       7200        ; リフレッシュ
                       3600        ; リトライ
                       1209600     ; 有効期限
                       3600        ; 最小TTL
                   )

NSレコード（nameservers）

ゾーションの権威サーバーを指定:

example.com.  IN  NS  ns1.example.com.
example.com.  IN  NS  ns2.example.com.

世界中に、このゾーン内のレコードに関するクエリをどこに送信するかを伝えます。

ゾーンタイプ

プライマリゾーン（マスター）

ゾーンレコードが編集される権威ソース:

ns1.example.com（プライマリ）
  → ゾーンファイルがここで編集される
  → 変更は直接行われる
  → セカンダリに更新を通知

セカンダリゾーン（スレーブ）

プライマリから複製される読み取り専用コピー:

ns2.example.com（セカンダリ）
  → プライマリからゾーンデータを取得
  → 直接編集することはできない
  → SOAリフレッシュ間隔に基づいて自動同期

1. セカンダリがSOAシリアル番号をチェック
2. プライマリシリアルが高い場合 → 完全なゾーン転送をリクエスト
3. プライマリが全ゾーンを送信
4. セカンダリがコピーを更新

1. セカンダリが最後のシリアル以降の変更のみをリクエスト
2. プライマリが差分を送信
3. 大規模ゾーンで小さな変更の場合、より効率的

フォワードゾーン

ドメイン名をIPアドレスにマップ（最も一般的）:

example.com → 203.0.113.50
www.example.com → 203.0.113.50

リバースゾーン

IPアドレスをドメイン名にマップ（PTRレコード）:

50.113.0.203.in-addr.arpa → example.com

用途:

• メールサーバーの検証
• ログとセキュリティ
• トラブルシューティング

ゾーン委譲

委譲はサブドメイン用に個別のゾーンを作成します:

親ゾーン（example.com）

; example.com ゾーン
@           IN  A       203.0.113.50
www         IN  A       203.0.113.50

; api.example.comを異なるnameserversに委譲
api         IN  NS      ns1.apihost.com.
api         IN  NS      ns2.apihost.com.

; グルーレコード（必要な場合）
ns1.api     IN  A       198.51.100.1
ns2.api     IN  A       198.51.100.2

委譲されたゾーン（api.example.com）

別のnameservers上の完全に個別のゾーンファイル:

; api.example.com ゾーン（ns1.apihost.comで）
@           IN  A       198.51.100.10
v1          IN  A       198.51.100.11
v2          IN  A       198.51.100.12

• 組織的: 異なるチームが異なるゾーンを管理
• 技術的: 異なるDNSプロバイダーを使用（例: API用AWS、Webサイト用Cloudflare）
• パフォーマンス: DNS負荷を分散
• セキュリティ: 機密サービスを隔離

2024010101  ; 2024年1月1日、バージョン01
2024010102  ; 2024年1月1日、バージョン02
2024010201  ; 2024年1月2日、バージョン01

zone "example.com" {
    type master;
    file "/var/named/example.com.zone";
    allow-transfer { 203.0.113.52; 203.0.113.53; };  // セカンダリIPのみ
    notify yes;
};

key "transfer-key" {
    algorithm hmac-sha256;
    secret "base64-encoded-key";
};

allow-transfer { key transfer-key; };

dig example.com SOA

; 応答セクション:
example.com.  3600  IN  SOA ns1.example.com. admin.example.com. (
                             2024010101 7200 3600 1209600 3600 )

dig example.com NS

; 応答セクション:
example.com.  86400  IN  NS  ns1.example.com.
example.com.  86400  IN  NS  ns2.example.com.

dig @ns1.example.com example.com AXFR

# 許可されている場合は全ゾーンを返す
# 拒否された場合は転送失敗を返す

example.com ゾーン:
  @     A      203.0.113.50
  www   A      203.0.113.50
  @     MX 10  mail.example.com
  mail  A      203.0.113.51
  @     TXT    "v=spf1 mx -all"

example.com ゾーン:
  @       A       203.0.113.50
  www     A       203.0.113.50
  blog    CNAME   hosting.wordpress.com.
  shop    CNAME   shops.myshopify.com.
  cdn     CNAME   d111111abcdef8.cloudfront.net.
  @       MX 10   aspmx.l.google.com.

example.com ゾーン:
  @       A   203.0.113.50
  www     A   203.0.113.50

  ; APIをAWS Route 53に委譲
  api     NS  ns-123.awsdns-01.com.
  api     NS  ns-456.awsdns-02.net.

  ; CDNをCloudflareに委譲
  cdn     NS  ns1.cloudflare.com.
  cdn     NS  ns2.cloudflare.com.

1. 常にシリアルをインクリメント: 各変更後、またはセカンダリが更新されない

2. 日付ベースのシリアルを使用: YYYYMMDDnn形式で明確

3. ゾーン転送を制限: 許可されたセカンダリのみ

4. 複数のnameserverを使用: 少なくとも2つ、できれば異なるネットワーク上の3つ以上

5. 適切なTTLを設定: キャッシングの利点と更新速度のバランス

6. 適用前にテスト: ゾーンファイル構文をロード前に検証

7. ゾーン転送を監視: セカンダリが同期していることを確認

8. 委譲を文書化: どのゾーンが委譲されており、どこにあるかを記録

9. ゾーンファイルをバックアップ: データ損失を防ぐ

10. バージョン管理を使用: ゾーンファイルの変更を時系列で追跡

example.com.  IN  A       203.0.113.50
example.com.  IN  RRSIG   A 8 2 3600 (
                                署名データ )

# Aレコードを動的に更新
nsupdate -k Kupdate.key <<EOF
server ns1.example.com
update delete www.example.com A
update add www.example.com 300 A 203.0.113.51
send
EOF

内部クライアント: example.com → 10.0.0.50（内部）
外部クライアント: example.com → 203.0.113.50（パブリック）

# プライマリが転送を許可するかをチェック
dig @ns1.example.com example.com AXFR

# セカンダリログでエラーをチェック
tail -f /var/log/named.log

# 委譲を確認
dig example.com NS
dig api.example.com NS

# 委譲されたサブドメインに異なるnameserverが表示されるはず

• 親ゾーンでNSレコードを確認
• グルーレコードをチェック（nameserverが自分のドメイン内にある場合）
• 子ゾーンが設定されていることを確認

DNSゾーンは分散DNS管理の基盤です。ゾーン構造、委譲、管理を理解することで、あらゆるサイズの組織向けにDNSを効果的に設計できます。