Azure Firewall DNS proxy: diagnose egress before opening rules

Incident
Workload: api-orders-prod
Subnet: spoke-prod/app-integration
Dependency: api.partner.example
Expected path: subnet -> UDR -> Azure Firewall -> Internet or private dependency
Expected DNS path: workload -> Azure Firewall DNS proxy or approved resolver -> upstream DNS
Expected rule: application rule on api.partner.example over HTTPS

Questions before change
Which resolver does the workload use at runtime?
Is Azure Firewall DNS proxy enabled and advertised to this subnet?
Does the UDR force traffic to the Firewall for the dependency IP?
Do Firewall logs show the expected FQDN or only an IP flow?
Which validation proves the dependency works without broadening egress?

FIREWALL_NAME="azfw-prod"
FIREWALL_RG="rg-network-prod"
POLICY_NAME="azfw-policy-prod"
POLICY_RG="rg-network-prod"

az network firewall show --name "$FIREWALL_NAME" --resource-group "$FIREWALL_RG" --query "{name:name,privateIp:ipConfigurations[0].privateIPAddress,dnsSettings:dnsSettings,firewallPolicy:firewallPolicy.id}" --output json

az network firewall policy show --name "$POLICY_NAME" --resource-group "$POLICY_RG" --query "{name:name,dnsSettings:dnsSettings,threatIntelMode:threatIntelMode}" --output json

az network firewall policy rule-collection-group list --policy-name "$POLICY_NAME" --resource-group "$POLICY_RG" --query "[].{name:name,priority:priority,provisioningState:provisioningState}" --output table

TARGET_FQDN="api.partner.example"
EXPECTED_FIREWALL_IP="10.40.0.4"

printf "Resolver configuration
"
cat /etc/resolv.conf || true

printf "Resolved addresses
"
getent hosts "$TARGET_FQDN" || nslookup "$TARGET_FQDN"

printf "Route selected toward resolved IP
"
TARGET_IP="$(getent hosts "$TARGET_FQDN" | awk '{print $1}' | head -1)"
ip route get "$TARGET_IP"

printf "TCP probe
"
timeout 5 bash -c "cat < /dev/null > /dev/tcp/$TARGET_FQDN/443"

let TargetFqdn = "api.partner.example";
let WindowStart = ago(2h);
AZFWApplicationRule
| where TimeGenerated > WindowStart
| where Fqdn has TargetFqdn or TargetUrl has TargetFqdn
| project TimeGenerated, SourceIp, Fqdn, TargetUrl, Action, RuleCollection, Rule, Protocol, DestinationPort, Policy
| order by TimeGenerated desc

let WorkloadPrefix = "10.42.";
let WindowStart = ago(2h);
AZFWNetworkRule
| where TimeGenerated > WindowStart
| where SourceIp startswith WorkloadPrefix
| project TimeGenerated, SourceIp, DestinationIp, DestinationPort, Action, RuleCollection, Rule, Protocol
| order by TimeGenerated desc

DNS proxy or resolver
The workload does not point to the expected DNS proxy
The internal resolver does not forward as intended
The FQDN resolves to different IPs depending on the subnet
Firewall logs do not contain the expected FQDN

Routing
The UDR does not cover the resolved prefix
A more specific route bypasses the Firewall
Return traffic follows an asymmetric path
The test succeeds from another subnet but fails from runtime

Firewall policy
The FQDN rule exists but in a lower-priority collection
Port or protocol does not match the real flow
A higher-priority deny rule catches the request
The effective FQDN is an alias, CDN name or different subdomain

Dependency or identity
The connection arrives but the API returns 401, 403 or 429
Certificate, SNI or expected hostname does not match
The partner changed IP, domain or rate-limit policy

before_change:
- capture_firewall_policy_and_dns_settings
- prove_runtime_resolver
- prove_effective_route_to_resolved_ip
- collect_application_and_firewall_logs

allowed_corrections:
- restore_dns_proxy_usage_for_subnet
- fix_forwarder_for_expected_domain
- add_exact_fqdn_application_rule
- adjust_rule_priority_with_evidence
- correct_udr_to_firewall_for_dependency_prefix

block_change_when:
- requested_rule_uses_wildcard_without_examples
- only_admin_workstation_test_passes
- rollback_state_is_missing
- firewall_logs_do_not_show_attempts_from_workload
- dependency_error_is_authentication_not_network

Accept change
Workload uses the approved resolver or Firewall DNS proxy
Resolved IP uses the expected UDR toward Azure Firewall
Firewall logs show the target FQDN and the intended rule
Application probe succeeds without wildcard or broad IP exception
Monitoring shows no new deny or timeout burst

Fix before opening more
Resolver differs between runtime and diagnostic host
FQDN is absent from application rule logs
Network rule logs show raw IP flows instead of expected FQDN traffic
Rule priority or protocol does not match the real request

Rollback
DNS proxy change breaks another spoke
UDR change redirects unrelated traffic
Wildcard or IP exception was added without evidence
Application still fails after the targeted correction
Previous resolver, route or rule state is known and restorable