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

> Review random upstream selection and the absence of an extra fallback when every configured DNS server is unavailable.

- Canonical URL: https://update.dsesecurity.com/updates/dse-20260909-251-do-not-treat-azure-firewall-s-dns-server-list-as-an-ordered-fallback-chain/
- Publisher: Detection Systems & Engineering (DSE Security)
- Author: DSE Security Editorial Team
- Published: 2026-09-10T00:27:45+00:00
- Modified: 2026-09-10T01:23:48+00:00
- Last reviewed by DSE: 2026-09-09
- Resource type: Guide
- DSE priority: Information
- Topics: Cybersecurity, Networks & Infrastructure
- Reading time: 2 minutes

## What you need to know

Review random upstream selection and the absence of an extra fallback when every configured DNS server is unavailable.

## Potentially affected

Azure Firewall DNS proxy deployments using multiple custom upstream DNS servers.

## DSE recommendation

Validate consistent answers and reachable failure paths across the configured DNS pool, without assuming list-order preference or an unconfigured fallback.

## Article

## 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](https://learn.microsoft.com/en-us/azure/firewall-manager/dns-settings).

## 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](https://learn.microsoft.com/en-us/azure/firewall-manager/dns-settings). Source retrieved September 9, 2026.

## Primary reference

- Name: Azure Firewall policy DNS settings | Microsoft Learn
- Authority: Microsoft Learn
- URL: https://learn.microsoft.com/en-us/azure/firewall-manager/dns-settings
- Source publication date: Not stated by the source

## Citation and use

Preferred citation: “Do not treat Azure Firewall's DNS server list as an ordered fallback chain,” DSE Security, https://update.dsesecurity.com/updates/dse-20260909-251-do-not-treat-azure-firewall-s-dns-server-list-as-an-ordered-fallback-chain/
Publishing principles: https://update.dsesecurity.com/updates/dse-updates-editorial-methodology/
Usage and citation policy: https://update.dsesecurity.com/usage/
Copyright © 2026 Detection Systems & Engineering. All rights reserved.