Azure hub and spoke, Firewall with DNS proxy using default DNS

Question

Azure hub and spoke, Firewall with DNS proxy using default DNS

Andrea Pasquino 60

Hello,

we have this setting:

Azure hub and spoke, Firewall with DNS proxy using default DNS, spoke vnets that point to the Firewall ip.

We have private dns zones with virtual network links to the hub.

We have private dns resolver with indbound and outbound endpoint, and a dns forwaring policy with virtual network links to the hub.

DNS resolution for all scenarios (public, private, hybrid) work perfectly.

Is there any good reason to set the firewall dns proxy to the ip of the inbound endpoint of the dns private resolver ?

Best Regards

Andrea

0 comments

Answer accepted by question author

SHOUMIK CHAKRAVARTY 910

Not in the setup you described. Pointing the firewall's DNS proxy at the inbound endpoint would not add anything, and the reason is in the resolver's documented resolution order.

The Azure DNS Private Resolver overview sets out the chain a client in the virtual network already follows:

"If you configure Default (Azure-provided) DNS servers in the virtual network, and there are Private DNS zones linked to the same virtual network, these zones are consulted. If the query doesn't match a Private DNS zone linked to the virtual network, then Virtual network links for DNS forwarding rulesets are consulted. ... If ruleset links are present, the DNS forwarding rules are evaluated. If a suffix match is found, the query is forwarded to the specified address."

Your firewall is simply another DNS client in the hub, so it already walks that chain: hub-linked private zones, then the ruleset linked to the hub, then Azure DNS. The resolver's policy is in the path already. Sending queries to the inbound endpoint would reach the same rules by a longer route. As the same page puts it, "You don't need to change any DNS client settings on your virtual machines (VMs) to use the Azure DNS Private Resolver."

That also explains why hybrid works with no custom DNS server anywhere, and why only the hub's links matter. Since every spoke sends DNS to the firewall in the hub, you do not need to link each spoke separately.

Worth being clear on what the inbound endpoint is for, since it is easy to assume it belongs here. It is the entry point for queries originating outside Azure: "To resolve your Azure private DNS zone from on-premises, enter the IP address of the inbound endpoint into your on-premises DNS conditional forwarder." Your firewall is going the other way, which is the outbound endpoint and ruleset, already covered.

Help make this community better for everyone: if this answer resolved your issue, please accept it or leave an upvote. If not, share more details in a comment so we can continue the discussion and find the right solution.

0 comments

1 additional answer

Your answer

Answer 1

Not if the current design already resolves public, private, and hybrid names correctly.

A good reason to point Azure Firewall DNS proxy to the Azure DNS Private Resolver inbound endpoint is when Azure Firewall must remain the DNS server for workloads, but DNS queries also need centralized handling by Private Resolver for scenarios such as forwarding specific domains to on-premises DNS. In that model, workloads send DNS to the firewall, and the firewall forwards upstream queries to the resolver inbound endpoint.

In the described design, the main reasons to keep Azure Firewall DNS proxy enabled are:

FQDN filtering in network rules: Azure Firewall requires DNS proxy to be enabled, and client virtual machines must use the firewall as their DNS server for consistent FQDN resolution.
Consistent DNS resolution: If clients do not use the firewall as DNS proxy, the firewall and clients can resolve names differently.
DNS logging: Routing DNS through Azure Firewall provides DNS request logging coverage.

If those goals are already met and name resolution is already working for public, private, and hybrid scenarios, there is no documented requirement to change the firewall’s upstream DNS from default Azure-provided DNS to the Private Resolver inbound endpoint.

A practical reason to change it would be to make the firewall forward DNS queries to Private Resolver so that conditional forwarding and centralized resolver logic are applied behind the firewall. That pattern is also reflected in Microsoft Q&A guidance for hybrid/on-premises name resolution when workloads must continue using Azure Firewall as DNS proxy.

One important caveat: if Azure Firewall uses a custom DNS server, that IP must be from the virtual network and must not be part of the Azure Firewall subnet.

References: