Azure Firewall DNS Proxy

運用前提: Portal上のresource stateだけでなく、対象5-tupleのeffective state・route・security logs・new connectionを組み合わせてdata planeを確認します。SKU/limit/preview statusは変更されるため、導入時は末尾のcurrent Microsoft Learnも再確認してください。

Azure Firewall DNS Proxyを理解するための前提

DNS proxyを有効にするとAzure Firewallがclient VMからDNS queryを受け、設定したupstream DNSへ代理問い合わせする。 Network ruleでFQDN filteringを使うにはDNS proxyを有効にし、client側もFirewall private IPをDNS serverとして使う構成が重要。

clientとFirewallが別々にDNS resolveするとCDN/round-robinの結果や時刻差で別IPを得て、FQDN ruleがunexpected denyになる。 positive DNS responseはTTLに従い最大1時間、negative responseは最大30分cacheされる。

FQDN network rule mappingはDNS resolutionに依存し、application ruleのSNI-based FQDN matchingとは別の仕組み。 custom upstream DNSを使う場合は複数resolverの可用性とFirewall→resolverの到達性を設計し、全upstream障害時のfail behaviorを確認する。

通信や判断の流れを追う

SourceRouteNSG / PolicyWorkloadResponse

Control plane と data plane

Control planecontrol planeではPolicy DNS proxy flag、custom DNS servers、parent/child inheritance、VNet/VM DNS settingsを管理する。

Data planedata planeではclient query→Firewall private IP:53→upstream resolver→cache/responseというDNS pathと、その結果を使ったFQDN network rule evaluationが連動する。

仕組み

clientがFirewall private IPへUDP/TCP 53でqueryする。

Firewall DNS proxyがcacheを確認し、必要ならupstream DNSへqueryする。

responseをclientへ返し、FQDN network rule用のIP mappingにも利用する。

clientがresolved IPへapplication connectionを開始する。

Network ruleがFirewallのFQDN→IP mappingに基づきAllow/Denyする。

Packet / decision path

障害時はresource一覧ではなく、同じsource/destination/port/protocolで各enforcement pointを順に追います。

DNS proxyをenableするだけで終えず、spoke VNet/VMのDNS serverをFirewallへ統一する。
upstream resolverを2系統以上で設計し、Firewallからのroute/NSGを確認する。
Private DNS Resolver/on-prem DNSとのforwarding loopを作らない。
DNS cache TTLとapplication retryをchange validationへ含める。
HTTP/SのFQDN filteringはApplication ruleを優先評価し、DNS-based network FQDNとの違いを理解する。

設計判断

判断点	推奨	理由
Client DNS	Firewall private IPをDNS serverとして配布。	client/Firewall resolution一致がFQDN Network ruleの前提。
Upstream	Azure DNSまたは冗長custom DNSを定義。	single resolver障害でegress全体を止めない。
Private DNS	Resolver/forwarderとの責務を分ける。	loop・split-horizon誤答を防ぐ。
Observability	DNS Proxy logsとNetwork Rule logsを相関。	名前解決失敗とpolicy denyを分離できる。

確認手順

Azure Portal / Network Watcher

Firewall Policy → DNS settingsでDNS proxyとcustom DNSを確認。
VNet → DNS serversでspokeがFirewall private IPを使うか確認し、VM再起動/renewが必要な変更影響を考慮。
Firewall logsでDNS proxy queryとnetwork rule hitを確認。

Verification discipline

subscription / resource group / resource ID / NIC / direction / 5-tupleを記録する。
同じ条件でbefore/afterを比較し、既存sessionとnew connectionを区別する。
configuration、effective state、logs、application resultを別々の証拠として残す。
変更成功はcontrol-plane Succeededではなくobservable data-plane behaviorで判定する。

Azure CLI — read-only first

az network firewall policy show -g <rg> -n <policy> -o jsonc
az network vnet show -g <rg> -n <vnet> -o jsonc
az monitor diagnostic-settings list --resource <firewall-resource-id> -o jsonc

PowerShell — read-only first

Get-AzFirewallPolicy -ResourceGroupName <rg> -Name <policy>
Get-AzVirtualNetwork -ResourceGroupName <rg> -Name <vnet>

障害切り分け

症状	疑う点	証拠	次の確認
FQDN ruleが時々deny	clientとFirewallのDNS不一致/CDN multi-IP	client nslookup + DNS proxy log + Firewall mapping	client DNSをFirewall proxyへ統一
全spokeで名前解決停止	upstream DNS障害/route/NSG	Firewall→resolver reachability	upstream冗長化とpath修正
Private Endpointだけpublic IPへ解決	split DNS/zone link/forwarding問題	client query resultとresolver path	Private DNS設計を修正
設定変更がすぐ反映されない	DNS cache/TTL	positive/negative cacheとquery timestamp	TTLを考慮してnew queryで検証

変更時の確認と rollback

変更前にPolicy DNS settings、VNet DNS servers、upstream resolver一覧を保存する。
rollback後はDNS cacheを考慮し、query→resolved IP→Firewall rule hitを一連で確認する。

Azure Firewall DNS Proxy