DNSのゾーン転送について

DNSのゾーン転送とは、権威DNSサーバー同士でDNSゾーンの情報を同期する仕組みです。

主に、プライマリDNSサーバーが管理しているゾーンデータを、セカンダリDNSサーバーへ複製するために使われます。

DNSはインターネットの基盤なので、1台のサーバーだけで運用すると障害時に名前解決へ影響が出る可能性があります。

そのため、同じゾーン情報を複数の権威DNSサーバーで共有し、可用性や冗長性を高めるためにゾーン転送が使われます。

ゾーンとは何か

DNSでは、あるドメインに関する管理単位をゾーンと呼びます。

たとえば example.com のゾーンには、次のような情報が含まれます。

• A レコード
• AAAA レコード
• MX レコード
• CNAME レコード
• TXT レコード
• NS レコード
• SOA レコード

ゾーン転送は、こうしたレコード群を権威DNSサーバー間で同期する仕組みです。

ゾーン転送の目的

ゾーン転送の主な目的は、DNS運用の安定性を高めることです。

可用性の向上

プライマリDNSサーバーに障害が発生しても、セカンダリDNSサーバーが応答できます。

冗長化

異なるネットワークや拠点に複数の権威DNSサーバーを配置することで、単一障害点を減らせます。

負荷分散

問い合わせを複数の権威DNSサーバーへ分散できます。

運用の一元化

ゾーン更新は主にプライマリ側で行い、その内容をセカンダリへ反映する形で管理できます。

基本構成

一般的な構成は次の通りです。

• プライマリDNSサーバー
  • ゾーンデータの元となる内容を管理するサーバー
• セカンダリDNSサーバー
  • プライマリからゾーン情報を受け取り、複製を保持するサーバー

通常、セカンダリが持つゾーン情報はプライマリから転送された複製であり、直接編集する運用は一般的ではありません。

ゾーン転送の種類

ゾーン転送には主に2種類あります。

AXFR（Full Zone Transfer）

ゾーン全体をまとめて転送する方式です。

初回同期や、差分転送が使えない場合などに利用されます。

特徴

• ゾーン全体を転送する
• 実装や動作がわかりやすい
• ゾーンが大きいと通信量が増えやすい

IXFR（Incremental Zone Transfer）

変更された差分だけを転送する方式です。

更新頻度が高いゾーンや、通信量を抑えたい場合に有効です。

特徴

• 変更分だけ転送する
• 通信効率がよい
• 更新が多い環境に向く
• 差分管理の前提が必要になる

SOAレコードとシリアル番号

ゾーン転送を理解するうえで重要なのが、SOA（Start of Authority）レコードです。

SOAには、そのゾーンに関する基本情報が入っています。

特に重要なのがシリアル番号です。

セカンダリDNSサーバーは、プライマリのSOAレコードにあるシリアル番号と、自分が保持しているシリアル番号を比較し、
プライマリのほうが新しければゾーン更新が必要だと判断します。

SOAレコードに含まれる主な項目

SOAには一般に次のような項目があります。

• Primary Master
  そのゾーンの基準となる権威サーバー
• Responsible Email
  管理者連絡先
• Serial
  ゾーン更新番号
• Refresh
  セカンダリが更新確認を行う間隔
• Retry
  更新確認や転送に失敗したときの再試行間隔
• Expire
  長期間同期できない場合に、そのゾーンデータを無効とみなすまでの期間
• Minimum
  現在の実務上は、主にネガティブ応答に関するTTLの文脈で扱われることが多い値

シリアル番号の運用でよくある問題

ゾーン転送に関する典型的なトラブルのひとつが、ゾーン内容を変更したのにSOAのシリアル番号を更新していないケースです。

たとえば、

• www.example.com のIPアドレスを変更した
• しかしシリアル番号を上げていない
• プライマリでは内容が変わっていても、セカンダリは更新の必要がないと判断する

という状態になると、サーバーごとに異なる応答が返ることがあります。

ゾーン転送はどのように始まるのか

ゾーン転送は、単にセカンダリが定期的にSOAを確認して始まるだけではありません。

実運用では、プライマリからの通知によって転送が促されることも多いです。

大まかな流れは次のとおりです。

1. プライマリのゾーン内容が更新される
2. セカンダリがSOAを確認する、またはプライマリから通知を受ける
3. セカンダリがシリアル番号を比較する
4. 更新が必要ならAXFRまたはIXFRを要求する
5. プライマリが転送を許可する条件を確認する
6. ゾーンデータが転送される
7. セカンダリが新しい内容を反映する

NOTIFYの役割

実際のDNS運用では、NOTIFY が重要です。

これは、プライマリDNSサーバーが
「このゾーンが更新された可能性があるので確認してほしい」
とセカンダリへ知らせる仕組みです。

NOTIFY自体がゾーンデータそのものを送るわけではありません。

通知を受けたセカンダリはSOAを確認し、必要であればAXFRやIXFRでゾーン転送を行います。

つまり、より正確には、

• SOAの比較が更新判断の基準
• NOTIFYが更新検知を早める仕組み

と理解するとよいです。

ゾーン転送とポート番号

ゾーン転送は通常、TCP 53番ポートを使います。

一般的なDNS問い合わせではUDPがよく使われますが、DNSは通常問い合わせでも条件によってTCPを使うことがあります。

そのため、

• 一般的なDNS問い合わせではUDPが多い
• ゾーン転送は通常TCPを使う

と理解しておくと正確です。

ゾーン転送のセキュリティリスク

ゾーン転送は便利な仕組みですが、設定を誤ると大きな情報漏えいにつながります。

もし誰にでもゾーン転送を許可してしまうと、第三者がそのゾーン内のレコード一覧を取得できる可能性があります。

たとえば次のような情報が見えることがあります。

• サブドメイン一覧
• メールサーバー情報
• 管理系サーバー名
• 開発環境や検証環境の名前
• VPNやAPI関連ホストの存在を示す手がかり

たとえば、次のようなホスト名が外部から見えると、攻撃者にとって偵察材料になります。

• admin.example.com
• dev.example.com
• stg.example.com
• mail.example.com
• vpn.example.com

このため、ゾーン転送は必要な相手にだけ許可するのが原則です。

安全な運用の基本

ゾーン転送を安全に使うためには、少なくとも次の点が重要です。

転送先を限定する

許可したセカンダリDNSサーバー以外にはゾーン転送を認めないようにします。

TCP 53番の通信制御を確認する

UDPだけでなく、TCPの53番がどこまで開いているかも確認が必要です。

TSIGを使う

転送要求の正当性確認や、メッセージの完全性確認に役立ちます。

不要な情報を外部ゾーンへ載せない

外部公開ゾーンには、不要な内部向け情報を載せないようにします。

定期的に設定を見直す

許可先IP、ACL、TSIG設定、ゾーン構成などを継続的に確認します。

TSIGとは何か

TSIG（Transaction SIGnature）は、DNSメッセージに署名を付けて、通信相手が正しい相手かどうか、また内容が改ざんされていないかを確認する仕組みです。

ゾーン転送では特に重要な保護手段です。

ただし、TSIGは主に

• 認証
• 完全性確認

のための仕組みであり、通信内容の秘匿そのものを目的としたものではありません。

そのため、必要に応じてファイアウォール、VPN、転送経路の制御などもあわせて考える必要があります。

ゾーン転送と再帰問い合わせの違い

これは混同されやすいですが、まったく別の仕組みです。

ゾーン転送

権威DNSサーバー間でゾーン情報を同期する仕組み

再帰問い合わせ

クライアントの代わりにDNSサーバーが名前解決を進める仕組み

つまり、

• ゾーン転送 = 権威データの複製
• 再帰問い合わせ = 名前解決の代行

です。

権威DNSとキャッシュDNSの違い

権威DNSサーバー

自分が管理しているゾーンについて正式な回答を返すサーバー

キャッシュDNSサーバー

他のDNSサーバーへ問い合わせを行い、その結果を保存して利用するサーバー

ゾーン転送は、基本的に権威DNSサーバー間で使われる仕組みであり、キャッシュDNSの同期機能ではありません。

よくあるトラブル

シリアル番号の更新忘れ

最も典型的な問題です。

転送許可設定の誤り

セカンダリのIPアドレスが許可されていないと転送できません。

TCP 53番の通信不備

UDPは通っていてもTCPが閉じているとゾーン転送は失敗します。

TSIG設定の不一致

キー名、アルゴリズム、共有秘密鍵が一致していないと認証に失敗します。

プライマリ／セカンダリ設定ミス

参照先アドレスやゾーン名の誤りでも同期できません。

差分転送が使えずフル転送になる

IXFRの前提条件がそろっていないと、AXFRへ切り替わることがあります。

長期間同期できず期限切れになる

一定期間更新できないと、セカンダリがそのゾーンを無効と判断することがあります。

確認方法

代表的には dig コマンドで確認できます。

dig AXFR example.com @ns1.example.com

このコマンドは、指定したサーバーに対して example.com のフルゾーン転送を要求します。

結果として、

• レコード一覧が返る
  → 転送が許可されている可能性がある
• Transfer failed
  → 転送拒否や認証失敗などの可能性がある
• タイムアウト
  → 通信経路、ファイアウォール、応答制御などの問題が考えられる

という見方ができます。

ただし、公開DNSサーバーではゾーン転送が拒否されるのが普通です。

また、確認は必ず自分に権限のある環境で行うのが前提です。

BINDなどでの運用イメージ

BINDなどのDNSサーバーソフトでは、概念的には次のような考え方で設定します。

プライマリ側

• このゾーンの元データを管理する
• どの相手にゾーン転送を許可するかを制御する

セカンダリ側

• どのプライマリからゾーン情報を取得するかを設定する
• 必要に応じて認証情報を使って転送を受ける

実装やバージョンによって既定値や細かい挙動は異なるため、転送制御は明示的に設定するのが安全です。

クラウド環境での考え方

最近はBINDなどを自前で運用せず、マネージドDNSサービスを使うことも多くなっています。

その場合、

• セカンダリDNSの概念が表に出ない
• ベンダー側で内部的に冗長化されている
• ゾーン転送の設定項目が直接見えない

こともあります。

ただし、外部DNSとの連携やセカンダリDNS機能を提供するサービスでは、やはりAXFR、IXFR、転送制御、認証の考え方は重要です。

Web運用の現場で意識したい点

ゾーン転送はインフラ寄りのテーマに見えますが、Web運用にも関係します。

DNS変更反映トラブルの原因になりうる

「レコードを変更したのに一部環境で古い応答が返る」というとき、TTLだけでなくセカンダリ未同期が原因のことがあります。

サブドメイン棚卸しの重要性

古いLP、検証環境、旧システム用ホスト、管理用ホストなどが残っていると、設定不備があった場合に情報露出の材料になります。

メールや認証設定にも影響する

MX、SPF、DKIM、DMARCなどの整合性に問題があると、メール配信や認証面へ影響が出ます。

委託先管理の確認項目になる

外部ベンダーへDNS管理を委託している場合でも、ゾーン転送の制限が適切かどうかは確認ポイントになります。

DNSSECとの違い

ゾーン転送

DNSデータを権威サーバー間で同期する仕組み

DNSSEC

DNS応答が正当なものかどうかを検証するための署名の仕組み

つまり、

• ゾーン転送 = データ配布・同期
• DNSSEC = 応答の真正性検証

であり、目的が異なります。

DNSSECを使っていても、ゾーン転送の許可設定が不適切なら情報漏えいリスクは別途存在します。

まとめ

DNSのゾーン転送とは、権威DNSサーバー間でゾーン情報を同期するための仕組みです。

重要なポイントをまとめると、次の通りです。

• プライマリDNSサーバーのゾーン情報をセカンダリDNSサーバーへ複製するために使う
• 方式には AXFR（全転送） と IXFR（差分転送） がある
• 更新判断には SOAレコードのシリアル番号 が重要
• 実運用では NOTIFY により更新検知が早まることが多い
• ゾーン転送は通常 TCP 53番 を使う
• 制限が不適切だと、サブドメイン情報などの漏えいにつながる
• 転送先制限、TSIG、通信制御、不要情報の整理 が安全運用の基本になる

以上、DNSのゾーン転送についてでした。

最後までお読みいただき、ありがとうございました。