Windows Server 2016 の DNS Policy で -Fqdn 条件を設定したのに「全然マッチせず、Get-DnsServerQueryResolutionPolicy でも Fqdn が空っぽ」という現象は、実は “書き方の仕様” と “DNS Policy の仕組み” をきちんと押さえておかないとハマりやすいポイントです。本記事では、特に www.www.www.xxx.contosso.com のような名前だけを無応答（IGNORE）にしたいケースを題材に、-Fqdn が効かない理由と、現実的かつ再現性の高い構成例を分かりやすく解説します。
Windows Server 2016 DNS Policy の「-Fqdn」が効かない現象とは
まず、よくある相談内容を整理します。
- 目的：DNS Query Resolution Policy の
-Fqdn条件を使い、www.www.www.xxx.contosso.comのような問い合わせを 無応答（IGNORE） にしたい。 - 現象：
-Fqdnにどんな値を入れてもポリシーがマッチせず、DNS は常に NXDOMAIN で応答する。Get-DnsServerQueryResolutionPolicyで確認しても、Fqdn 条件が Criteria に表示されない／空 に見える。- ゾーンレベル（
-ZoneName指定あり）・サーバーレベルの両方で試しても結果は同じ。
- テストしている名前の例：
www.www.www.test.contosso.comWwW.WwW.WwW.ssl.contosso.comwww.www.www.123.123.123.123.contosso.com
多くの場合、原因は次の 2 点に集約されます。
-Fqdnの書式（特にワイルドカード）が DNS Policy の仕様から外れている。- DNS Policy の評価順やアクション（IGNORE / DENY / ALLOW）の理解があいまいで、狙ったタイミングでポリシーが当たっていない。
ここからは、仕様の整理と具体的な設定例を交えながら、一つずつ解きほぐしていきます。
DNS Query Resolution Policy の基本仕様をおさらい
ポリシーの構成要素と評価順
DNS Query Resolution Policy は大きく以下の 3 要素で構成されています。
| 要素 | 意味 | 代表的な例 |
|---|---|---|
| Criteria（条件） | クエリ送信元サブネット、サーバー IF、FQDN、QType、TimeOfDay などの組み合わせ | -Fqdn "EQ,*.contoso.com" / -ClientSubnet "EQ,OfficeA" |
| Action（アクション） | 一致したときにどう振る舞うか | ALLOW / DENY / IGNORE |
| Scope（スコープ） | ゾーンスコープ・キャッシュスコープ・再帰スコープなど | Split DNS やロードバランシングなどの高度な構成で使用 |
評価順は以下の通りです。
- サーバーレベル ポリシー（すべてのゾーンに対して最初に評価）
- ゾーンレベル ポリシー（該当ゾーンでのみ評価）
- 再帰ポリシー（権威応答では解決できず、再帰が必要になった場合に評価）
加えて、同じレベル（サーバー or ゾーン）の中では -ProcessingOrder が小さいポリシーから順に判定されます。
Action：ALLOW / DENY / IGNORE の違い
| Action | 挙動 | クライアント側から見える応答 | 主な用途 |
|---|---|---|---|
| ALLOW | 条件に一致したクエリを許可し、指定スコープで解決 | 通常の DNS 応答 | Split DNS、負荷分散、特定クライアントだけ別 IP を返す、など |
| DENY | クエリを拒否 | 通常は REFUSED | 「問い合わせ自体禁止」を明示したい場合 |
| IGNORE | クエリを黙って捨てる | タイムアウト（応答なし） | 悪性ドメインのブラックホール化・フィルタリング |
Microsoft の公式ドキュメントでも、悪性ドメインのブロック例として、サーバーレベルで -Action IGNORE を用いたポリシーが紹介されています。
-Fqdn 条件の仕様とワイルドカードの正しい使い方
FQDN 条件は「EQ / NE + 値の列挙」
-Fqdn で指定する条件は、DNS Policy Criteria の一種として定義されており、形式は以下のようになっています。
- 基本形式：
EQ,値1,値2; NE,値3,値4のような文字列 EQ：一致したら真（OR 条件で評価）NE：一致しなかったら真（AND 条件で評価）
FQDN の場合は「クエリ名（QName）」に対して評価されます。例えば、
-Fqdn "EQ,host1.contosso.com"… クエリ名がhost1.contosso.comのときだけ一致-Fqdn "EQ,*.contosso.com"…contosso.com配下すべて（contosso.com自身も含む）に一致-Fqdn "EQ,*.contosso.com,*.woodgrove.com"… 2 ドメインのどちらかの配下なら一致
このように、EQ の後ろに並べた FQDN は 「いずれかに一致すれば OK」 という OR 条件になります。
なお、DNS 名は仕様上 大文字小文字を区別しない ため、www / WwW のような表記ゆれは気にしなくて構いません。
ワイルドカードは「先頭 *」によるサフィックス一致が前提
FQDN 条件はワイルドカードをサポートしますが、公式ドキュメントに挙がっている例はいずれも 先頭に *. を付けたサフィックス一致 です。
EQ,*.contoso.com…contoso.com配下すべてEQ,*.contoso.com,*.woodgrove.com… 2 つのドメイン配下すべて
一方で、次のような表現は 仕様上まったく言及がなく、実装も保証されていません。
EQ,*.www.www.www.*EQ,*www.*.contosso.comEQ,*.contosso.*
プロトコル仕様では、FQDN 条件が解釈不能な場合は DNS_ERROR_POLICY_INVALID_CRITERIA_FQDN (9994) が返される と定義されています。 実際の Windows Server 2016 では、エラーとしてはねられるケースもあれば、ポリシー自体は作成されるものの Criteria 内に FQDN が保存されず、結果的に FQDN 条件が「無い」ポリシーとして動いてしまうケースも報告されています。
そのため、www.www.www.xxx.contosso.com のような「途中に特徴がある名前」を FQDN パターンだけで表現するのは現実的ではありません。DNS Policy の設計自体を少し変えるのが堅実です。
Get-DnsServerQueryResolutionPolicy で Fqdn が空に見える理由
Get-DnsServerQueryResolutionPolicy をそのまま叩くと、Criteria フィールドにどの条件が載っているかが簡易表示されます。
Get-DnsServerQueryResolutionPolicy -ZoneName "contosso.com" | Format-List *
ここで Fqdn を含む Criteria が表示されない場合、主に次の可能性があります。
-Fqdnで指定した文字列が仕様に沿っておらず、内部的に無視されている。- そもそもゾーンレベルではなくサーバーレベルで作ったポリシーを見ている。
- 別名で作成したポリシーを見ている（
-Nameの指定ミス）。
特に「EQ,*.www.www.www.*」のようなワイルドカード多用パターンは、前述の通り仕様上保証されていないため、ポリシー作成時に Fqdn 条件として解釈されていない可能性が高いと考えられます。
「www.www.www.*.contosso.com だけ無応答」にする現実解：子ゾーン方式
DNS Policy の -Fqdn だけで「途中に www.www.www を含む名前」を指定しようとすると、どうしてもワイルドカードの仕様とぶつかります。そこでおすすめなのが、www.www.www.contosso.com を子ゾーンとして切り出し、ゾーン単位で IGNORE する構成です。
手順 1：子ゾーン www.www.www.contosso.com を作成
まず、既存の contosso.com ゾーンの下に、www.www.www.contosso.com という子ゾーンを作成します。
PowerShell
Add-DnsServerPrimaryZone `
-Name "www.www.www.contosso.com" `
-ReplicationScope "Domain"
- AD 統合 DNS の場合、
-ReplicationScopeは環境に合わせてForest/Domain等を選択してください。 - スタブ／セカンダリにする必要はありません。単純なプライマリ ゾーンで構いません。
この時点で、
www.www.www.test.contosso.comwww.www.www.ssl.contosso.comwww.www.www.123.123.123.123.contosso.com
といった名前は、いずれも www.www.www.contosso.com ゾーンの配下として解決されるようになります。
手順 2：子ゾーン配下はすべて IGNORE にするゾーンレベルポリシー
次に、この子ゾーンに対して、すべてのクエリを IGNORE するゾーンレベルポリシーを作成します。
PowerShell
Add-DnsServerQueryResolutionPolicy `
-ZoneName "www.www.www.contosso.com" `
-Name "DropAllUnderWWW3" `
-Action IGNORE
このポリシーは FQDN 条件をあえて指定していないため、ゾーン配下のすべてのクエリが IGNORE の対象になります。
- クライアントから見ると、クエリはタイムアウトし、NXDOMAIN すら返りません。
- サーバーは
www.www.www.contosso.comゾーン配下のレコードを一切返さない「ブラックホール」として振る舞います。
これは Microsoft が示している「悪性ドメインを IGNORE でブラックホール化する」例と同じ考え方を、子ゾーンに限定して適用したものです。
検証手順：キャッシュクリアと nslookup
設定後は、必ず DNS キャッシュをクリアしてから動作確認を行いましょう。
PowerShell
# サーバー側キャッシュを削除
Clear-DnsServerCache -Force
その上で、クライアントまたは DNS サーバー自身から nslookup でテストします。
nslookup www.www.www.test.contosso.com <DNSサーバーのIP>
- 期待される結果：応答が返らず、クライアント側でタイムアウト（IGNORE）。
- もし NXDOMAIN が返る場合は、まだポリシーが評価される前に通常の名前解決経路が働いているか、別のキャッシュが残っている可能性があります。
DNS サーバー側での一般的なトラブルシューティング（イベントログの確認、ゾーンの状態確認など）は、公式の「Troubleshooting DNS Servers」ドキュメントの手順も参考になります。
ドメイン全体をサーバーレベルでブラックホール化する例
「contosso.com 配下は全部落として構わない」という要件であれば、子ゾーン方式ではなく サーバーレベル ポリシー + FQDN 条件 でシンプルに実現できます。
PowerShell
Add-DnsServerQueryResolutionPolicy `
-Name "BlockAllContosso" `
-Action IGNORE `
-Fqdn "EQ,*.contosso.com"
これは Microsoft の公式ドキュメントにある「悪性ドメイン contosomalicious.com をサーバーレベルでブロックする例」とほぼ同じ構成です。
contosso.com自体も含めて、ドメイン配下すべてのクエリが IGNORE になります。- 正規の内部サービスまで巻き込んでしまうため、実環境で使う場合は非常に慎重な設計が必要です。
ゾーンレベルではなくサーバーレベルにしている点も重要です。サーバーレベル ポリシーは すべてのゾーンより先に評価されるため、NXDOMAIN を返す既存レコードやフォワーダーの前に「ブラックホール」が挟まる形になります。
つまずきやすいポイントとチェックリスト
ここでは、実務でよくハマるポイントをチェックリスト形式で整理します。
| チェック項目 | よくある落とし穴 | 確認・対処のポイント |
|---|---|---|
| ドメイン名のスペル | contoso と contosso など、1 文字違い | ゾーン名、-Fqdn、nslookup のクエリ名が完全一致しているか確認 |
| ゾーンレベル / サーバーレベル | ゾーンレベルで作ったのに、サーバーレベルで確認している | -ZoneName あり・なしで Get-DnsServerQueryResolutionPolicy を実行する |
| ProcessingOrder | ブロックポリシーの優先度が低く、別ポリシーに先にマッチしている | ブロック系は -ProcessingOrder 1 など先頭に持ってくる |
| ワイルドカード | *.www.www.www.* のような非標準パターン | EQ,*.domain.com のようなサフィックス表現に整理するか、子ゾーン方式を検討する |
| キャッシュ | ポリシー変更後も以前のキャッシュで判定している | Clear-DnsServerCache -Force、クライアント側も ipconfig /flushdns などでクリア |
| 再帰ポリシー | 再帰用ポリシー（-ApplyOnRecursion）と混同 | 権威応答を落とすだけなら通常は再帰ポリシー不要。QueryProcessing レベルで設計する |
-Fqdn 以外の条件を組み合わせて「足切り」する応用例
FQDN 条件だけで複雑なパターンを表現しようとすると限界がありますが、DNS Policy では他にも以下のような条件を組み合わせることができます。
- ClientSubnet（クライアントサブネット）
- ServerInterfaceIP（DNS サーバーの受信インターフェイス）
- QType（A / AAAA / SRV / TXT などのレコード種別）
- TimeOfDay（クエリを受信した時間帯）
例えば、「社外から来る *.contosso.com の問い合わせだけ IGNORE にしたい」といった場合は、次のような手順が考えられます。
PowerShell
# 例：外部サブネットを定義
Add-DnsServerClientSubnet -Name "ExternalNet" -IPv4Subnet "203.0.113.0/24"
# 例：外部サブネットからの *.contosso.com クエリは IGNORE
Add-DnsServerQueryResolutionPolicy `
-Name "DropContossoFromExternal" `
-Action IGNORE `
-ClientSubnet "EQ,ExternalNet" `
-Fqdn "EQ,*.contosso.com"
このように、FQDN だけで頑張るのではなく、「誰から」「どの IF に」「どの種類のレコードを」問い合わせているかも条件に加えることで、運用上の要件に沿った柔軟なフィルタを作れます。
運用面でのベストプラクティス
ポリシーの確認テンプレート
ポリシーを作成したら、次のコマンドをワンセットで実行しておくと、あとから状況を追いやすくなります。
PowerShell
# サーバーレベル
Get-DnsServerQueryResolutionPolicy | `
Select-Object Name,Level,ProcessingOrder,Action,Criteria
# ゾーンレベル（例：contosso.com）
Get-DnsServerQueryResolutionPolicy -ZoneName "contosso.com" | `
Select-Object Name,Level,ProcessingOrder,Action,Criteria
# 子ゾーン（例：www.www.www.contosso.com）
Get-DnsServerQueryResolutionPolicy -ZoneName "www.www.www.contosso.com" | `
Select-Object Name,Level,ProcessingOrder,Action,Criteria
Criteria カラムに Fqdn 条件がきちんと載っているか、ProcessingOrder の並びが意図通りかを定期的に確認しておきましょう。
ログとデバッグの活用
ポリシーが効かないときは、DNS サーバーのイベントログ（DNS Server ログ）や、必要に応じてデバッグログを有効化して、クエリがどのように処理されているかを追うのが有効です。
- クエリがそもそも DNS サーバーに届いていないのか
- ポリシーにマッチしているのか、していないのか
- 再帰まで到達しているのか
を切り分けることで、「ポリシーの書き方の問題」なのか「ネットワーク／ゾーン構成の問題」なのかを判断しやすくなります。
Windows Server 2016 を使い続ける場合の注意点とアップグレード検討
DNS Policy 機能自体は Windows Server 2016 で導入されたもので、その後の 2019 / 2022 / 2025 でも継続してサポートされています。 一方で、実装の完成度やドキュメントの充実度は新しいバージョンほど高く、特に FQDN 条件まわりの癖やバグ修正はバージョンによって挙動が異なる可能性があります。
今回のように DNS Policy を積極的に活用したい環境では、
- DNS Policy に関する既知の不具合や修正 KB の有無を確認する
- 将来的な機能拡張（split DNS、高度なトラフィックマネジメントなど）を見据えて、より新しい Windows Server バージョンへの移行を計画する
といった観点も踏まえ、長期運用の計画を立てておくと安心です。
まとめ：-Fqdn でハマったら「書式」と「設計」を見直す
最後に、本記事の要点を整理します。
-Fqdn条件はEQ/NE+ FQDN の列挙 で指定し、ワイルドカードは 先頭*.によるサフィックス一致 が前提。EQ,*.www.www.www.*のような複雑なワイルドカードは仕様外で、Fqdn 条件が保存されない／マッチしない原因になりやすい。- 「
www.www.www.*.contosso.comだけ無応答にしたい」ようなケースでは、子ゾーンwww.www.www.contosso.comを作成し、ゾーンレベルポリシーで IGNORE する構成が再現性も高く扱いやすい。 - ドメイン全体を落とす必要がある場合は、
-Fqdn "EQ,*.contosso.com"のように、サーバーレベルポリシーでブラックホール化するパターンも利用できる。 - うまく動かないときは、ProcessingOrder・ゾーン／サーバーレベル・キャッシュ・ワイルドカードの書き方を一つずつチェックし、必要に応じてログやデバッグ機能を活用する。
-Fqdn は一見シンプルに見えますが、DNS Policy の評価順やワイルドカード仕様とセットで理解しておかないとハマりやすいポイントです。子ゾーン方式や他の条件（ClientSubnet など）も組み合わせながら、自組織の要件に合わせた現実的な DNS フィルタリング設計に役立ててください。
コメント