Azure Finally Has Native DNS Query Logging

Azure DNS Security Policies hit general availability, bringing native DNS query logging to the platform. And while logging alone would have been enough to get my attention, they also shipped DNS query filtering (block, allow, alert) in the same package. Let me walk through how it all works

Why This Took So Long to Matter

The core of Azure's built-in DNS resolution is the wire server at 168.63.129.16. Every virtual machine in Azure can use it by default to resolve Azure Private DNS zones and public names. It's reliable, it's fast, and for years it produced exactly zero DNS query logs. Nothing. That magic IP address had no logging capability at all.

Even the Azure Private DNS Resolver, when it was introduced, didn't solve this. It improved DNS architecture significantly but still left the logging gap wide open.

So customers with compliance requirements, security teams that needed DNS visibility, or architects who just wanted to know what their workloads were actually resolving ended up doing one of two things:

• 1.Stand up a third-party DNS service (Infoblox, Bluecat, BIND, Windows DNS Server) and route all compute through it. This gave you logs but also gave you more VMs to manage, more licensing costs, and an architecture that didn't fit well for isolated workloads.
• 2.Use Azure Firewall's DNS proxy feature, which did include query logging. A reasonable option if you were already running Firewall, but a significant cost to justify just for DNS visibility.

Both patterns were expensive ways to solve what should have been a platform-level feature. DNS Security Policies finally makes it one.

What DNS Security Policies Actually Do

There are two functions here, and they're worth separating clearly:

DNS Query Logging

Every query processed through the policy gets captured: source IP, query name, record type, action taken. Send it to Log Analytics, a storage account, or Event Hub.

DNS Query Filtering

Block or allow queries based on domain lists. Blocked queries return a specific CNAME response instead of NXDOMAIN, making it clear what happened.

Alert Action

There's an "alert" action in the rule set. Honest note: in testing, it appears to behave the same as allow and log. Worth being aware of before you build logic around it.

How the Resources Fit Together

Before getting into configuration, it helps to understand how DNS Security Policies are structured. There are three resource types involved, and the Microsoft Learn docs use slightly different names from what the API actually calls them. Here's the quick translation:

Naming cheat sheet (Learn docs vs. API) DNS Security Policy = DNS Resolver Policy
DNS Traffic Rules = DNS Security Rules
Domain Lists = DNS Resolver Domain Lists

These three types relate to each other as follows: the DNS Security Policy is the parent. It has two types of children: DNS Traffic Rules (your filtering and logging logic) and Virtual Network Links (which VNets the policy applies to). Domain Lists are sibling resources to the policy itself, not children, which means you can reuse the same domain list across multiple policies.

DNS Traffic Rules

Rules are the engine of the policy. Each rule has a priority (100 to 65,000), an action (block, allow, or alert), and a reference to a domain list. A policy can have up to 10 rules. Rules are evaluated in priority order, lowest number first.

Here's what a typical layered rule set might look like:

100 Malware domain list Block Denies queries matching known bad domains

200 Sensitive data exfil list Alert Logs the query (currently behaves like allow)

65000 All traffic Allow Catches everything else, generates log entry

Priority ordering gotcha Rules are evaluated in order, and the first match wins. If you allow contoso.com at rule 100 and try to block bad.contoso.com at rule 200, the block will never fire. The rule 100 allow matches first because bad.contoso.com is a subdomain of contoso.com. Plan your rule ordering carefully.

Domain Lists

Domain lists are where you define what the rules match against. Each entry is either a full domain name or a wildcard, represented by a single period (which matches all subdomains). Because domain lists are siblings of the policy rather than children, you can maintain a central set of lists and reuse them across multiple policies in different environments.

Virtual Network Links

This is how you apply a policy to traffic. Each virtual network link ties one DNS Security Policy to one virtual network. The policy then intercepts queries that flow through that VNet's wire server.

Key constraints to know: each virtual network can only be linked to one DNS Security Policy. However, a single policy can be linked to multiple virtual networks, making centralized designs workable. And since these policies are regional resources, you'll need one per region in a multi-region setup.

What Actually Gets Captured

The policy processes queries that go through the wire server in the linked virtual network. Here's what was tested and what the results were:

Scenario	Captured?
VM using wire server (168.63.129.16) in linked VNet	Yes
VM using Azure Private DNS Resolver in the same VNet	Yes
VM using a DNS proxy in front of Private DNS Resolver	Yes
A records and PTR records	Yes
AAAA records	Yes
TCP-based DNS queries (not just UDP)	Yes
Azure Bastion	Yes
Azure Firewall	Yes
VM pointing to an external DNS server (bypassing wire server)	No

That last row is important. If a machine is configured to use a DNS server outside the wire server (say, a private IP pointing to an on-prem resolver), its queries won't pass through the policy. The policy only catches what goes through Azure's built-in DNS resolution path.

What the Logs and Blocks Actually Look Like

When diagnostic logging is enabled on a DNS Security Policy, query events are written to a Log Analytics table named DNSQueryLogs. Each entry includes the source IP of the query, the domain name queried, the record type, and the action taken. The action field values are Deny, Allow, and None (which corresponds to the alert action).

When a query is blocked, the response the client receives is not an NXDOMAIN. Instead, it gets back a CNAME pointing to blockpolicy.azuredns.invalid. This is actually better behavior for troubleshooting. An NXDOMAIN looks like the domain doesn't exist. The blockpolicy.azuredns.invalid CNAME makes it immediately obvious that a DNS Security Policy is the reason the query failed, not a misconfigured DNS record or a missing zone.

Where to Link Policies in Practice

The policy intercepts queries at the wire server level in the linked virtual network. In a centralized DNS design where you're running an Azure Private DNS Resolver (or any DNS service) in a hub VNet, the right place to attach the policy is on that hub VNet. All spoke queries that route through the hub's DNS infrastructure will be captured by the policy.

For isolated workloads that don't connect to a shared DNS hub, you can link the policy directly to each isolated VNet. Since a policy can be linked to multiple VNets, one policy can cover an entire hub-and-spoke design while a separate policy handles isolated environments.

One policy per region DNS Security Policies are regional resources. If you have workloads in multiple Azure regions, you'll need a separate policy in each region. You can reuse the same domain lists across all of them.

My Take

This is a feature that should have shipped years ago, and saying that isn't a criticism of the team that built it. DNS query visibility is table stakes for any security-conscious Azure deployment. The fact that it required either a third-party DNS server or Azure Firewall to achieve was a real cost and complexity burden on customers.

The filtering capability is a genuine bonus. Being able to block known-bad domains at the DNS level, before a connection is even attempted, is a lightweight and effective control. The domain list reuse model is well thought out for multi-environment deployments. The alert action being effectively the same as allow is a quirk to watch, but it's early days and GA means the foundations are solid.

If you're running Azure workloads with any compliance, security, or operational visibility requirements around DNS, this is worth setting up today. The days of spinning up BIND servers just to get DNS logs are over.

References
Azure DNS Security Policies - Microsoft Docs
DNS in Microsoft Azure: DNS Security Policies - Journey of the Geek