Microsoft Defender for Cloud · Microsoft Defender for Cloud
Microsoft Defender for DNS should be enabled
Written and reviewed by Emnode · Last reviewed
What does the recommendation "Microsoft Defender for DNS should be enabled" check?
Flags any subscription where the standalone Microsoft Defender for DNS plan is not set to the Standard tier. Defender for DNS is agentless: it analyses the DNS queries that your Azure resources send through the Azure-provided (default) recursive resolver and raises alerts for DNS tunnelling, data exfiltration, communication with command-and-control servers, cryptomining domains and other known-malicious lookups. The check only covers traffic that traverses Azure's default resolver. It does NOT inspect queries sent to custom or third-party DNS servers, queries that use DNS over HTTPS to bypass the system resolver, or any non-DNS network traffic, and it detects suspicious lookups rather than blocking them. Note that the standalone Dns plan is deprecated: since 1 August 2023 new subscriptions receive the same DNS detections through Defender for Servers Plan 2, while subscriptions that already had the standalone plan can keep it.
Why does "Microsoft Defender for DNS should be enabled" matter?
Almost every modern intrusion touches DNS: malware resolves its command-and-control domain, and exfiltrated data is frequently smuggled out one TXT-record query at a time precisely because DNS is rarely inspected. Without DNS-layer detection that activity blends into normal traffic and the first sign of compromise is often the breach notification itself. Turning on these detections gives you an early, agentless tripwire across every resource on the subscription, shrinking the window between a foothold and your response and reducing the regulatory and reputational cost of a breach that ran undetected for weeks.
How do I fix "Microsoft Defender for DNS should be enabled"?
- If the subscription already runs the standalone plan, raise it to Standard with: az security pricing create --name 'Dns' --pricing-tier 'Standard', then confirm with az security pricing show --name 'Dns' --query 'pricingTier'.
- For any subscription onboarded after 1 August 2023, do not chase the deprecated Dns plan: enable Defender for Servers Plan 2 instead (az security pricing create --name 'VirtualMachines' --pricing-tier 'Standard' --subplan 'P2'), which now carries the DNS detections.
- Route alerts to a real inbox by configuring Defender for Cloud email notifications so high-severity DNS findings are not missed: az security contact create with the alert-notifications object set to '{"state":"On","minimalSeverity":"High"}'.
Remediation script · bash
# Enable the three high-value Defender plans on the current subscription.
# Servers on Plan 2 (adds JIT access, FIM and vulnerability scanning).
az security pricing create --name VirtualMachines \
--tier Standard --subplan P2
# Storage on the current per-account plan.
az security pricing create --name StorageAccounts --tier Standard
# Azure SQL Database servers (VA + Advanced Threat Protection).
az security pricing create --name SqlServers --tier Standard
# Verify what is now active on this subscription.
az security pricing list \
--query "value[?pricingTier=='Standard'].name" -o tsv
# Ratchet it shut for the estate: assign the built-in DeployIfNotExists
# policies that turn each plan on for any subscription where it is missing.
# Servers (built-in 'Configure Azure Defender for servers to be enabled').
az policy assignment create \
--name enable-defender-servers \
--policy 8e86a5b6-b9bd-49d1-8e21-4bb8a0862222 \
--scope "/providers/Microsoft.Management/managementGroups/contoso-root"
# Look up the matching Storage and SQL policies by display name rather than
# hard-coding a GUID, then assign each the same way at the same scope.
az policy definition list \
--query "[?contains(displayName, 'Configure Microsoft Defender for Storage') || contains(displayName, 'Configure Azure Defender to be enabled on SQL servers')].{name:name, displayName:displayName}" \
-o table Full walkthrough (console steps, edge cases and verification) in the lesson Enable Microsoft Defender for Cloud plans.
Is "Microsoft Defender for DNS should be enabled" a false positive?
A subscription whose resources resolve DNS exclusively through a self-managed forwarder or a third-party resolver gains little from the standalone plan, because Defender for DNS only sees the Azure default resolver and would observe almost no query traffic. In that architecture the correct fix is to enable DNS detection where the queries actually flow, through Defender for Servers Plan 2 on the workloads or your forwarder's own threat intelligence, and document the standalone-plan finding as an accepted exception rather than paying for a plan that cannot see your traffic.
More Microsoft Defender for Cloud controls
- Email notification to subscription owner for high severity alerts should be enabled
- Microsoft Defender for Azure Cosmos DB should be enabled
- Microsoft Defender for Containers should be enabled
- Microsoft Defender for open-source relational databases should be enabled
- Microsoft Defender for Resource Manager should be enabled
- Microsoft Defender for SQL on machines should be enabled on workspaces
- Microsoft Defender for SQL servers on machines should be enabled