【実務・中級編】 ZTNAとDNS（ポート53）および名前解決の秘匿・ルーティング制御 – ゼロトラスト＆エンタープライズセキュリティ実践ガイド

境界防御の幻想を捨てろ：ZTNA時代におけるDNS秘匿と名前解決の全技術

やあ、エンジニア諸君。日々のAPI設計やインフラ運用、本当にお疲れ様。
突然だが、君たちのシステムはまだ「社内ネットワークの内側にいれば安全」という、昭和のオフィスビル発想の幻想にしがみついていないだろうか？

VPNを繋げば社内LANの空気が吸える——そんな時代はもう過去のものだ。リモートワークが当たり前になり、クラウドファーストが極まった現代において、社内ネットワークという「城壁」はもはや意味をなさない。そこで登場するのがゼロトラストネットワークアクセス（ZTNA）だが、ここで多くのインフラエンジニアやWeb API設計者がハマる「最大の落とし穴」がある。それが DNS（ポート53）と名前解決 だ。

今回は、ZTNA環境下において内部ネットワークの構造をいかにして外部（パブリック）から完全に隠蔽し、名前解決の要求を安全にルーティングするか、その泥臭くて美しい実務の裏側を徹底的に解説しよう。

—

1. なぜ「ポート53」がゼロトラストの急所なのか？

境界型防御の時代、私たちは社内DNSサーバー（BINDやActive Directoryなど）をプライベートIPで立て、クライアントは社内LANに接続した瞬間にそのサーバーへ向かって api.internal.corp のような内部ドメインを問い合わせていた。

しかし、ゼロトラストの基本理念は 「Never Trust, Always Verify（決して信用せず、常に検証せよ）」 だ。もし、リモートワーカーが自宅のWi-Fiから社内リソースにアクセスする際、パブリックなインターネット経由で無防備なDNS問い合わせを行ったり、内部ドメインの構造が外から丸見えになっていたりしたらどうなるか？

攻撃者は、DNSのゾーン転送やブルートフォース、あるいは単なるキャッシュポイズニングやDNSの露見を通じて、企業の内部サーバーのホスト名やIPアドレス（例：db-master-01.internal.corp や k8s-internal-ingress.corp）を容易に把握できてしまう。名前解決ができるということは、攻撃者にとっての「社内サーベイランス（偵察フェーズ）」の完了を意味するのだ。

したがって、ZTNAにおける名前解決の設計思想は、「知るべき者だけが、知るべき名前を知り、それ以外の者には存在すら隠蔽する」 でなければならない。

—

2. スプリットDNSとZTNAプロキシによる名前解決の通信フロー

現代の洗練されたZTNAアーキテクチャでは、クライアント端末に常駐するエージェント（ZTNAクライアント）が、DNSクエリのルーティングを厳密に制御する。これを実現するのが スプリットDNS（Split DNS） と ZTNAプロキシ（またはパケットフォワーダー） の連携だ。

百聞は一見にしかず。クライアントが api.corp.local を叩いたとき、パケットとDNSクエリが裏側でどう流れているのか、シーケンスを見てみよう。

[クライアント端末]
  │
  ├── 1. ブラウザ/アプリから `api.corp.local` の名前解決要求が発生
  │
  ├── 2. ZTNAクライアントエージェント（OSのDNSリゾルバをフック）
  │      ├─ 判定: ドメインがプライベートゾーン（例: *.corp.local）に合致するか？
  │      └─ 合致する場合、パブリックDNSには送らず、ZTNAセキュアチャネルへ転送
  │
  ├── 3. ZTNAプロキシ（クラウド/エッジ）へ暗号化トンネル経由でDNSクエリを送信
  │      
  └── 4. 社内プライベートDNSサーバーが名前解決を実行し、応答を返す
         (※この際、パブリックなインターネット側からは一切名前解決ができない)

このフローの美しい点は、クライアントが社外にいようがカフェにいようが、あたかも社内LANの直近にいるかのように安全な名前解決が行われ、かつ外部の野良ネットワークに対して内部ドメインの存在が1バイトたりとも漏洩しないことだ。

—

3. 実践：クライアント側およびZTNAルーターの設定指針

では、具体的にどのような設定を行えば、このセキュアな名前解決ルーティングを構築できるのか。実務でよく使われるオープンソースのVPN/ZTNA基盤や、モダンなOSのDNS設定（systemd-resolvedやTailscale/WireGuard等のコンポーネント）を念頭に置いた設定アプローチを見ていこう。

A. Linuxクライアント (systemd-resolved) の設定例

モダンなLinux環境では、特定のドメインに対するクエリを指定のプライベートDNSサーバー（ZTNAトンネル内のIP）に強制するスプリットDNS設定を記述する。

# /etc/systemd/resolved.conf.d/ztna-split-dns.conf
[Resolve]
# 企業内部向けのドメインのみをZTNA側のDNSサーバーにルーティング
Domains=~corp.local ~internal.api
# ZTNAトンネル内に存在するセキュアな内製DNSサーバーのIPアドレス
DNS=100.64.0.53
# フォールバック用パブリックDNS（社内ドメイン以外用）
FallbackDNS=1.1.1.1 8.8.8.8

> シニアからの実務Tips:
> Domains= の設定で、ドメイン名の頭に必ずチルダ (~) をつけるのがポイントだ。これにより、グローバルなデフォルトDNSではなく、指定したドメインに対するクエリだけがこの DNS= サーバーへルーティングされる（スプリットDNSの有効化）。これを忘れると、全ての名前解決が社内DNSに吸い込まれてしまい、YouTubeや外部APIへのアクセスが死ぬという地獄を見るので注意してほしい。

B. ZTNAプロキシ・ゲートウェイ側（BIND等）のコンフィグレーション

次に、リクエストを受け取る社内側のDNSサーバー（あるいはZTNAゲートウェイ内蔵のDNSフォワーダー）の設定だ。外部からの不正な再帰問い合わせ（Open Resolverとしての悪用）を完全にブロックしつつ、内部ドメインのみを名前解決させる。

// /etc/bind/named.conf.options の一部抜粋
options {
    directory "/var/cache/bind";

    // 外部からの無差別な再帰問い合わせを拒否し、ZTNAトンネル内からの通信のみ許可
    recursion yes;
    allow-recursion { 
        100.64.0.0/10; // ZTNAのキャリアグレードNATレンジ
        10.0.0.0/8;    // 社内プライベートレンジ
        localhost;
    };

    // ゾーン情報の外部公開を防ぐため、不要なバージョン情報やクエリを隠蔽
    version "not currently available";
    allow-transfer { none; };

    dnssec-validation auto;
    listen-on { 100.64.0.53; }; // ZTNA専用のインターフェースのみで待ち受け
    listen-on-v6 { none; };
};

—

4. アプリケーション層（Web API設計）からのアプローチ

インフラ側でどれだけDNSを秘匿しても、アプリケーション層の設計が雑だと、結局内部構造が露出してしまう。例えば、Web APIのクライアントSDKやフロントエンド（React/Vueなど）のコード内に、ハードコードされた内部ホスト名が露出していないだろうか？

ここでは、Python（requests ライブラリ）と、フロントエンドのモダンな Fetch API を用いて、環境に応じた動的なエンドポイント解決と、ZTNAプロキシ経由の通信制御をスマートに実装する例を示す。

PythonによるAPIクライアント実装例

環境変数に基づいて内部向けのエンドポイントとパブリック向けのエンドポイントを切り替えつつ、内部DNSが正常に名前解決できるコンテキストを保証する設計だ。

import os
import requests
from requests.adapters import HTTPAdapter
from urllib3.util.retry import Retry

class SecureAPIClient:
    def __init__(self):
        # 実行環境がZTNAトンネル内にあるか、あるいは環境変数で切り替える
        # 例: ZTNA環境下では internal.api.corp.local を使用
        self.base_url = os.getenv("API_BASE_URL", "https://api.corp.local/v1")
        
        self.session = requests.Session()
        
        # リトライ戦略の設定（ネットワーク揺らぎ対策）
        retries = Retry(
            total=3,
            backoff_factor=0.5,
            status_forcelist=[500, 502, 503, 504]
        )
        self.session.mount("https://", HTTPAdapter(max_retries=retries))

    def fetch_sensitive_data(self, resource_id: str) -> dict:
        target_url = f"{self.base_url}/resources/{resource_id}"
        
        try:
            # このリクエストが発生した際、OSのリゾルバがスプリットDNS経由で
            # api.corp.local をZTNAプロキシ経由で名前解決する
            response = self.session.get(target_url, timeout=5)
            response.raise_for_status()
            return response.json()
            
        except requests.exceptions.RequestException as e:
            # ログには詳細なURLを含めつつ、内部構造がスタックトレース等で外部に漏れないよう配慮
            print(f"[ERROR] Failed to fetch secure resource via ZTNA: {str(e)}")
            raise

# 実行例
if __name__ == "__main__":
    client = SecureAPIClient()
    # データ取得（裏でスプリットDNSとZTNAトンネルが機能している）
    # data = client.fetch_sensitive_data("sec-9921")

—

5. 現場で役立つデバッグ・トラブルシューティングTips

最後に、インフラ構築やAPI結合テストの現場で「名前解決できない！」「つながらん！」と絶望したときに、シニアエンジニアが真っ直ぐ手に取るデバッグコマンドと手順を授けよう。

1. クライアントが実際にどのDNSサーバーに問い合わせているか確認する

LinuxやmacOSで、DNSのルーティングが意図通りスプリットされているか確認するには resolvectl や scutil を使う。

# systemd-resolved を使っている環境での確認
resolvectl status

# 特定のドメインがどのDNSサーバーにルーティングされているかテスト
resolvectl query api.corp.local

もしここで、社内DNSではなくパブリックDNS（8.8.8.8 など）に問い合わせがいっていて NXDOMAIN（名前が存在しない）エラーになっていたら、スプリットDNSの設定（Domains= の記述やインターフェースの優先順位）が負けている証拠だ。

2. dig コマンドで強制的にZTNA用DNSを指定して名前解決をテストする

アプリやOSの設定を疑う前に、DNSサーバー単体が正しく応答するかを直接叩いて検証する。

# ZTNAプロキシ上のDNSサーバー(100.64.0.53)に対して直接問い合わせる
dig @100.64.0.53 api.corp.local +short

# もしここでIPが正しく返ってくればDNSサーバーとトンネルは正常。
# 返ってこなければ、バインドの設定かパケットフォワード（iptables / nftables）のルーティングミスだ。

—

まとめ：境界の壁から「暗号化されたアイデンティティ」へ

境界型防御の時代は、社内ネットワークという「安全な囲い」の中にいれば、DNSだろうが何だろうが信頼された。だが、その城壁は一度破られれば内部はスカスカという致命的な弱点を抱えていた。

ゼロトラストにおけるDNSの秘匿とスプリットDNSのルーティング制御は、単なる「名前隠し」ではない。「通信しようとする相手が誰であり、どの正当なチャネルを通っているか」をDNSのレイヤーから厳格に制御し、攻撃者に企業の内部地図を絶対に渡さないという、現代インフラの防衛ラインそのものなのだ。

教科書通りの設定をコピペするだけでは、現場の複雑なネットワークトポロジーやリモートワークの環境変化には太刀打ちできない。ぜひ今回の解説を参考に、君たちのシステムのDNSまわりをもう一度見直し、真に堅牢なゼロトラスト・アーキテクチャを完成させてほしい。健闘を祈る！

スポンサーリンク

コメント

タイトルとURLをコピーしました