Do not treat Azure Firewall's DNS server list as an ordered fallback chain

Source facts

When Azure Firewall has multiple custom DNS servers, Microsoft says it selects a server randomly. DNS proxy stops using a detected unhealthy server and uses another available one. If every configured server is unavailable, there is no additional DNS fallback.

While upstream servers remain unhealthy, the proxy performs health checks at five-second intervals using a recursive root-name-server query. Checks stop when an upstream is considered healthy and resume after a later error. Microsoft Learn.

Applicability

Inventory the firewall’s configured upstream addresses and the names each must resolve. For a Firewall Manager-managed instance, review the associated policy’s DNS settings as part of the configuration record.

DSE recommendation

DSE recommends treating the listed servers as a pool that must provide the intended answers, not as a preferred server followed by a special emergency resolver. Compare their forwarding and private-zone reachability with the application requirements. Define an operational response for loss of the entire pool instead of assuming the firewall will silently use an unlisted service.

Verification

In an approved test, query representative public and private names through the firewall and compare answers with each upstream. Exercise loss of one upstream and then the planned all-unavailable scenario within a safe test scope. Record observed resolution and recovery behavior. Confirm monitoring distinguishes upstream availability from whether the returned answer is correct for the requested application name.

Official references

Microsoft Learn: Azure Firewall policy DNS settings. Source retrieved September 9, 2026.