Azure Private Link DNS NXDOMAIN DoS: Hidden Risks Across VNets and Mitigations

A quietly dangerous interaction between Azure Private Link’s DNS behavior and well-meaning Private Endpoint deployments can produce an unexpected denial-of-service effect across tenant resources — and defenders need to treat it like a design flaw, not merely a documentation footnote. Unit 42’s investigation shows how creating Private Endpoints or Private DNS zone links in one virtual network can force DNS resolution down a path that returns NXDOMAIN for the same resource from other VNets, effectively cutting off access to otherwise-working public endpoints. This creates three realistic attack or accident vectors — internal misconfiguration, third‑party/vendor deployment, and malicious actor abuse — and leaves a large population of Azure customers exposed unless they adopt explicit mitigations such as Azure’s “fallback to internet” or carefully managed DNS records. m])

Background​

How Private Link, Private Endpoints and Private DNS zones interact​

Azure Private Link provides a secure, private‑network path to many Azure PaaS services by mapping a service’s public DNS name to a private IP assigned to a Private Endpoint. To implement this mapping, Azure commonly creates Private DNS zones (for example, privatelink.blob.core.windows[.]net) and links them to the virtual networks where the Private Endpoint lives. When a VM or workload in a VNet queries a service name such as mystorage.blob.core.windows[.]net and that VNet has a virtual network link to the Private DNS zone for blob storage, Azure’s resolution logic will prefer the private zone — returning the Private Endpoint IP (via an A record) instead of the public service endpoint. This behavior is by design and intended to ensure that workloads within VNets using Private Endpoints always route traffic over Azure’s backbone. However, because the private zones take precedence, a VNet that is linked to a Private DNS zone but lacks the specific A record for a particular resource will receive an authoritative negative (NXDOMAIN) for that name — even if the resource’s public endpoint remains available. In practice that means: add a Private DNS zone link in the wrong place (or on behalf of another tenant) and you can break name resolution for workloads that previously relied on the public endpoint. Microsoft documents this behavior and the need for additional DNS configuration when Private DNS zones overlap with public resource names.

The denial-of-service mechanism​

The outage is not caused by the service itself (the storage account, Key Vault, Cosmos DB, etc. being taken down; it is caused by DNS resolution shifting to a Private DNS zone that has no matching A record for that particular resource. The net effect is a partial denial-of-service: workloads that resolve via the affected VNet can’t find the resource’s IP and thus chough the resource’s public endpoint and ACLs have not changed. Unit 42 demonstrated several realistic triggers for this failure mode — accidental and deliberate — and highlighted the potential for cascading impact when core resources (storage, Key Vault) are affected.

---

Why this matters now (and who’s at risk)​

Services commonly affected​

Any Azure service that supports Private Link and uses the privatelink.* naming pattern can be impacted. Microsoft’s service documentation and governance/best‑practice content make it clear that services such as Azure Storage, Azure Key Vault, Azure Cosmos DB, Azure Container Registry (ACR), App Service / Function Apps, and many Azure AI/ML offerings support Private Endpoints and the corresponding private DNS zones. If a VNet linked to a privatelink zone receives DNS queries for names that are present only in other private zones (or in public DNS), those queries can fail with NXDOMAIN unless corrected. Unit 42 lists Key Vault, Cosmos DB, ACR, Function Apps and OpenAI accounts among the frequently affected services — all of which have Private Link support. is straightforward: if storage access is broken, Functions can fail to start or update; if Key Vault access is broken, secrets cannot be fetched and services depending on them fail; if ACR access breaks, deployments and image pulls fail. Those dependencies make this a high‑impact availability problem, not just an esoteric DNS annoyance.

Attack and accident vectors​

• Accidental — internal: a network admin creates a Private Endpoint and the associated Private DNS zone and links it to VNets to lock down resources, but forgets to add records or enable fallback where required. The result: legitimate internal workloads can no longer reach previously accessible public endpoints.
• Accidental — vendor: a third‑party vendor deploys Private Endpoints (common for scanners, security tooling, or managed services). Because vendors often operate under different subscriptions or resource groups, their Private DNS zones can to VNets and inadvertently disrupt DNS resolution.
• Malicious — attacker: a threat actor with the ability to create Private Endpoints (compromised or misused service principal, subscription-level access) can create Private DNS zones and links intentionally to cause an outage across target VNets. This is an attractive low-effort DoS vector inside the victim’s cloud tenancy. Unit 42 calls out the exact same threat model.

---

Technical anatomy: how a Private Endpoint causes NXDOMAIN-induced DoS​

Typical flow without Private Endpoint​

• Client VM issues DNS query for mystorage.blob.core.windows[.]net.
• Resolver returns the public IP (via CNAME to service endpoint), client connects to the public endpoint.
• Storage evaluates the source IP against its Network ACLs and allows/denies accordingly.

Flow with a Private Endpoint in another VNet (the problem)​

• A Private Endpoint is created for the storage account in VNet2; Azure created a Private DNS zone privatelink.blob.core.windows[.]net and added an A record for that storage account in the zone linked to VNet2.
• VNet1 is linked to the same Private DNS zone (perhaps automatically, or by an administrator).
• A VM in VNet1 queries mystorage.blob.core.windows[.]net. Azure’s DNS resolution logic checks the linked Private DNS zone first; it finds no A record for the storage account in the zone as seen from VNet1 and returns NXDOMAIN.
• Because resolution returned NXDOMAIN, the client does not attempt the public endpoint and the connection fails — service is effectively denied to workloads in VNet1 despite no change at the storage account itself. Microsoft documents this priority/override interaction and warns that private zones linked to VNets can cause NXDOMAIN responses unless the zone contains the expected records or fallback is configured.

---

Microsoft’s mitigations — what exists, and their trade‑offs​

Microsoft recognizes this behavior and offers two pragmatic mitigations:

• Enable fallback to internet (NxDomainRedirect) on the Virtual Network Link for the Private DNS zone. When enabled, Azure’s recursive resolvers will retry failed queries (NXDOMAIN) against public DNS and return the public endpoint if found. This restores reachability but routes the traffic discovery path via the internet resolver instead of strictly over Azure’s private backbone — a security/architecture tradeoff. Detailed Microsoft guidance and how‑to steps are available in the Azure Private DNS documentation.
• Manually add records (A or CNAME) into the Private DNS zone for the missing public resources so that the name resolves to a reachable IP. This avoids routing via the public internet but introduces operational overhead and drift risk: public IPs can change and manual maintenance burden. Microsoft explicitly calls out that manual A‑records are possible, but not recommended at scale.

Both approaches close the immediate availability hole — but neither perfectly preserves the original Private Link design goals (strict private‑backbone traffic and minimal public exposure). Unit 42 argues that the fallback option partially addresses the problem but undermines the “private backbone only” model; manual records are operationally heavy. Both are useful as stopgaps that must be accompanied by better discovery and governance.

---

Practical detection and hunting guidance​

Defenders should treat this as a configuration/telemetry problem: discover VNets linked to privatelink zones, identify resources that allow public access but lack Private Endpoints in some VNets, and monitor DNS resolution failures to Private Link namespaces.

• Use Azure Resource Graph or Azure CLI to enumerate Private DNS zone virtual network links and their resolutionPolicy values (NxDomainRedirect). Microsoft provides sample queries and guidance on how to identify whand whether fallback is enabled. Enabling NxDomainRedirect may be an acceptable remediation in many environments but should be managed centrally.
• Query for storage accounts (or other resource types) that have public network access enabled but also use network ACLs (defaultAction Deny with selected vnets/IPs) and do not have any privateEndpointConnections. Those are classic candidates for being broken by Private DNS zone links because they are reachable via specific VNets or IPs but lack a private endpoint in some networks. Unit 42 included example Resource Graph queries to locate these patterns; use them as a starting point for large estates and adapt for Key Vault, ACR, Cosmos DB, and App Services.
• Search DNS logs and application errors for sudden spikes of NXDOMAIN responses against privatelink.* domains or for application errors pointing to “name not at previously worked. If you lack DNS logging in cloud VNets, instrument VMs or use Azure Private Resolver/Private DNS logging to capture the failing queries. Cloud providers and third‑party network observability tools can help correlate DNS failures with service‑level incidents.
• Audit who can create Private Endpoints: limit scope of contributors and service principals that can create network interfaces and private endpoints. The easiest attack vector is a compromised or overly-permissive identity that can register Private Endpoints and link private DNS zones into VNets. Apply least privilege via RBAC and require approhanges. Unit 42 highlights the attacker vector where an actor with rights can intentionally create Private Endpoints to cause DoS.

---

Concrete remediation playbook (prioritized)​

• Inventory: export current Private DNS zones, virtual network links, and resolutionPolicy values. Search for links to privatelink.* zones and identify VNets that are forced to resolve through them. Use Azure Resource Graph queries or the Azure portal audit views.
• Assess exposures: find PaaS resources (storage, Key Vault, Cosmos DB, ACR, Function Apps) where:
• publicNetworkAccess == "Enabled" AND
• defaultAction == "Deny" AND
• no privateEndpointConnections exist AND
• vnetRules or ipRules allow specific VNets or IPs to reach them.
  These are high-risk resources that could be subject to DNS-induced DoS. Unit 42 provides sample Resource Graph queries to find such combinations.
• Short-term fix (fastest): enable fallback to internet (NxDomainRedirect) on the VNet link(s) that are breaking name resolution. This will restore resolution quickly for most cases. Document the decision and classify which VNets are allowed to use fallback, because this relaxes the private-only guarantee.
• Medium-term fix (preferred where possible): for services you control, deploy Private Endpoints in each VNet that needs deterministic private access or implement carefully scoped DNS forwarding rules (Azure Private Resolver) so that queries for public resources are forwarded to a resolver that can answer them correctly. This preserves private-bounded traffic for workloads that need it.
• Long-term governance: restrict who can create Private Endpoints and who can link Private DNS zones into VNets. Require change approvals for network DNS links and add automated compliance/enforcement (Azure Policy) to detect and block promiscuous links or unauthorized resolutionPolicy changes. Use auditable change requests for any NxDomainRedirect toggles.
• Operational hygiene: treat DNS as part of your incident runbooks. Instrument DNS query logs, add alerts for NXDOMAIN spikes in privatelink namespaces, and route such alerts to networking and cloud securwith application errors to detect cascading outages early.

---

Risks and tradeoffs — what defenders must weigh​

• Enabling fallback to the internet recovers availability at the cost of breaking the strict “traffic over Azure backbone only” model. For highly regulated environments this may be unacceptable; for many commercial workloads it’s an operationally reasonable compromise. Microsoft documents this trade‑off and provides the NxDomainRedirect toggle specifically to address the real-world complexity of multi-tenant, multi-subscription Private Link patterns.
• Manual DNS entries reduce the internet‑exposure tradeoff but create operational drift and maintenance burden. Public IPs tied to public endpoints may change; manual A records in private zones can become stale, creating new outages later. Microsoft explicitly discourages this for large fleets.
• The attack surface for abuse is primarily misused creation of Private Endpoints or DNS links. Limit who can create those resources and apply detection for unusual Private Endpoint creation in your tenancy. Unit 42 emphasizes that a malicious actor with sufficient permissions can weaponize Private Endpoint cdenial-of-service condition.
• Complex multi-tenant or managed‑service arrangements (vendors servicing many customers) can lead to accidental cross-linking or poorly documented DNS constructs; defenders should treat vendor-deployed Private Endpoints as a managed change with explicit operational rules and approvals.

---

Independent confirmation and how strongly to believe the metrics​

Unit 42 reports that “over 5% of Azure storage accounts” are currently configured in a way that makes them susceptible to this DNS‑induced DoS condition. That is a high‑visibility claim and an important finding if accurate. Public Microsoft documentation confirms the mechanics (how private DNS zones and Private Endpoints can lead to NXDOMAIN and the availability of NxDomainRedirect/fallback) and independent community writeups and operator blogs document real‑world encounters with the exact NXDOMAIN problem (for example, writeups showing CNAME→privatelink and NXDOMAIN behavior gnostics). However, the specific numeric claim (the 5% figure) is telemetry‑dependent and comes from Unit 42’s analysis of its datasets. That precise percentage should be treated as a directional indicator: meaningful and concerning, but not a universal law. Defenders should therefore act on the root cause (DNS interactions and governance) rather than fixating solely on the percentage claim; treat the 5% figure as a credible indicator that the issue is widespread enough to need organized remediation, not proof that all or most customers are affected.

---

Recommended policy controls and automation​

• Enforce an Azure Policy that audits (or denies) creation of Private DNS zone virtual network links unless they are pre‑approved. Make NxDomainRedirect an explicit property in your audits so you can control activation at scale.
• Centralize DNS management: avoid ad‑hoc linking of private zones into VNets by delegating Private DNS zone lifecycle to a small set of network administrators.
• Monitor Azure Activity Logs and Azure Policy events for Private Endpoint creations and Private DNS virtual network link changes; escalate unexpected changes to a security operations queue.
• Build Resource Graph queries into scheduled automation to list risky storage accounts (publicNetworkAccess enabled + do privateEndpointConnections + allowed vnets/ipRules). Use that inventory to prioritize service-by-service remediation. Unit 42 provides sample Resource Graph queries that can be adapted to your estate.

---

n calls for operational controls, not just documentation
Azure Private Link and Private Endpoints are powerful tools for reducing attack surface and meeting compliance requirements, but their DNS-first mechanics create a brittle interplay that can be weaponized or accidentally misconfigured to produce a denial-of-service outcome. Microsoft’s fallback mechanism (NxDomainRedirect) and manual record options are useful mitigations, but they trade off the original security posture or increase operational overhead. The pragmatic defense is a layered program of inventory, least-privilege governance for endpoint creation, DNS visibility and logging, automated scanning of the precise configuration comb highlights, and a prioritized remediation playbook that matches each service’s business criticality. Palo Alto Networks’ Unit 42 offers specific cloud posture assessment and runtime protections that can help detect, alert and remediate the kinds of misuse described here; their published investigation provides the operational signal that defenders should not ignore. Treat Private Endpoint deployment as a change that requires security review, DNS design validation, and business signoff — doing so will prevent accidental outages and deny attackers a surprisingly easy DoS vector inside compromised or mismanaged Azure environments.

---

Quick reference — action checklist​

• Run Resource Graph queries to find VNets linked to privatelink.* zones and to find storage/KeyVault/ACR resources that match the risky pattern Unit 42 describes.
• If you observe outages or NXDOMAIN spikes for privatelink.* names, consider enabling NxDomainRedirect on the affected VNet links as an emergency remediation.
• Where privacy/compliance requires private-only routing, plan and deploy Private Endpoints for each VNet that needs access, or implement Azure Private Resolver/conditional forwarding to correctly terminate queries.
• Lock down RBAC for Private Endpoint and Private DNS management and monitor Azure Activity Logs for unexpected changes.
• Document vendor-managed Private Endpoint practices and require visibility/approval for vendor DNS/link changes to customer VNets.

This combination of discovery, rapid contingency (fallback), permanent fixes (private endpoints/forwarding), and governance will close the gap Unit 42 exposed: without it, well‑meaning networking changes — or a single compromised identity — can produce real downtime for cloud applications by exploiting the way Azure prioritizes private DNS zones.

---

Source: Unit 42 DNS OverDoS: Are Private Endpoints Too Private?