DNSゾーン転送とは何か、そしてなぜセキュリティ上の脆弱性となるのか？

冗長性は、ドメインネームシステム（DNS）の根幹をなすものです。権威ネームサーバーがオフラインになったり、接続不能になったりした場合でも、バックアップサーバーが直ちにそのドメインに対するクエリを解決し、サービスに支障をきたさないよう準備されていなければなりません。これらのセカンダリサーバー間の同期を維持するため、DNSではゾーン転送を利用してレコードを自動的に複製しています。

適切に設定されていれば、ゾーン転送は信頼できるサーバー間で目立たない形で実行されます。しかし、たった1つのデフォルト設定やアクセス制御の見落としによって、この複製チャネルがインターネット全体に開放されてしまう可能性があります。そうなると、本来は管理上の利便性を図るための機能が、情報漏洩の温床となってしまいます。

このガイドでは、DNSゾーン転送とは何か、AXFRとIXFRの動作上の違い、オープン転送がなぜ深刻なセキュリティ上の脅威となるのか、そしてネームサーバーを不正な偵察から保護する方法について解説します。

DNSゾーン転送とは何ですか？

DNSゾーン転送とは、プライマリの権威ネームサーバーから、TCPポート53を介して1つ以上のセカンダリネームサーバーへゾーンファイルを複製することです。これにより、セカンダリネームサーバーが、クライアントからのクエリに権威を持って応答するために必要なすべてのリソースレコードの同一のコピーを確実に保持できるようになります。

このレプリケーションが存在する理由を理解するには、権威DNSがどのように機能するかを考えてみましょう。DNSゾーンは、グローバルなドメイン階層内の個別の管理領域を表します。ゾーンファイルには、その領域を定義するリソースレコードの完全なカタログが含まれており、これにはアドレスのマッピング（AレコードおよびAAAAレコード）、メールエクスチェンジャー（MXレコード）、サービスの場所（SRVレコード）、および検証文字列（TXTレコード）などが含まれます。

単一のネームサーバーに依存すると、許容できない単一障害点が生じます。そのサーバーでハードウェア障害、ネットワークの輻輳、または分散型サービス拒否（DDoS）攻撃による障害が発生した場合、訪問者はドメインを解決できなくなります。

ダウンタイムを防ぐため、組織ではセカンダリネームサーバーを導入しています。これらのサーバーを手動で管理すると、管理者がすべてのレコードの変更を複数のホストに逐一反映させる必要があり、非効率的でミスが生じやすくなります。DNSゾーン転送はこのプロセスを自動化し、セカンダリサーバーが更新されたゾーンデータをマスターホストから直接取得できるようにします。これにより、高可用性が確保され、地理的に分散したネームサーバー間でクエリの負荷が分散されます。

DNSゾーン転送の仕組み

DNSゾーン転送はクライアント・サーバー型アーキテクチャに基づいており、セカンダリネームサーバーがデータを要求するクライアントとして機能し、プライマリネームサーバーがそれを提供するサーバーとして機能します。

Webブラウザからの標準的なDNSクエリは、通常、速度とオーバーヘッドの低減を図るため、ユーザーデータグラムプロトコル（UDP）のポート53を介して行われます。これに対し、ゾーン転送は伝送制御プロトコル（TCP）のポート53を介して行われます。TCPは、パケット損失なく大量の構造化データを送信するために必要な、信頼性の高いステートフルな接続とエラーチェックを提供します。

同期処理は、Start of Authority（SOA）レコード、具体的にはそのシリアル番号フィールドに依存しています：

1. シリアル番号の比較： セカンダリネームサーバーは、定期的にプライマリサーバーに対してSOAレコードの照会を行います。また、管理者がゾーンを更新した場合、プライマリネームサーバーは、更新をセカンダリに通知するために、自発的なDNS NOTIFYメッセージ（RFC 1996）を送信することができます。
2. 転送の決定： セカンダリサーバーは、プライマリサーバーのシリアル番号を自身のローカルコピーと比較します。プライマリのシリアル番号の方が大きい場合、セカンダリサーバーはレコードが変更されたことを認識し、転送要求を開始します。
3. データ転送： プライマリサーバーはリクエストを検証し、確立されたTCP接続を介して更新されたレコードを送信します。

設定や変更の量に応じて、サーバーはこの同期処理を、AXFR または IXFR のいずれかの方法で行います。

AXFR（フルゾーン転送）

RFC 1035 で定義され、RFC 5936 で更新された「権威転送（AXFR）」は、当初の転送メカニズムです。AXFR リクエストが実行されると、プライマリネームサーバーは、SOA レコードで始まり、SOA レコードで終わるゾーンファイル全体を送信します。

AXFRはシンプルで信頼性が高い反面、大規模なゾーンでは非効率的です。企業が50,000件のリソースレコードを含むゾーンを管理しており、その中の1つのIPアドレスを変更した場合、AXFR転送では50,000件すべてのレコードが再送信されます。トラフィック量の多いネットワークでは、このような全レコードの転送が繰り返されることで、不要なネットワーク帯域幅や処理リソースが消費されてしまいます。

IXFR（増分ゾーン転送）

完全転送に伴うオーバーヘッドを排除するため、RFC 1995 では増分ゾーン転送（IXFR）が導入されました。IXFR では、データベース全体をコピーする代わりに、セカンダリサーバーの現在のバージョンとプライマリサーバーの更新後のバージョンとの間の具体的な相違点のみを送信します。

IXFRによる通信中、セカンダリサーバーはリクエスト内に現在のSOAシリアル番号を送信します。プライマリサーバーは変更ログを評価し、その間のバージョン間でどのレコードが削除され、どのレコードが追加されたかを特定した上で、それらの差分データのみを送信します。これにより、帯域幅の消費が大幅に削減され、分散アーキテクチャ全体での同期が高速化されます。

AXFRとIXFRの比較

セカンダリサーバーが長期間オフラインの状態にあり、そのシリアル番号がプライマリサーバーのトランザクション履歴の範囲外となっている場合、IXFRではそのギャップを埋めることができません。そのような状況では、システムはゾーンを再構築するために、正常にフルAXFR転送に切り替わります。

オープンゾーン転送がセキュリティ上の脆弱性となる理由

ゾーン転送は管理上の同期に不可欠ですが、その設計は機密性よりも可用性を重視して行われました。デフォルトでは、従来のネームサーバーの設定では、受信するAXFRクエリをすべて正当なものとして扱うことが多かったのです。

オープンゾーン転送とは、権威ネームサーバーが、権限のないIPアドレスから発信されたAXFRリクエストに応答してしまう現象のことです。この設定ミスが存在する場合、インターネットに接続している誰でもそのネームサーバーにクエリを送信し、ゾーンファイルの完全なコピーを受け取ることができます。

この脆弱性は、重大な情報漏洩のリスクをもたらします。攻撃者は、試行錯誤によるブルートフォース攻撃に頼るのではなく、組織のデジタルフットプリントに関する、権限付きで体系化された一覧情報を入手することになります。これにより、手作業による偵察段階が、瞬時かつ包括的なシステム発見へと変わります。オープンゾーン転送は、依然として最も多く記録されている 一般的なDNSの脆弱性の一つであり続けています であり続けています。これは、内部の運用設計図が公に閲覧可能になってしまうためです。

攻撃者はゾーン転送から何を学ぶのか

脅威アクターがオープンAXFRクエリを通じてゾーンファイルを入手すると、標準的なDNSクエリではほとんど確認できないデータにアクセスできるようになります：

• サブドメインディレクトリの完全な一覧： 攻撃者は、内部機能、部署、または独自技術にちなんで名付けられたホスト名を含め、登録されているすべてのサブドメインを特定します。
• 開発およびステージング用ホスト: dev.example.com、test-api.example.com、qa-vpn.example.com などのサブドメインでは、本番環境レベルのファイアウォールや最新のセキュリティパッチ、厳格なアクセス制御が整備されていない、リリース前のソフトウェアが頻繁に実行されています。
• 管理用およびリモート用ポータル： イントラネットのリンク、従業員向けポータル、VPN接続ポイント、およびデータベース管理インターフェースは、レコード一覧に直接表示されることがよくあります。
• メールおよびルーティングのアーキテクチャ： MXレコードおよびそれに対応するメールホストのIPアドレスは、組織のメールフィルタリングのトポロジー、ルーティングのホップ数、およびサードパーティの配信サービスを明らかにします。
• サードパーティによる検証データ： 監査を受けていないTXTレコードには、クラウドプラットフォーム、SaaS連携、分析ツール向けの検証トークンや、内部インフラの依存関係を示唆する過去の検証文字列が含まれていることがよくあります。

ゾーン転送の漏洩が他の攻撃を助長する仕組み

オープンゾーン転送を通じて得られた情報は、高度な二次攻撃を行うための足掛かりとなります：

• サブドメインの乗っ取り： ゾーンファイルには、使用されなくなったAmazon S3バケット、GitHub Pages、Microsoft Azureインスタンスなど、廃止されたクラウドリソースを指す「ダングリングCNAMEレコード」が含まれていることがよくあります。攻撃者は、CNAMEレコードの完全なリストを入手することで、サードパーティプロバイダー上のこれらの放置されたリソースを乗っ取り、被害者の認証済みドメインの下で不正なコンテンツを配信することが可能になります。
• スピアフィッシングとソーシャルエンジニアリング： 社内サーバーの命名規則、従業員ポータルのアドレス、およびベンダーとの関係を把握することで、攻撃者は極めて信憑性の高いソーシャルエンジニアリングの罠を仕掛けることが可能になります。攻撃者が標的型メール内で実際の社内ホスト名を参照すると、受信者がその通信を信頼する可能性が大幅に高まります。攻撃者がインフラストラクチャに関する情報をどのように活用して標的型の認証情報収集を行っているかについては、以下の解説記事をご覧ください。 スピアフィッシングに関する詳細な解説をご覧ください。
• 攻撃対象領域の拡大： プライベートネットワークが誤ってパブリックゾーンに統合されると、ゾーン転送によって内部のIPアドレス体系が頻繁に露呈してしまいます。これにより、攻撃者は境界ファイアウォールを探知し、内部の管理用インターフェースを標的とするために必要なルーティング情報を得ることになります。

さらに、ゾーン転送自体はトラフィックを操作するものではありませんが、企業のキャッシュおよびルーティングのトポロジーを理解することで、次のような二次的な攻撃を容易にする可能性があります。 DNSキャッシュポイズニングといった二次的な攻撃を容易にする可能性があります。

ドメインでゾーン転送が許可されているかを確認する方法

セキュリティ管理者は、権威ネームサーバーが不正なゾーン転送を許可していないかどうかを確認する必要があります。その目的は、ゾーンの完全なコピーを要求する外部からのクエリに対して、完全なレコードではなく、明示的な拒否応答が返されることを確認することです。

管理者は、ドメインのNSレコードに記載されている各権威ネームサーバーに対して、外部の信頼できないネットワーク環境からAXFRクエリを送信することで、この状態を評価します。

• セキュアな動作: ネームサーバーはクエリを即座に拒否し、REFUSED または SERVFAIL のステータスを返します。ゾーンレコードは一切送信されません。
• 脆弱性を招く動作： ネームサーバーは接続を受け入れ、AXFRリクエストの受信確認を行い、ドメインのリソースレコードの完全なリストをストリームで返します。

定期的な抜き打ち検査に加え、企業環境では自動監視の導入が有効です。自動設定チェックにより、ネームサーバーの更新によって意図せず転送制限が解除されてしまった場合を検知できます。 

PowerDMARCには、その DNSセキュリティ監視 スイートに自動AXFR露出チェック機能を組み込んでおり、権威サーバーがパブリックゾーン転送リクエストに応答し始めた瞬間に管理者にアラートを送信します。

DNSゾーン転送のセキュリティ対策方法

不正なゾーン転送からドメインを保護するには、厳格なアクセス制限と最新の暗号化対策を実施する必要があります。公式の NISTのDNSセキュリティガイドライン に従うことで、ドメインの完全性を確保するための信頼できる基準が確立されます。

DNSインフラ全体において、以下の防御策を実施してください：

1. IPアドレスによる転送の制限：制限のないAXFRまたはIXFRクエリは決して許可しないでください。ネームサーバーの設定ブロック内（BINDのallow-transferディレクティブなど）で、許可されたセカンダリネームサーバーのIPアドレスを明示的に指定し、そのホワイトリストに含まれていない外部からのすべてのリクエストを拒否してください。
2. TSIG による認証： IPアドレスのみによるアクセス制限は基本的な保護策となりますが、特定のネットワークトポロジーではIPアドレスが偽装される可能性があります。トランザクション署名（TSIG）を実装し、共有された暗号秘密鍵を使用してネームサーバー間の通信を認証してください。
3. スタンドアロンシステムでのゾーン転送を無効にする: ドメインが単一のネームサーバーに依存している場合、または独自のAPIバックプレーンを介して同期を行う最新のマネージドDNSプロバイダーを利用している場合は、ゾーン転送を完全に無効にしてください。
4. スプリットホライズンDNSの実装： 社内ネットワーク用と外部向けパブリックサービス用のゾーンファイルを別々に管理します。社内ホスト名、テスト環境、およびステージング用サブドメインは、決して一般に公開されているゾーンファイル内に含めてはなりません。
5. ネームサーバーデーモンにパッチを適用しておく： DNSソフトウェアの脆弱性を悪用すると、攻撃者がACLルールを迂回したり、リソース枯渇を引き起こしたりする可能性があります。BIND、PowerDNS、Knot DNS、NSDなどのサーバーソフトウェアは、常に最新かつパッチ適用済みのバージョンを実行し、ゼロデイ脆弱性や DNS増幅攻撃への曝露を最小限に抑えてください。
6. 転送リクエストに関するログとアラート： ネームサーバーのクエリログを監視し、予期しないAXFRまたはIXFRリクエストがないか確認してください。見知らぬIPアドレスからの転送試行が繰り返される場合は、多くの場合、攻撃者による積極的な偵察活動が行われていることを示しています。
7. ゾーンレコードを定期的に監査する： ゾーンファイルを定期的に確認し、不要なレコード、特に有効期限が切れたサードパーティのクラウドホスティングリソースを指している古いCNAMEエントリを特定して削除してください。

TSIG による転送の認証と XoT による暗号化

RFC 2845 で標準化され、RFC 8945 で改訂されたトランザクション署名（TSIG）は、DNS メッセージングに暗号による認証を追加するものです。TSIG は、プライマリネームサーバーとセカンダリネームサーバーの間で確立された対称の共有秘密鍵に依存しています。

設定が完了すると、セカンダリネームサーバーは、共有鍵と現在のタイムスタンプから導出された暗号ハッシュを用いて、AXFRまたはIXFRリクエストに署名を行います。プライマリネームサーバーは、自身の鍵を用いてその署名を検証します。署名が一致し、許容される時間枠内にある場合、転送が実行されます。鍵が存在しないか無効である場合、プライマリサーバーは接続を拒否します。

TSIGは身元確認を行い、データの完全性を保証しますが、転送中にゾーンの内容自体を暗号化することはありません。この機密性の欠如を解決するため、インターネット技術タスクフォース（IETF）は RFC 9103を公開し、TLS（Transport Layer Security）を介したDNSゾーン転送（XoT）を規定しました。XoTは、AXFRおよびIXFRセッションを暗号化されたTLSトンネル内にカプセル化することで、転送ネットワークにおける盗聴、中間者攻撃による検査、および改ざんを防止します。

PowerDMARC によるゾーン転送の露出状況の監視

ネームサーバーのインフラを保護するには、防御的なサーバー設定と、継続的な外部からの可観測性の両方が必要です。インフラチームがゾーンのアクセスリストを管理する一方で、セキュリティアナリストは、管理上のミスやクラウドへの移行によってレコードが知らぬ間に公開されないよう、継続的な可視性を確保する必要があります。

PowerDMARCは、包括的な 最高のDNSセキュリティソリューション エコシステムに組み込んでいます。

PowerDMARCの「DNSセキュリティ監視・コンプライアンス」サービスは、インラインフィルタリングプロキシやファイアウォールではなく、外部DNSレコードの監視およびセキュリティコンプライアンス管理プラットフォームとして位置付けられており、お客様の権威ネームサーバー全体に対して自動チェックを実行します：

• AXFRのセキュリティチェック： 外部の場所から権威ネームサーバーに対して継続的にテストを行い、不正なゾーン転送が拒否されていることを確認します。
• ゾーンリークに関する監査ログ： セカンダリまたはプライマリネームサーバーが誤ってAXFRデータダンプを許可してしまった場合、即座にフラグを立て、ログに記録します。
• レコードの変更検出： SOAによるシリアルデータの移動を監視し、公開リソースレコードにおける追加、変更、削除を追跡します。
• ネームサーバーの同期確認： セカンダリネームサーバーが、プライマリネームサーバーと照らし合わせて同一かつ同期されたレコードを保持していることを検証します。
• DNSSEC とダングリング CNAME の監視： DNSSECチェーンの破損を管理者に警告し、サブドメイン乗っ取りに悪用される前に、古くなったCNAMEレコードを特定します。

厳格なネームサーバーへのアクセス制御と、継続的な自動レコード監視を組み合わせることで、DNSトポロジーの機密性、耐障害性、および企業のセキュリティ基準への準拠が確保されます。

よくあるご質問

DNSゾーン転送の目的は何ですか？

DNSゾーン転送では、プライマリの権威ネームサーバーからセカンダリのネームサーバーへ、TCPポート53を介してゾーンデータが複製されます。この複製により、分散ネットワーク全体での高可用性、負荷分散、および耐障害性が確保され、プライマリサーバーが利用できなくなった場合でも、ドメイン解決の失敗を防ぐことができます。

AXFRとIXFRの違いは何ですか？

AXFRはフルゾーン転送を実行し、変更の有無にかかわらず、ゾーンファイル全体および関連するすべてのリソースレコードを送信します。一方、IXFRは増分転送を実行し、セカンダリサーバーの最後の同期シリアル番号以降に行われた特定のレコードの追加および削除のみを送信します。

DNSゾーン転送は攻撃にあたるのでしょうか？

いいえ、ゾーン転送とは、インターネット標準で定義された標準的な管理メカニズムのことです。これがセキュリティインシデントとなるのは、権威ネームサーバーの設定ミスにより、権限のない一般のクライアントに対してオープンで無制限のAXFR転送が許可され、攻撃者が組織のドメインインフラストラクチャの全体像をダウンロードできてしまう場合に限られます。

ゾーン転送ではどのポートが使われますか？

ゾーン転送ではTCPポート53が使用されます。標準的な再帰的DNS検索では速度向上のためにUDPポート53が使用されますが、ゾーン転送では、データの切り捨てやパケット損失が発生することなく、大容量で複数のパケットにまたがるゾーンレコードを確実に送信できる信頼性の高い接続を確立するために、TCPが必要となります。

TSIGとは何ですか？また、どのようにしてゾーン転送のセキュリティを確保しているのでしょうか？

TSIG（Transaction Signatures）は、RFC 8945で定義されているDNS認証メカニズムです。これは、共有の対称暗号鍵を使用してゾーン転送リクエストおよびレスポンスに署名を行い、プライマリおよびセカンダリネームサーバーが、ゾーンレコードを送信する前に相互に認証を行い、データの完全性を検証することを保証します。

マネージドDNSプロバイダーはゾーン転送を許可していますか？

最新のマネージドクラウドDNSプロバイダーの多くは、デフォルトで従来のパブリックAXFR転送を無効にし、独自のAPIや内部のアニキャストネットワークを使用してレコードを複製しています。ただし、一部のクラウドプロバイダーでは、カスタム製の外部セカンダリネームサーバーを接続する際のハイブリッド環境に対応するため、オプションとして安全なAXFR設定を提供しています。

まとめ

DNSゾーン転送は、ネットワークの継続的な可用性と信頼性の高いドメイン解決を維持するために不可欠です。しかし、制限を設けずに放置すると、企業ネットワークへの「開かれた窓」となり、攻撃者にサブドメイン、管理ポータル、さらには忘れ去られたテスト環境の詳細な一覧をさらすことになってしまいます。

ゾーン転送のセキュリティを確保するために、冗長性を放棄する必要はありません。転送を承認されたセカンダリIPアドレスに限定し、TSIGキーを用いて通信の認証を行い、XoTでセッションを暗号化し、厳格なゾーン管理を維持することで、可用性を損なうことなくネーミング資産を保護することができます。

今すぐ、ドメインインフラのセキュリティ強化に向けた第一歩を踏み出しましょう。当社の 無料のドメインアナライザー を利用してパブリックDNSの状態を確認するか、PowerDMARCのDNSセキュリティモニタリングを導入して、インフラが不正に公開されるのを防ぎましょう。