はじめに：なぜ、社内ニート（失礼、社内SE）の私は夜な夜な「名前解決」に泣かされるのか
「VPNを廃止して完全なゼロトラスト移行だ！今日から君たちの端末はどこから繋いでもゼロトラスト！」
……よくある威勢の良い経営陣の号令で始まったZTNA（Zero Trust Network Access）プロジェクト。ですが、インフラ担当者なら誰しも、その裏で冷や汗をかいた経験があるはずです。リモートワーク中のエンジニアから届く、こんな悲鳴の数々を。
「社内向けのWeb APIにapi.internal.corpで繋がらないんですが！」
「あれ？ カフェのWi-Fiに変えたら、さっきまで見えていた社内システムが『サーバーが見つかりません』になるんだけど……」
そう、これこそが境界型防御から脱却したエンジニアの前に立ち塞がる、最大にして最初の難関――「DNS解決の迷宮」です。
パブリックなインターネットの世界と、厳重にプロテクトされたプライベートな社内ネットワークの境界が溶け出したとき、OSはどちらのDNSサーバーに問い合わせるべきか迷子になります。今回は、この泥臭くてシビアな名前解決の闇を切り崩し、現代のZTNA環境に欠かせない「プライベートDNSプロキシ」が、いかにして私たちの夜勤を救うのか、その仕組みと実装のすべてを解き明かしていきましょう。
—
1. 境界型防御の崩壊と、ZTNAが直面する「名前解決」のジレンマ
かつての「城壁防御（Castle-and-Moat）」モデルでは、社内LAN（お城の中）にさえ入ってしまえば、社内DNSサーバーがすべての名前解決を握っていました。intranet.localだろうが、外部のexample.comだろうが、社内リゾルバがすべてよしなに処理してくれたのです。
しかし、ゼロトラストの思想では「場所」を信頼しません。ユーザーは自宅、カフェ、移動中の新幹線など、あらゆる「信頼できないネットワーク（Untrusted Network）」からアクセスします。この状態で社内リソースへアクセスさせようとすると、次のような構造的な矛盾が生じます。
1. スプリット・ホライゾンDNSの限界: 社内用プライベートIPアドレス（例: 10.0.0.0/8）をパブリックDNSに登録するわけにはいきません。情報漏洩やスプーフィングの温床になります。
2. ルーティングの矛盾: ユーザーのPCがパブリックDNS（例: 8.8.8.8や1.1.1.1）に問い合わせた場合、社内ドメイン（*.internal.corp）の名前解決結果は「そんなドメイン知らん（NXDOMAIN）」か、あるいはパブリックに公開された別サーバーのIPが返ってきてしまい、ZTNAのセキュアトンネルにパケットを流し込めません。
つまり、「パケットをセキュアなトンネルへ流し込むためには、その手前の段階で『正しいプライベートIP』の名前解決が完了していなければならない」という鶏と卵のジレンマが存在するのです。
—
2. プライベートDNSプロキシのアーキテクチャと通信フロー
このジレンマを鮮やかに解決するのが、端末エージェントやエッジルーターに組み込まれる「プライベートDNSプロキシ（Private DNS Proxy）」です。
多くの先進的なZTNAソリューション（Cloudflare One, Zscaler Private Access, Tailscaleなど）は、クライアント端末のOSに仮想ネットワークインターフェース（TUN/TAPデバイス）を張り、同時にローカルのループバックアドレス（例: 127.0.0.1:53 や専用の仮想IP）に軽量なDNSフォワーダー（プロキシ）を常駐させます。
データの流れるリアルなシーケンス
開発者がブラウザやAPIクライアントから https://api.internal.corp/v1/users を叩いた瞬間、パケットとクエリの裏側では次のようなドラマが展開されています。
[開発者のPC (Client OS)]
│
├─ 1. ブラウザが「api.internal.corp」の名前解決を要求
│
▼
[ローカルDNSプロキシ (127.0.0.1:53)]
│
├─ 2. ドメイン名がスプリットDNSのルーティングルールに合致するか判定？
│ ├─ 合致する (例: *.internal.corp) ──> 3へ
│ └─ 合致しない (例: google.com) ──> 4へ
│
├─ 3. 【プライベート経路】ZTNAの暗号化トンネルを経由し、社内権威DNSへクエリ転送
│ └─ 応答: 「10.100.50.20（社内APIサーバーのプライベートIP）」
│
└─ 4. 【パブリック経路】通常のISP/パブリックDNS (8.8.8.8等) へ転送
└─ 応答: パブリックIP
│
▼
[OSのネットワーク層]
└─ 5. 宛先IP「10.100.50.20」宛てのパケットをZTNAの仮想インターフェースへルーティングこの仕組みの肝は、「どのドメインの問い合わせを、どのDNSサーバーへルーティングするか（Split DNS Routing）」をクライアント側のプロキシが完全に制御している点にあります。ユーザーは、社内にいようがスタバにいようが、意識することなく同じ api.internal.corp というURLを叩くだけで、ZTNAトンネルを介して安全にAPIサーバーへ到達できるのです。
—
3. 実務で直面する設定の罠とパラメータのチューニング
現場のインフラエンジニアとして、このプライベートDNSプロキシを導入する際に必ずハマるポイントがいくつかあります。机上の空論ではなく、トラブルシューティング現場の知見を共有しましょう。
トラブル1: キャッシュポイズニングとTTLの罠
社内システムの切り替え時、DNSの古いキャッシュが残り続けて接続エラーになるインシデントが多発します。プライベートDNSプロキシの設定では、負のキャッシュ（NXDOMAINのキャッシュ時間）と正のキャッシュの最大TTL（Max TTL）を短めに設定するのが鉄則です。
トラブル2: mDNSやパブリックDNSとの名前解決の競合
特にmacOSやWindowsの最新バージョンでは、OS標準のマルチキャストDNS（mDNS）や「括られたネットワーク」でのDNSプライバシー機能（DoH/DoT）が暴走し、ローカルプロキシへのフォワーディングをバイパスしてしまうことがあります。
これを防ぐためには、OS側のDNS設定で特定のサーチドメイン（例: .internal.corp）に対するクエリを、確実にローカルループバックのプロキシへ向けるルーティング設定（macOSなら /etc/resolver/ の活用など）が必要です。
—
4. 実装例：Pythonとcurlによる検証・デバッグ手法
では、実際にアプリケーション層やCLIから、このZTNA環境およびプライベートDNS解決が正しく機能しているかを検証・デバッグするための実践的なコードとコマンドを見ていきましょう。
1. curlを用いたDNS名前解決の強制バイパスとルーティング確認
デバッグの基本は、｢どのDNSサーバーから、どのIPが引けているか｣を直接確認することです。dig コマンドや、カスタムDNSを指定できる curl のオプション（HTTP/3やDoH対応など）が強力な武器になります。
# ローカルのプライベートDNSプロキシ（例: 127.0.0.1:5353）に対して直接名前解決を問い合わせる
dig @127.0.0.1 -p 5353 api.internal.corp +short
# 【出力例】
# 10.100.50.20 ← しっかり社内プライベートIPが返ってきているか確認！
# curlで特定の名前解決結果を強制しつつ、APIの応答速度とTLSハンドシェイクを検証する
curl -iv --resolve api.internal.corp:443:10.100.50.20 https://api.internal.corp/v1/health2. Python (requests / httpx) によるAPIクライアントの実装とカスタムDNS解決
マイクロサービス環境のWeb APIクライアントをPythonで実装する際、環境によってDNS解決をモック化したり、特定のカスタムリゾルバを経由させたい場合があります。requests 単体では細かいDNS制御が難しいため、モダンな httpx や、ソケット通信をハックするアプローチが実務では重宝します。
以下は、カスタムDNSサーバーのIPを指定して名前解決を行いつつ、安全にAPIリクエストを投げるPythonスクリプトの例です。
import socket
import httpx
import dns.resolver # dnspython ライブラリを使用
# 設定パラメータ
TARGET_DOMAIN = "api.internal.corp"
TARGET_PORT = 443
# ZTNAクライアントが提供するローカルプロキシや社内DNSのIPを指定
PRIVATE_DNS_SERVER = "127.0.0.1"
PRIVATE_DNS_PORT = 5353
def resolve_via_private_dns(domain: str) -> str:
"""
プライベートDNSサーバーへ直接問い合わせを行い、
パブリックに漏洩しない内部IPアドレスを取得する関数
"""
resolver = dns.resolver.Resolver()
resolver.nameservers = [PRIVATE_DNS_SERVER]
resolver.port = PRIVATE_DNS_PORT
try:
# Aレコードの問い合わせを実行
answer = resolver.resolve(domain, 'A')
resolved_ip = answer[0].to_text()
print(f"[DEBUG] Successfully resolved {domain} -> {resolved_ip} via Private DNS.")
return resolved_ip
except Exception as e:
print(f"[ERROR] Failed to resolve {domain}: {e}")
raise
def call_internal_api():
"""
プライベートDNSで解決したIPを用いて、安全にAPIへリクエストを送信する
"""
try:
# 1. 名前の解決
target_ip = resolve_via_private_dns(TARGET_DOMAIN)
# 2. httpxのTransport層やクライアント設定を利用し、
# TLSのSNI（Server Name Indication）を維持したまま特定IPへリクエストを送る
# ※ ホストヘッダーにはドメイン名を正しく保持させることが重要です
url = f"https://{TARGET_DOMAIN}/v1/status"
# 実務での接続テスト用クライアント設定
# （検証環境でオレオレ証明書を許容する場合は verify=False もしくはカスタムCAを指定）
with httpx.Client(verify=True, timeout=5.0) as client:
# 内部的な名前解決のオーバーライドをシミュレートするため、
# ホスト名を維持しつつIPへ直接接続するカスタムトランスポートを設定することも可能です
response = client.get(
url,
# ホスト名とIPの紐付けを強制する場合のヘッダー・ルーティング調整
headers={"Host": TARGET_DOMAIN}
)
print(f"API Response Status: {response.status_code}")
print(f"API Response Body: {response.json()}")
except httpx.RequestError as exc:
print(f"An error occurred while requesting {exc.request.url!r}: {exc}")
if __name__ == "__main__":
call_internal_api()このコードのポイントは、dns.resolver を使って明示的にローカルのプライベートDNSプロキシにクエリを投げ、取得したプライベートIPをベースに通信を行っている点です。実務のコンテナ環境や特殊な踏み台サーバー（Bastion）構成において、DNSの向き先迷子を防ぐための定石パターンとなります。
—
おわりに：境界のない世界でエンジニアが持つべき「羅針盤」
VPNという分厚い城壁が取り払われ、私たちは「どこからでも繋がる、だが誰も無条件には信用されない」という美しい、しかし繊細なゼロトラストの荒野に立ちました。
その荒野でユーザーが迷子にならず、目的地のAPIや社内サーバーへスムーズにたどり着けるかどうかは、今回解説した「プライベートDNSプロキシ」という名の羅針盤が正しく機能しているかにかかっています。
「なんか社内APIに繋がらないんだけど？」というSlackのメンションに冷や汗をかく夜はもう終わりです。パケットの旅路とDNSの裏側の仕組みさえ頭に入っていれば、トラブルシューティングはただのパズルゲームに変わります。
さあ、明日からのインフラ設計やAPIクライアントの実装に、このプライベートDNSの視点を取り入れてみてください。あなたのネットワークは、より強靭で、そして何よりスマートなものに生まれ変わるはずです。
コメント