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

境界防御の終焉と「見えないDNS」：ZTNAにおける名前解決の深淵

かつて、エンタープライズネットワークの守護神は「ファイアウォール」という名の城壁でした。しかし、クラウドネイティブな現代において、城壁のゲートを叩く者はもはや信頼に足る社員ばかりではありません。我々は今、「信頼するな、常に検証せよ」というゼロトラストの荒野に立たされています。

今回は、ZTNA（Zero Trust Network Access）の設計において、しばしば見落とされがちな「名前解決の秘匿」という深淵にメスを入れます。なぜ、あなたの社内DNSは「偵察」のターゲットになり得るのか。そして、それをどう封じ込めるべきか。パケットの深層から紐解いていきましょう。

1. DNSという名の「地図」を敵に渡すな

伝統的なスプリットDNS構成では、クライアントがinternal.example.comを引く際、クエリは境界のDNSサーバーへ平文（UDP/53）で投げられます。これは、内部ネットワークのトポロジーを全方位に宣言しているに等しい。攻撃者はパッシブなネットワーク盗聴だけで、あなたの組織にどのリソースが存在するかという「宝の地図」を手に入れることができます。

ZTNAの理想は、「名前解決そのものをトンネル化し、プロキシ経由で処理する」ことです。

パケットレベルの秘匿化戦略

DoH（DNS over HTTPS）やDoT（DNS over TLS）をZTNAクライアントに組み込むことは、もはや必須要件です。これにより、名前解決のクエリは通常のHTTPS（443/TCP）トラフィックにカプセル化されます。

RTT削減の工夫: TLS 1.3の0-RTTハンドシェイクや、QUIC（HTTP/3）を採用することで、DNSクエリのレイテンシを極限まで圧縮します。
ヘッダー圧縮: HPACKやQPACKを用いてDNSのペイロードを圧縮し、中継プロキシの負荷を軽減。大規模環境ではこの数ミリ秒の積算が、ユーザー体感速度を劇的に変えます。

2. カーネルレベルでのルーティング制御：nftablesを活用した強制転送

ZTNAクライアントを配布できない環境や、レガシーなIoTデバイスを保護する場合、境界ルーターやゲートウェイ側で「DNSの強制ルーティング」を行う必要があります。ここで、Linuxのnftablesを用いた、スマートな透過的DNSプロキシの仕組みを見てみましょう。

# 53番ポートへの通信を強制的かつ透過的にZTNAプロキシへ転送する例
# 外部からのDNSクエリをインターセプトし、自身のDoH変換プロセスへ流し込む
table inet nat {
    chain prerouting {
        type nat hook prerouting priority dstnat;
        # 社内DNSへのクエリをローカルのDoHプロキシ（例: 127.0.0.1:8053）へリダイレクト
        iifname "eth0" tcp dport 53 dnat to 127.0.0.1:8053
        iifname "eth0" udp dport 53 dnat to 127.0.0.1:8053
    }
}

この実装の肝は、クライアントに設定を変更させることなく、ネットワーク層でクエリを「握りつぶす」点にあります。dnatを使うことで、クライアントは自分がプロキシと通信していることに気づくことはありません。

3. TCPスタックのチューニングとパフォーマンスの極致

ZTNAプロキシを経由させる際、最もボトルネックになりやすいのは「接続の確立」です。特に、クライアントとプロキシ間、そしてプロキシと上流リソース間の双方向ハンドシェイクが重なると、RTTは倍増します。

LinuxのTCPカーネルパラメータをチューニングし、このオーバーヘッドを最小化します。

# 接続切断後の再利用を高速化し、短時間の大量クエリを捌く
net.ipv4.tcp_tw_reuse = 1

# TCPウィンドウサイズを動的に調整し、高帯域・高遅延環境でのスループットを維持
net.ipv4.tcp_rmem = 4096 87380 16777216
net.ipv4.tcp_wmem = 4096 65536 16777216

# 接続失敗時のバックオフを抑え、ユーザーの待機時間を短縮
net.ipv4.tcp_syn_retries = 2

4. 結びに：境界から「アイデンティティ」へ

名前解決を秘匿し、DNSクエリさえもアイデンティティに基づいた認可プロセスの一部とみなすこと。これが、境界防御から脱却した後の、真のゼロトラストの姿です。

DNSを単なる「名前解決の手段」として扱う時代は終わりました。それは、ネットワークの存在を証明し、認可されたユーザーにのみ限定的に開示されるべき「機密情報」です。パケットを暗号化し、プロキシで抽象化し、カーネルの奥底で制御する。この泥臭くも精密なアーキテクチャこそが、あなたのエンタープライズを守る最後の砦となるでしょう。

技術は常に進化し、攻撃者は次の隙を狙っています。しかし、プロトコルの挙動を理解し、その挙動を制御下に置く我々インフラ屋がいる限り、ゼロトラストはただのバズワードではなく、強固な現実として実装可能なのです。

—
執筆後記:
次回は、このZTNA環境における「証明書ベースのmTLS認証」を、サイドカープロキシなしでeBPFを用いて極限まで軽量化する手法について解説する予定です。ネットワークの深淵を覗く準備をしておいてください。