【実務・中級編】 DNSゾーン転送(TCP/53)の仕組みとセキュリティ – ネットワーク基礎とWebセキュリティ実践ガイド

DNSの裏側で動く静かなる巨人：TCP/53（ゾーン転送）の仕組みと実務的セキュリティ対策

こんにちは。夜中に突然のインシデントアラートが鳴り響き、冷や汗を流しながらパケットキャプチャを眺めた経験は、インフラエンジニアなら一度や二度ではないはずです。

私たちが普段何気なく使っているWebブラウザや、マイクロサービス間で飛び交うWeb APIの裏側には、必ずDNS（Domain Name System）の存在があります。AレコードやAAAAレコードの解決には、基本的に軽量で速いUDPのポート53が使われます。これは皆さんご存知でしょう。

しかし、マスター（プライマリ）DNSサーバーとスレーブ（セカンダリ）DNSサーバーの間で、膨大なドメイン情報を同期させる「ゾーン転送」の瞬間を覗いたことはあるでしょうか？

ここで主役に躍り出るのが、TCPのポート53です。

今回は、数々の修羅場を潜り抜けてきたシニアエンジニアの視点から、DNSゾーン転送のリアルな挙動、AXFRとIXFRの仕様、そして実務で絶対やっておかなければならないセキュリティ対策について、泥臭い知見を交えて徹底的に解説します。

—

1. UDPからTCPへ：なぜゾーン転送にはTCP/53が必要なのか？

「DNSはUDP」という固定観念を持っていると、パケットアナライザ（Wiresharkなど）でゾーン転送の通信を見たときに驚くことになります。いきなり3ウェイハンドシェイク（SYN -> SYN-ACK -> ACK）が始まり、TCPポート53番でセッションが確立されるのです。

パケットの断片化とサイズ制限の壁

通常の名前解決（Aレコードの問い合わせなど）であれば、UDPのペイロードサイズ（通常512バイト、EDNS0を使えばさらに拡大）に収まります。しかし、数十、数百のサブドメインや複雑なレコードを持つエンタープライズ環境のゾーンデータは、数KBから場合によっては数MBに及びます。

UDPでこれを送ろうとすると、IPパケットのフラグメンテーション（断片化）が発生し、途中のルーターやファイアウォールでドロップされるリスクが跳ね上がります。さらに、UDPは信頼性（到達確認や順序制御）を担保しないため、レコードの脱落が許されないゾーン同期には致命的な欠陥となります。

そのため、DNSの設計者たちは、「信頼性の高いTCPを用いて、すべてのレコードを確実かつ順序通りに流し込む」という選択をゾーン転送に採用しました。

—

2. AXFRとIXFR：2つの同期プロセスの内部挙動

ゾーン転送には、大きく分けて2種類の方式が存在します。それぞれのパケットの動きを見ていきましょう。

全域転送（AXFR: Full Zone Transfer）

AXFRは、マスターサーバーが持つゾーン情報のすべてを丸ごとスレーブサーバーにコピーする仕組みです。主にスレーブが新しく構築された時や、シリアル番号の差分があまりにも大きすぎて追いつかない場合に発生します。

【通信シーケンスのイメージ】
1. スレーブからマスターへ TCP 3ウェイハンドシェイク確立。
2. スレーブが AXFR リクエスト（QTYPE=AXFR）を送信。
3. マスターが最初のレスポンスとして、SOA（Start of Authority）レコードを返す。
4. 続いて、A、MX、CNAMEなどの全レコードがTCPストリームに乗って流れてくる。
5. 転送の最後に、再度マスターのSOAレコードが送られ、通信終了の目印となる。
6. TCPセッションが切断される。

差分転送（IXFR: Incremental Zone Transfer）

何万ものレコードを持つ大規模なゾーンで、たった1つのIPアドレスが変わるたびにAXFRで全データを送受信していたのでは、ネットワーク帯域の無駄遣いであり、マスターの負荷にもなります。そこで登場するのが、IXFRです。

IXFRでは、SOAレコードの「シリアル番号（Serial Number）」を利用します。スレーブが保持しているシリアル番号と、マスターの現在のシリアル番号を比較し、変更があった差分（追加・削除されたレコード）のみを転送します。

シリアル番号の重要性: BINDなどのDNSサーバーを運用する際、ゾーンファイルを書き換えたら必ずシリアル番号をインクリメント（加算）する必要があります。これを忘れると、スレーブ側が「更新がない」と判断し、いつまで経ってもレコードが同期されません。実務で最もやりがちなミスのひとつです。

—

3. 現場で使える！BIND 9におけるゾーン転送の設定例

では、実際のインフラ構築現場でどのように設定されているのか、BIND 9の構成ファイル（named.conf）を例に見てみましょう。セキュリティを考慮した実務的な設定になっています。

// ==========================================
// マスター（プライマリ）DNSサーバーの設定例
// ==========================================
zone "example.internal" {
    type master;
    file "/var/named/zones/db.example.internal";
    
    // ゾーン転送を許可するスレーブサーバーのIPを指定（セキュリティの基本！）
    allow-transfer {
        192.0.2.10; // スレーブA
        192.0.2.20; // スレーブB
    };

    // TSIG（トランザクション署名）を用いた強固な認証を適用する場合
    // allow-transfer { key "dns-sync-key"; };
};

// ==========================================
// スレーブ（セカンダリ）DNSサーバーの設定例
// ==========================================
zone "example.internal" {
    type slave;
    file "slaves/db.example.internal";
    masters {
        192.0.2.1; // マスターDNSサーバーのIP
    };
};

—

4. ゾーン転送の闇：セキュリティリスクと脆弱性

エンジニアとして最も警戒しなければならないのは、「設定ミスによる意図しないゾーン転送のオープン（オープンリゾルバならぬオープンゾーン転送）」です。

もし、前述の allow-transfer の設定を書き忘れたり、any や 10.0.0.0/8 のような広範なネットワークを許可したままにしておくとどうなるでしょうか？

攻撃者は外部からあなたのDNSサーバーに対して AXFR を要求し、社内ネットワークのIP体系、内部サーバーのホスト名、DMZの構成、果ては隠しAPIのドメイン名に至るまで、すべての設計図をノーコストで丸裸にできてしまいます。これは情報漏洩の第一歩であり、ペネトレーションテスト（脆弱性診断）では最初に狙われるポイントです。

実際にdigコマンドで脆弱性を確認してみる（検証用）

実務では、自社のDNSサーバーが外部から不正なゾーン転送を受け付けていないか、定期的に監査（アセスメント）する必要があります。以下の dig コマンドは、セキュリティ診断で一般的に使われる手法です。

# ターゲットのDNSサーバー（例: ns1.example.internal）に対してAXFRを要求する
dig @ns1.example.internal example.internal AXFR

【正常な防衛がなされている場合のレスポンス】
サーバー側で正しく制限されている場合、以下のように弾かれます（あるいはタイムアウトします）。

; <<>> DiG 9.16.27-Debian <<>> @ns1.example.internal example.internal AXFR
; (1 server found)
;; global options: +cmd
;; connection timed out; no servers could be reached

※あるいは Transfer failed. や REFUSED のステータスが返ってきます。

もし、ここにドメインの全レコードがずらーっと出力されてしまったら……今すぐ allow-transfer の設定を確認してください。

—

5. さらなる高みへ：TSIG（Transaction Signature）による暗号化認証

IPアドレスによるアクセス制限（allow-transfer）は悪くありませんが、クラウド環境や動的ルーティング、IPスプーフィングの危険性を考慮すると、それだけでは十分とは言えません。

エンタープライズの現場では、TSIG（Transaction Signature）を用いた共有鍵暗号方式による認証・署名を必ず導入します。

TSIGの仕組み

1. マスターとスレーブの間で、共通の秘密鍵（例: HMAC-SHA256）をあらかじめ安全に共有する。
2. ゾーン転送のパケット（AXFR/IXFR）を送信する際、その秘密鍵を使ってパケットにデジタル署名を付与する。
3. 受信側は、同じ秘密鍵を使って署名を検証し、正当な通信元であることを確認してから同期を受け入れる。

これにより、IPアドレスを偽装した中間者攻撃（MiTM）や、不正なゾーンデータのインジェクションを完全に防ぐことができます。

—

まとめ：パケットの裏側にある意図を読めるエンジニアへ

今回は、TCP/53で行われるDNSゾーン転送の仕組みから、AXFR/IXFRのパケットの挙動、そして実務における恐ろしいセキュリティリスクと対策までを解説しました。

ゾーン転送は信頼性が命のため、TCP/53でセッションを張って行われる。
AXFRは全件コピー、IXFRはシリアル番号を用いた差分同期である。
allow-transfer の設定ミスやTSIGの未導入は、企業インフラの設計図を敵に差し出すようなもの。

Web APIの設計やモダンなクラウドインフラの構築においても、基礎となるDNSやネットワークの挙動を深く理解しているかどうかが、障害発生時の切り分けスピードや、セキュアなアーキテクチャ設計の明暗を分けます。

「なぜこのポートが開いているのか」「このパケットはどんな文脈で流れているのか」。常にその背景に思いを馳せられる、頼れるシニアエンジニアを目指して一緒に頑張っていきましょう！