Mastering Azure DNS Solutions - Part 5 - Azure Firewall DNS Proxy

Using Azure Firewall as a DNS Proxy

DNS is often called the “first step of every network connection.”
Because of that, DNS traffic represents a critical opportunity to secure, monitor, and control communications across your cloud infrastructure.

Azure Firewall can act as a DNS Proxy, giving you centralized DNS visibility, policy enforcement, and logging — without relying on external appliances or custom scripts.

In this blog, we’ll explore:

  • What it means to use Azure Firewall as a DNS Proxy
  • Why it’s beneficial
  • How it fits into typical architectures (with a diagram)
  • How to configure it via the Azure Portal and Bicep
  • Security tips and best practices

What is Azure Firewall DNS Proxy?

When you enable DNS Proxy on Azure Firewall, the firewall intercepts DNS queries from your Azure resources, forwards them to your designated DNS server (private or public), and returns the responses.

This offers a powerful point of inspection, logging, and control over all DNS traffic.

Benefits of Using Azure Firewall as a DNS Proxy

Benefit Details
Centralized DNS Logging Capture DNS query logs through Azure Monitor.
Policy Enforcement Allow/deny traffic based on DNS names, not just IPs (FQDN tags).
Security Hardening DNS queries stay inside Azure without direct external exposure.
Simplified Architecture No need for separate DNS proxy VMs or appliances.
Supports Private and Public Resolution Forward DNS queries to Private DNS Zones, on-premises DNS servers, or Internet DNS servers.

Where Azure Firewall DNS Proxy Adds Value

  • Zero-trust network designs needing DNS visibility at every boundary.
  • Hybrid environments where Azure resources resolve both private and public domains securely.
  • Environments requiring DNS query logging for compliance (e.g., PCI DSS, ISO 27001).
  • Reducing operational complexity versus managing dedicated DNS forwarders.

Visualizing Azure Firewall as a DNS Proxy

Here’s a diagram illustrating how Azure Firewall sits between VMs and external/internal DNS servers:

flowchart TB subgraph AzureVNet ["Azure Virtual Network (myVNet)"] AzureVM["Azure VM (10.1.0.4)"] AzureFirewall["Azure Firewall (DNS Proxy enabled)"] end subgraph ExternalDNS ["DNS Resolution Targets"] PrivateDNS["Azure Private DNS Zone / On-Prem DNS Server"] InternetDNS["Public Internet DNS Servers"] end AzureVM -- "DNS Query" --> AzureFirewall AzureFirewall -- "DNS Forwarding" --> PrivateDNS AzureFirewall -- "DNS Forwarding" --> InternetDNS PrivateDNS -- "DNS Response" --> AzureFirewall InternetDNS -- "DNS Response" --> AzureFirewall AzureFirewall -- "Response" --> AzureVM

Configuring Azure Firewall DNS Proxy Using the Azure Portal

Step 1: Deploy Azure Firewall (if not already deployed)

  1. In the Azure Portal, navigate to Create a resource > Networking > Azure Firewall.
  2. Follow the deployment wizard to deploy the Firewall into your Virtual Network.

Step 2: Enable DNS Proxy on Azure Firewall

  1. Open your deployed Azure Firewall.
  2. Under Settings, select DNS Settings.
  3. Set DNS Proxy to Enabled.
  4. Under Custom DNS servers, enter:
    • Your internal DNS IP (e.g., Private DNS Resolver inbound endpoint IP, or On-prem DNS IP accessible via VPN/ExpressRoute).
  5. Save the settings.

Step 3: Configure VM DNS Settings

  • Configure your VM NIC settings or VNet DNS settings to point to Azure Firewall’s Private IP Address.
  • This ensures that all VM DNS queries go through the firewall.

Step 4: Test the Setup

  • SSH or RDP into a VM.
  • Run nslookup or dig against a private domain (e.g., internal.contoso.com) and a public domain (e.g., www.microsoft.com).
  • Verify that the response is successful and logged in Azure Firewall diagnostics.

Deploying Azure Firewall DNS Proxy Using Bicep

Here’s a Bicep template to configure Azure Firewall with DNS Proxy enabled:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
@description('Name of the Azure Firewall')
param firewallName string = 'myFirewall'

@description('Name of the Virtual Network and Subnet IDs')
param vnetId string
param subnetId string

@description('List of custom DNS server IPs')
param customDnsServers array = [
  '10.2.0.4' // Example Private Resolver IP
]

resource firewall 'Microsoft.Network/azureFirewalls@2023-02-01' = {
  name: firewallName
  location: resourceGroup().location
  properties: {
    sku: {
      name: 'AZFW_VNet'
      tier: 'Standard'
    }
    ipConfigurations: [
      {
        name: 'firewall-ipconfig'
        properties: {
          subnet: {
            id: subnetId
          }
          publicIPAddress: {
            id: '' // If using a public IP; optional for internal-only
          }
        }
      }
    ]
    dnsSettings: {
      servers: customDnsServers
      enableDnsProxy: true
    }
  }
}
ℹ️
Make sure to link the VM NICs or VNet DNS settings to the Firewall’s private IP separately after deployment!

We discussed this in the previous blog article Mastering Azure DNS Solutions - Part 4 - Custom DNS

Security Considerations

  • Use NSGs and Firewall policies to restrict who can send DNS queries to Azure Firewall.
  • Monitor DNS logs through Azure Monitor to detect anomalies.
  • Avoid recursive loops: Make sure the custom DNS servers you configure don’t forward back to the Firewall.
  • High Availability: Azure Firewall is highly available by design, but monitor and alert on performance metrics.

Design Guidance

  • Centralize all VNet DNS queries through the Azure Firewall for full visibility.
  • Pair with Azure DNS Private Resolver to handle private Azure zone resolutions efficiently.
  • Use Firewall Policy for DNS Filtering: Block/allow specific domains based on your organization’s security policies.
  • Document fallback behavior: Ensure VMs fail gracefully if DNS resolution is interrupted.

Conclusion

Using Azure Firewall as a DNS Proxy gives you centralized DNS security, control, and auditing without introducing extra infrastructure complexity.
Whether protecting cloud-native environments or extending hybrid DNS visibility, this pattern improves observability and enforces corporate policies at a critical layer of the networking stack.

DNS is your first line of network defense — make sure you can see and control it properly!

Learn More