All Azure Technologies @ one Place

Understanding the Delay in Implementing DNS Features

At the heart of Azure’s integrated DNS resolution lies the wire Server identified by 168.63.129.16. By default, every virtual machine within Azure is able to use this for resolving both Azure Private DNS zones and public names. Known for its reliability and speed, it’s worth noting that for many years it generated precisely zero DNS query logs—absolutely nothing. This particular IP had no logging features whatsoever.

Even with the launch of the Azure Private DNS Resolver, the issue of logging remained unresolved. While it advanced DNS architecture considerably, it still left a significant logging gap.

Consequently, customers facing compliance obligations, security teams requiring DNS visibility, or architects wanting insight into workload resolutions had to resort to one of two options:

• 1.Implement a third-party DNS solution (such as Infoblox, Bluecat, BIND, or Windows DNS Server) and route all compute through it. While this provided logging, it also brought about additional VMs to oversee, increased licensing costs, and an architecture that wasn’t ideal for isolated workloads.
• 2.Utilise Azure Firewall’s DNS proxy feature, which did offer query logging. This was a sensible choice for those already using the Firewall, but it represented a significant expense solely for the purpose of DNS visibility.

Both approaches posed financial burdens to resolve what should have been an intrinsic feature of the platform. The introduction of DNS Security Policies finally changes that.

The Functionality of DNS Security Policies

DNS Security Policies encompass two key functions, each deserving clear distinction:

How the Components Interact

Before diving into configuration, it’s useful to grasp the structure of DNS Security Policies. Three types of resources are involved, and the terminology used in Microsoft Learn documents varies slightly from the API’s naming conventions. Here’s a quick comparison:

Nomenclature Overview (Learn docs vs. API) DNS Security Policy = DNS Resolver Policy
DNS Traffic Rules = DNS Security Rules
Domain Lists = DNS Resolver Domain Lists

These resources are interrelated: the DNS Security Policy acts as the parent resource, containing two child types—DNS Traffic Rules (your logging and filtering logic) and Virtual Network Links (which VNets the policy applies to). Domain Lists are not children of the policy but siblings, which allows a single list to be reused across various policies.

DNS Traffic Rules

Each rule serves as the driving force behind the policy, with its own priority (ranging from 100 to 65,000), action (block, allow, or alert), and reference to a domain list. Up to ten rules can exist within a policy, evaluated in order of priority, starting from the lowest number.

Here’s an example of a typical layered rule set:

Heads Up on Priority Ordering Keep in mind that rules are assessed in sequence, and the first matching rule takes precedence. So, if you allow contoso.com at rule 100 and attempt to block bad.contoso.com at rule 200, the block will not trigger, as the allow rule will match first. Be careful with how you order your rules.

Domain Lists

Domain lists define the criteria against which the rules match. Each entry can either be a complete domain name or a wildcard denoted by a single period (which signifies all subdomains). Since domain lists are siblings of the policy rather than children, you can maintain a central repository of lists and apply them across various policies in different environments.

Virtual Network Links

This mechanism links a policy to its applicable traffic. Each virtual network link connects one DNS Security Policy to a single virtual network, enabling the policy to intercept queries that traverse that VNet’s wire Server.

It’s essential to note that each virtual network can only be linked to one DNS Security Policy. However, a single policy may be associated with multiple virtual networks, which facilitates centralised designs. Additionally, since these policies are regional assets, you’ll need to establish one for each region in a multi-region setup.

Understanding Captured Data

The policy processes queries funnelling through the wire Server of the linked virtual network. Here’s a summary of what has been tested and the results obtained:

The last entry is particularly significant. If a machine is set to use a DNS Server outside of the wire Server—such as a private IP directed to an on-premises resolver—its queries will not be captured by the policy. The policy is designed to catch only those inquiries that pass through Azure’s default DNS resolution path.

Insights on Log and Block Outputs

When diagnostic logging is activated on a DNS Security Policy, query events are logged in a table named DNSQueryLogs within Log Analytics. Each entry encompasses the source IP of the query, the queried domain name, the record type, and the action undertaken. The action field can hold values such as Deny, Allow, and None (which correlates with the alert action).

When a query is blocked, the client receives a response that is not an NXDOMAIN. Instead, the reply contains a CNAME pointing to blockpolicy.azuredns.invalid. This is advantageous for troubleshooting, as an NXDOMAIN suggests the domain does not exist. The blockpolicy.azuredns.invalid CNAME immediately clarifies that a DNS Security Policy caused the query failure, rather than pointing to a misconfigured DNS record or a nonexistent zone.

Practical Applications for Linking Policies

The policy captures queries at the wire Server level within the linked virtual network. If you are employing a centralised DNS architecture with an Azure Private DNS Resolver (or an alternative DNS service) in a hub VNet, the best practice is to apply the policy to that hub VNet. This way, all spoke queries that route through the hub’s DNS infrastructure will be monitored by the policy.

For isolated workloads that do not connect with a shared DNS hub, you can attach the policy directly to each standalone VNet. Since one policy can be associated with multiple VNets, this allows a single policy to cater to an entire hub-and-spoke structure while another policy addresses isolated environments.

One Policy per Region Remember that DNS Security Policies are regional resources. If your workloads are spread across multiple Azure regions, separate policies will be necessary for each. Fortunately, the same domain lists can be utilized across all of them.

Final Thoughts

This should have been a standard feature introduced years ago, and this observation isn’t meant as a critique of the development team responsible for it. Visibility into DNS queries is essential for any security-focused Azure deployment. Previously, obtaining this visibility necessitated the use of a third-party DNS Server or Azure Firewall, imposing considerable costs and complex setups on customers.

The filtering feature adds genuine value as well. Being able to block known malicious domains at the DNS level, prior to any connection attempts, serves as an effective and efficient security measure. The model for reusing domain lists is thoughtfully designed for multi-environment deployments. Although the alert action behaving similarly to allow is a quirk to keep an eye on, the early functionality promises a solid foundation.

If your Azure workloads have any compliance, security, or operational visibility requirements concerning DNS, setting this up should be a priority now. The era of spinning up BIND servers just to obtain DNS logs is behind us.