CDNやGeoDNSで最適な配信先を返すためにEDNS0 ECS（EDNS Client Subnet / RFC 7871）が使われます。しかし社内のActive Directory DNS（Windows DNS Server）をフォワーダーとして挟むと、ECSが上流へ渡らず期待した結果にならないことがあります。本記事では、挙動の考え方、検証方法、そして設計上の回避策を実務目線で整理します。
結論：Windows DNS ServerのフォワーダーにECS透過は期待しない
最初に結論から言うと、Windows DNS Server（Windows Server 2016以降を含む）をDNSフォワーダーとして動かした場合、クライアントが付与したECS（EDNS Client Subnet）オプションを上流へ「付けたまま転送する」挙動は期待しない方が安全です。
- 公式ドキュメントで「Windows DNSがECSを転送する／しない」が明確に断言されている一次情報は多くありません。
- 一方で、現場やコミュニティの報告としてクライアント→Windows DNSではECS付きで届くが、Windows DNS→上流への問い合わせではECSが消える（破棄される）というパケットキャプチャ結果が共有されています。
- 後年の追試コメントでも、同様にMicrosoft DNSがCSUBNET（ECS）を引き継がない現象を再現できた、という指摘があります。
このため、CDN/GeoDNS最適化など「ECS前提の名前解決」を成立させたい要件では、Windows DNSにECS透過を期待する構成を避けるのが実務的な落としどころになります。
「理解」と「転送」は別問題：ECS対応の意味を分解する
「Windows DNSはECSを理解しているのか？」という問いは、実は何をもって“理解”と呼ぶかで答えが変わります。ECSに関しては、少なくとも次の3段階に分けて考えると整理しやすいです。
| 段階 | 意味 | 実務上の見え方 |
|---|---|---|
| 受理できる | ECS付きの問い合わせをエラーにせず処理する | クライアント→Windows DNSの問い合わせが成立し、応答が返る（＝ECSがあっても拒否しない） |
| 解釈して使う | ECSを見て応答・キャッシュ・上流選択を変える | ECSの値を変えると、同じ名前でも返るIPが変わる／キャッシュが分かれる等の差が出る |
| 透過して転送する | クライアントが付けたECSを保持したまま上流へ問い合わせる | Windows DNS→上流のパケットにもECSが残る |
今回の論点はこのうち「透過して転送する」で、ここに関しては期待しない方が安全、というのが結論です。逆に言えば、クライアント→Windows DNSで問い合わせが成立するだけでは「ECSが効いている」とは言い切れないため、必ず上流へ出ていくパケットまで確認する必要があります。
そもそもECSとは何か：EDNS0の拡張オプション
ECS（EDNS Client Subnet）は、DNS問い合わせに「クライアントの属するネットワーク（サブネット）」の情報を付与して、権威DNSや上流リゾルバがより適切な応答（例：近いCDNのエッジ）を返せるようにする仕組みです。EDNS0のオプションとして定義されており、DNSパケット上はOPTレコード内のEDNS0 optionとして格納されます。
| ECSで渡される主な要素 | 意味 | 実務での注意点 |
|---|---|---|
| Address Family | IPv4/IPv6どちらのサブネットか | デュアルスタック環境では、どちらのECSが付いているかで結果が変わる場合があります。 |
| Source Prefix-Length | クライアント側サブネットのプレフィックス長（例：IPv4 /24） | 細かすぎるプレフィックスはプライバシー面で不利、粗すぎるとGeo最適化が効きません。 |
| Scope Prefix-Length | 応答が有効と見なされる範囲（キャッシュ制御に関係） | キャッシュの効き方に影響し、運用によってはキャッシュが分断されやすくなります。 |
| Client Subnet Address | クライアントサブネット（丸められたアドレス） | 「クライアントIPそのもの」ではなく、通常はサブネット単位で共有される情報です。 |
重要なのは、ECSは“DNSの仕組みそのもの”というより、CDNやGeoDNS、Anycastなどの最適化のために付加される追加情報である点です。ECSが付くかどうか、付くとしてどのプレフィックスで付くかは、ネットワーク設計・リゾルバ設計・プライバシーポリシーに強く依存します。
「フォワーダー＝そのまま転送」とは限らない：Windows DNSの役割を整理
「DNSフォワーダー」と聞くと、クライアントが送ったDNSパケットをそのまま上流へ流す“中継”を想像しがちです。しかし多くの環境でフォワーダーとして動いているのは、単なるUDPリレーではなく再帰リゾルバ（キャッシュDNS）です。再帰リゾルバは問い合わせを受け取ると、内部で状態管理・キャッシュ判定・問い合わせの再構成を行い、必要に応じて上流へ新しい問い合わせを作ります。
| 仕組み | 動作イメージ | クライアントのEDNS0/ECSを保持しやすいか | 典型的な用途 |
|---|---|---|---|
| 単純なUDP/TCPリレー（透過プロキシ） | パケットをほぼそのまま転送 | 保持しやすい（ただし実装次第） | ネットワーク機器の透過中継、特殊用途 |
| 再帰リゾルバ（キャッシュDNS）としてのフォワーダー | 問い合わせを終端し、必要なら新しい問い合わせを生成して上流へ | 保持されないことがある（むしろ保持しない実装も多い） | 社内DNS、AD統合DNS、社内の名前解決基盤 |
Windows DNS Serverは、Active Directory統合DNSとして使われることが多く、社内の名前解決の中核として再帰・キャッシュ・フォワードを担います。そのため、ECSのような“クライアント文脈”を上流へそのまま引き継ぐ設計にはなっていない（または積極的にやらない）可能性が高い、というのが現実的な見立てです。
起きやすい症状：CDN最適化が効かない・拠点ごとの差が出ない
ECSが上流へ渡らない場合、上流（パブリックDNSや権威DNS/CDN）が判断できるのは「問い合わせ元（リゾルバ）のIP」です。社内のWindows DNSが一箇所に集約されていると、全拠点のユーザーが同じ場所から来たように見えます。結果として、次のような症状が出やすくなります。
- 拠点Aと拠点Bで同じFQDNを引いても、返るIPが同じになり、距離の近いPoPに誘導されない。
- 海外拠点ユーザーが、国内向けのCDNエッジに誘導されて遅延が増える。
- アプリ側は正常でも「DNSだけが遅い」「初回接続だけ遅い」など体感の問題として顕在化する。
- CDN事業者のログ上、クライアントではなくWindows DNSの送信元IPにアクセスが集約され、分析が歪む。
検証方法：ECSが“どこで消えるか”をパケットで確認する
公式に断言されている資料が少ない領域ほど、実務では手元の環境で再現・可視化して判断するのが確実です。ここでは「クライアント→Windows DNS→上流」のどの区間でECSが消えるかを確認するための、現実的な手順をまとめます。
検証に必要なもの
- ECSを付けて問い合わせできるツール（例：
dig、kdigなど） - パケットキャプチャ環境（Wireshark、tcpdump等）
- 検証用の名前（CDN配下のドメインなど、ECSの有無で応答差が出やすいもの）
Windows標準のnslookupやPowerShellのResolve-DnsNameは、クライアント側から任意のECSを付ける用途には向きません。検証では、ECSを明示的に付与できるツールを使うのがポイントです。
ステップ1：クライアントからWindows DNSへECS付きで問い合わせる
例として、ECSを明示してAレコードを問い合わせるケースを示します（書き方はツールにより差があります）。
dig @<Windows_DNSのIP> example.cdn-domain.test A +subnet=203.0.113.0/24この時点で、クライアント側キャプチャ（またはWindows DNSサーバーの受信側キャプチャ）にて、DNSパケット内にOPTレコード → EDNS0 option → Client Subnetが見えることを確認します。
ステップ2：Windows DNSから上流への問い合わせをキャプチャする
次に、Windows DNSサーバーから上流（フォワーダー先）へ出ていくDNS問い合わせをキャプチャします。見るべきポイントは次の通りです。
- 上流へ出ていく問い合わせにOPTレコードが付いているか
- OPTレコードが付いている場合、EDNS0 optionとしてClient Subnetが含まれているか
- 含まれていない場合、クライアント→Windows DNSでは見えていたECSが、上流問い合わせでは落ちている（破棄されている）
ステップ3：結果を表にまとめて判断する
| 観測ポイント | 見えるはずのもの | 解釈 |
|---|---|---|
| クライアント→Windows DNS | ECS optionあり | クライアントはECSを付けて送れている。 |
| Windows DNS→上流 | ECS optionなし | Windows DNSがECSを引き継がず、上流へは通常の問い合わせを生成している可能性が高い。 |
| Windows DNS→上流 | ECS optionあり | （もし見えた場合）構成やバージョン依存で透過している可能性。再現条件の整理が必要。 |
「ECSが見える／見えない」は、キャプチャの場所を間違えると誤判定します。必ず“Windows DNSから外へ出ていく側”を押さえることが大切です。
なぜECSが転送されないのか：技術的に起こり得る理由
Windows DNSの内部実装を断定することはできませんが、一般論として「ECSがそのまま上流へ渡らない」理由は複数考えられます。どれか1つというより、設計上の判断として複合的に起きます。
- 再帰リゾルバは問い合わせを再構成する：クライアントのパケットを“転送”するのではなく、必要な情報だけで新しい問い合わせを作るため、EDNS0オプションをコピーしない実装は珍しくありません。
- プライバシーと情報漏えいの懸念：ECSはクライアントのネットワーク情報を上流へ渡します。組織ポリシーによっては、意図せず外部へ内部ネットワークの形を漏らすことになります。
- キャッシュ効率の悪化：ECSは“サブネットごとに違う答え”を引き起こしやすく、キャッシュが細分化されます。基盤DNSとしては性能・安定性の観点で好まれない場合があります。
- 上流との互換性リスク：ECSに限らず、EDNS0は機器や経路上の不具合により応答が欠落するケースがあり、安定性を優先してオプションを控えめにする実装もあります。
混同注意：「DNSポリシーのClient Subnet」と「EDNS Client Subnet」は別物
Windows Server 2016以降のWindows DNSには、DNSポリシー等の機能で「クライアントサブネット」を条件に応答を変える設計が可能です。ここで言う「クライアントサブネット」は、EDNS0 ECS（RFC 7871）とは別物として理解しておくと混乱が減ります。
| 項目 | Windows DNSのDNSポリシー（Client Subnet） | EDNS0 ECS（EDNS Client Subnet / RFC 7871） |
|---|---|---|
| どこで使うか | 主に権威応答や条件付き応答（Windows DNSが答えを返す側） | 再帰問い合わせ時に上流へ“クライアント文脈”を伝える |
| 判定材料 | 問い合わせ元IP（Windows DNSが見えるクライアントIP） | DNSパケット内のEDNS0オプション（Client Subnet） |
| 目的 | 拠点・ネットワークごとに異なるレコードを返す等 | CDN/GeoDNSが近い配信先を返す等 |
| 今回の論点 | Windows DNS自身が返答を作る話 | Windows DNSが上流へECSを“引き継ぐか”の話 |
「Windows DNSにClient Subnetという機能がある＝ECSを転送できるはず」という推測は成り立ちません。機能の層が違います。
実務的な対処：ECS前提の構成を避ける設計パターン
要件が「ECSによる最適化を効かせたい」なら、Windows DNSを経由させる構成そのものを見直すのが近道です。ここでは実務で採りやすい代替案を3つに整理します。
ECSを転送できるキャッシュDNS（リゾルバ）を別途用意する
最もシンプルなのは、ECSを扱えるキャッシュDNSを別に立て、クライアントがそこへ問い合わせる構成です。Windows DNSはAD統合DNSとして内部ゾーン（社内ドメイン）に集中し、外向けの名前解決は別リゾルバに役割分担します。
- クライアントのDNSサーバー設定を、内部向け・外部向けで分ける（もしくはDHCPで拠点ごとに配布先を変える）
- 外部向けリゾルバ側でECSの付与・転送方針（プレフィックス長、送出先ドメインの限定など）を制御する
このパターンのメリットは、Windows DNSの制約に引きずられないことと、ECSに伴うポリシー（どこまでクライアント情報を外部へ渡すか）を明示的に決められることです。
拠点ごとにリゾルバを置き、「送信元（リゾルバ所在地）」で最適化させる
ECSは便利ですが、そもそもGeoDNS/CDNが参照できる情報はECSだけではありません。拠点ごとにリゾルバを設置し、上流から見える送信元IPが拠点の地理情報に近くなるようにすると、ECSがなくても一定の最適化が働きます。
- 拠点Aのクライアントは拠点Aのリゾルバへ
- 拠点Bのクライアントは拠点Bのリゾルバへ
この方式はプライバシー面でも扱いやすい一方で、拠点数が多いと運用負荷が上がります。リゾルバを冗長化するか、WAN断時の動作をどうするかも設計対象です。
上流（DNSサービス／ロードバランサ）側をECS非依存に見直す
「どうしてもWindows DNSを中核にしたい」「クライアント設定を変えられない」といった制約がある場合は、上流側の設計を変える選択肢もあります。
- DNSではなくHTTPレイヤのGSLB/ロードバランスで最適化する（アプリ側で近いエンドポイントへ誘導）
- 権威DNS側をAnycast化し、問い合わせ元（リゾルバ）に近い拠点へ自然に到達するようにする
- 拠点ごとに別FQDNを使う、またはSplit-horizonで内部からは固定の経路に寄せる
ECSに頼らない設計にすると、DNS基盤が変わっても影響が小さくなり、将来の移行や統合が楽になる傾向があります。
対処方針の選び方：要件別の判断表
| 要件 | おすすめ方針 | 理由 | 注意点 |
|---|---|---|---|
| 拠点差でCDN最適化を強く効かせたい | ECS対応リゾルバを別に用意し、外部解決を分離 | ECSの送出ポリシーを制御でき、Windows DNSの制約を回避できる | クライアント設定（DHCP配布含む）の設計が必要 |
| 拠点数が少なく、安定運用を優先したい | 拠点ごとにローカルリゾルバを配置 | ECSなしでも送信元IPベースで最適化が働きやすい | 冗長化・監視・更新の運用が必要 |
| 社内DNSを極力シンプルにしたい | ECS非依存の上流設計（Anycast/HTTP最適化等） | DNS基盤の差異に左右されにくい | 上流やアプリ側の変更コストが発生 |
運用でハマりやすいポイント
「一部だけ遅い」「特定拠点だけ遅い」はDNSが原因のことがある
ECSを期待しているのに効かない場合、アプリケーションログでは原因が見えにくく、ネットワーク遅延やサーバー性能の問題に見えてしまうことがあります。拠点ごとの差、回線経路の違い、初回接続だけ遅いといった症状があるときは、DNS応答（返ってきたIP）と接続先PoPの違いを突き合わせると原因が見えます。
キャッシュのせいで「たまに正しい」「たまに違う」ように見える
DNSはキャッシュが強い仕組みです。検証時にキャッシュが残っていると、ECSの有無に関係なく同じ応答が返り続けることがあります。検証では次の点を意識すると切り分けが楽になります。
- 短いTTLのドメインを使う、またはキャッシュを明示的にクリアしてから試験する
- Windows DNS側・上流側の双方でキャッシュ状況を考慮する
- 複数回の問い合わせで結果がブレる場合は、キャッシュヒット／ミスの差を疑う
セキュリティ・コンプライアンス面の確認を忘れない
ECSは便利ですが、クライアントのネットワーク情報を外部へ渡す性質上、情報管理の観点で扱いが難しくなることがあります。ECS対応リゾルバを採用する場合でも、少なくとも次は事前に決めておくと安全です。
- どの宛先（ドメイン／上流）に対してECSを付けるのか（全てに付けない）
- IPv4/IPv6それぞれのプレフィックス長をどうするか
- ログや監査上、ECS付き問い合わせをどう扱うか
Windows DNSを使い続ける場合の現実的な落とし所
Active Directory環境では、Windows DNSは「内部の名前解決」「AD関連レコード」「動的更新」などの理由で手放しにくい存在です。だからこそ、設計を次のように割り切ると運用が安定します。
- Windows DNS：社内ゾーンの権威DNS＋社内向け解決の中核
- 外部向け最適化：ECS対応リゾルバ／拠点リゾルバ／上流設計変更で実現
「何でもWindows DNSでやる」より、役割分担の方が設計自由度と可観測性が上がります。特にCDN最適化のように、DNSがアプリ体感に直結する領域では効果的です。
まとめ
Windows DNS Serverをフォワーダーとして挟んだ構成では、EDNS0のECS（EDNS Client Subnet）を上流へそのまま引き継ぐ動作は期待しない方が安全です。ECS前提のGeoDNS/CDN最適化を成立させたい場合は、ECS対応リゾルバの導入や拠点ごとのリゾルバ配置、あるいは上流設計の見直しなど、Windows DNSの外側で要件を満たす方向に寄せると失敗しにくくなります。最終的には、パケットキャプチャで「どこでECSが消えるか」を押さえ、要件とポリシー（プライバシー/運用）をセットで決めるのが近道です。
コメント