インターネットを利用する際、私たちはドメイン名を通じてWebサイトにアクセスしたり、メールを送受信したりしています。
この背後でドメイン名とIPアドレスを紐付けているのがDNS（Domain Name System）という仕組みです。
DNSを安定して運用するためには、複数のサーバーで同じ情報を共有し、負荷分散や冗長性を確保する必要があります。
このサーバー間での情報共有を実現する仕組みこそが、今回解説する「ゾーン転送」です。
本記事では、ゾーン転送の基本的な仕組みから、その種類、そして運用において避けては通れないセキュリティ上の注意点までを詳しく解き明かしていきます。
ゾーン転送とは何か？
ゾーン転送とは、特定のドメインに関する管理情報（ゾーンデータ）を、あるDNSサーバーから別のDNSサーバーへコピーするプロセスのことを指します。
DNSサーバーには、情報の原本を持つ「プライマリDNSサーバー（マスター）」と、そのコピーを保持する「セカンダリDNSサーバー（スレーブ）」という役割分担が存在します。
プライマリサーバーでドメイン情報の変更が行われた際、その内容をセカンダリサーバーに同期させるためにゾーン転送が実行されます。
これにより、世界中のどのDNSサーバーに問い合わせても、常に最新かつ同一の情報を得られるようになります。
もしゾーン転送が正常に行われないと、サーバー間で情報の不一致が生じ、Webサイトが表示されないといったトラブルの原因となります。
そのため、ネットワーク管理者にとってゾーン転送の適切な設定は、サービスの可用性を維持するための不可欠な業務と言えるでしょう。
ゾーン転送の仕組みと通信の流れ
ゾーン転送は、主にTCPのポート番号53を使用して行われます。
通常のDNSクエリ（名前解決）では高速なUDPが使われますが、データの信頼性が求められるゾーン転送では、コネクション型のTCPが採用されています。
転送のトリガーとなるのは、主に「通知（DNS NOTIFY）」または「定期的な確認」の2パターンです。
DNS NOTIFYによる同期
プライマリサーバーの設定が更新されると、プライマリ側からセカンダリサーバーに対して「更新があった」という通知が送られます。
この通知をDNS NOTIFYと呼び、これを受け取ったセカンダリサーバーが転送を要求します。
この仕組みにより、管理者が手動で操作しなくても、情報の変更が即座に反映されるようになっています。
SOAレコードに基づく定期更新
セカンダリサーバーは、プライマリサーバーからの通知を待つだけでなく、一定の間隔でデータの更新を確認しています。
この間隔を制御しているのが、ゾーン情報の冒頭に記述されている「SOA（Start of Authority）レコード」です。
SOAレコードには、シリアル番号や更新間隔（Refresh）、再試行間隔（Retry）といったパラメータが含まれています。
セカンダリサーバーは、自身の持つシリアル番号よりもプライマリサーバーの番号が大きくなっている場合に、転送を開始します。
ゾーン転送の2つの主要な方式
ゾーン転送には、効率性や通信環境に応じて使い分けられる2つの主要な方式が存在します。
それぞれの特性を理解することで、より効率的なネットワーク運用が可能になります。
AXFR（全ゾーン転送）
AXFRは、ゾーン内のすべてのリソースレコードを一度に転送する方式です。
セカンダリサーバーを新規に構築する際や、既存のデータが何らかの理由で破損した場合などに使用されます。
非常にシンプルで確実な方法ですが、ゾーン内のデータ量が多い場合、転送に時間がかかりネットワーク帯域を圧迫するというデメリットがあります。
IXFR（増分ゾーン転送）
IXFRは、前回の同期から変更された差分データのみを転送する方式です。
ドメイン情報の一部を修正しただけで、全データを再送するのは非効率であるため、大規模なゾーン運用ではIXFRが好んで利用されます。
通信量を大幅に削減できるため、モバイル回線を経由した通信や、頻繁に更新が発生する環境において非常に有効です。
ただし、サーバー双方がIXFRに対応している必要がある点には注意が必要です。
ゾーン転送とセキュリティの重要性
ゾーン転送は便利な機能ですが、適切な制限をかけずに公開してしまうと、深刻なセキュリティリスクを招くことになります。
かつては誰でもゾーン転送を要求できる設定が一般的でしたが、現在では厳格な制限を設けることが常識となっています。
情報漏洩のプロトコルとしての悪用
第三者が自由にゾーン転送を実行できてしまうと、そのドメインに登録されているすべてのホスト名やIPアドレスの一覧が筒抜けになります。
攻撃者はこの情報を利用して、社内システムや開発用サーバーの存在を特定し、標的型攻撃の足がかりにします。
例えば、外部には公開していないはずのホスト名から、社内のネットワーク構成を推測されてしまう危険性があります。
したがって、不特定多数からのゾーン転送要求は、必ず拒否するように設定しなければなりません。
DoS攻撃への悪用
ゾーンデータのサイズが非常に大きい場合、大量のゾーン転送要求を送りつけることで、DNSサーバーのリソースを枯渇させる攻撃が可能です。
これにより、正当なユーザーからの名前解決要求に応答できなくなる「サービス拒否（DoS）状態」に陥る恐れがあります。
安全にゾーン転送を行うための対策
セキュアなゾーン転送を実現するためには、いくつかの防御策を組み合わせる多層防御の考え方が重要です。
以下の手法を導入することで、外部からの不正なデータ取得を効果的に防ぐことができます。
IPアドレスによる転送制限
最も基本的な対策は、ゾーン転送を許可するサーバーのIPアドレスを限定することです。
プライマリサーバーの設定において、あらかじめ登録したセカンダリサーバーのIPアドレス以外からのAXFR/IXFR要求を拒否するように指定します。
BINDなどの主要なDNSソフトウェアでは、allow-transferなどのディレクティブを使用してこの制限を記述します。
TSIG（Transaction SIGnature）の導入
IPアドレスによる制限だけでは、IPスプーフィング（なりすまし）などの攻撃を完全に防ぐことは困難です。
より強固な認証を実現するために、TSIG（共通鍵暗号を用いた署名技術）を利用することが推奨されます。
TSIGでは、プライマリとセカンダリの間で事前に共通の秘密鍵を共有し、通信ごとに署名を行います。
これにより、転送要求が正当な相手から送られたものであることと、通信途中でデータが改ざんされていないことを証明できます。
ステルスマスター構成の検討
セキュリティをさらに高める手法として「ステルスマスター」と呼ばれる構成があります。
これは、実際にゾーン情報を管理しているプライマリサーバーを外部に公開せず、セカンダリサーバーのみをインターネット上に配置する構成です。
外部の攻撃者はプライマリサーバーの存在を直接知ることができないため、攻撃の対象となるリスクを最小限に抑えることが可能です。
ゾーン転送の確認に役立つツール
設定が正しく行われているかを確認するために、管理者は診断ツールを活用する必要があります。
代表的なツールとして、LinuxやmacOSに標準搭載されているdigコマンドが挙げられます。
以下のコマンドを実行することで、特定のサーバーに対してゾーン転送を試行することができます。
# 指定したDNSサーバーに対してゾーン転送（AXFR）を要求する例
dig @ns1.example.com example.com axfrもし外部のPCからこのコマンドを実行してエラー（Transfer failed）になれば、適切にアクセス制限がかかっていることを意味します。
一方で、管理下のセカンダリサーバーから実行して成功すれば、同期設定が正しく機能していることが確認できます。
; <<>> DiG 9.16.1-Ubuntu <<>> @ns1.example.com example.com axfr
; (1 server found)
;; global options: +cmd
; Transfer failed.このように、定期的に設定の有効性をチェックすることも、安定運用の重要な要素です。
まとめ
ゾーン転送は、DNSサーバー間でドメイン情報を確実に同期させ、インターネットの基盤を支える重要な仕組みです。
AXFRやIXFRといった方式を適切に選択することで、効率的な運用を実現できます。
しかし、その利便性の裏には情報漏洩やDoS攻撃といったセキュリティリスクが潜んでいます。
IPアドレスによる制限やTSIGによる認証を確実に実施し、安全なDNS運用を心がけることが大切です。
DNSの冗長化を図る際には、今回紹介した仕組みを正しく理解し、堅牢なシステムを構築してください。
