Share via

What is azureprivatedns.net ? How its related with Azure private DNS Zones?

Rajesh Swarnkar 1,236 Reputation points
2026-05-26T10:16:00.75+00:00

Hi, When I do nslookup with debug flags, I have noticed this primary name server = azureprivatedns.net. May I know how its related to Private DNS Zones and what exactly it is? 

$ nslookup -debug -type=a mycoolstorage.privatelink.blob.core.windows.net
Server:  europednssrv.fabrikam.net
Address:  10.255.17.30
 
Got answer:
    HEADER:
        opcode = QUERY, id = 3, rcode = NXDOMAIN
        header flags:  response, want recursion, recursion avail.
        questions = 1,  answers = 0,  authority records = 1,  additional = 0
    QUESTIONS:
        mycoolstorage.privatelink.blob.core.windows.net, type = A, class = IN
    AUTHORITY RECORDS:
    ->  privatelink.blob.core.windows.net
        ttl = 10 (10 secs)
        primary name server = azureprivatedns.net
        responsible mail addr = azureprivatedns-host.microsoft.com
        serial  = 1
        refresh = 3600 (1 hour)
        retry   = 300 (5 mins)
        expire  = 2419200 (28 days)
        default TTL = 10 (10 secs)
Azure DNS
Azure DNS

An Azure service that enables hosting Domain Name System (DNS) domains in Azure.

0 comments

Answer accepted by question author

Jerald Felix 14,885 Reputation points Volunteer Moderator
2026-05-26T12:33:03.2466667+00:00

Hello Rajesh Swarnkar,

Greetings! Thanks for raising this question in the Q&A forum.

Great observation and a really good question! What you spotted in that nslookup -debug output is completely normal and expected nothing is broken. Let me explain it clearly in simple terms.

Think of azureprivatedns.net as the hidden backbone name server that Azure uses internally to host and manage all Azure Private DNS Zones. It is Microsoft's own internal DNS infrastructure you will never create it, manage it, or interact with it directly. It just shows up in the SOA (Start of Authority) record whenever Azure is the authority for a Private DNS Zone.

When you created (or when Azure auto-created) the Private DNS Zone privatelink.blob.core.windows.net, Azure registered it on this internal platform. The SOA record for that zone therefore points to azureprivatedns.net as the primary name server and azureprivatedns-host.microsoft.com as the responsible address — both of which are fully owned and operated by Microsoft.

Breaking down your nslookup output line by line:

Your query went to your on-premises DNS server (europednssrv.fabrikam.net at 10.255.17.30), which tried to resolve mycoolstorage.privatelink.blob.core.windows.net but got an NXDOMAIN response (not found). This is because your on-premises DNS server does not know about your Azure Private DNS Zone it cannot reach the Azure internal resolver. The SOA record it returned simply tells you that azureprivatedns.net is the rightful authority for privatelink.blob.core.windows.net, and that Azure holds the answer but your current DNS path cannot get to it.

Why you are getting NXDOMAIN — the real issue to fix:

The NXDOMAIN result tells us your DNS resolution path is broken for private endpoint resolution. Here is why this typically happens and how to fix it:

Confirm your VNet is linked to the Private DNS Zone. Go to Azure Portal → Private DNS Zones → privatelink.blob.core.windows.net → Virtual network links and check that your VNet is listed there with Auto registration or at minimum as a linked VNet. If your VNet is not linked, Azure's internal resolver (168.63.129.16) will not be able to answer queries for that zone.

  1. Check where your VMs are pointed for DNS. Go to Azure Portal → Virtual Network → your VNet → DNS servers. If it is set to your on-premises DNS (europednssrv.fabrikam.net), queries for private endpoints never reach Azure's resolver at 168.63.129.16. You need to configure your on-premises DNS server to forward queries for privatelink.blob.core.windows.net to Azure's resolver 168.63.129.16 this is the standard hybrid DNS setup for Private Endpoints.

Set up conditional forwarding on your on-premises DNS server. On europednssrv.fabrikam.net, create a conditional forwarder for:

Zone: privatelink.blob.core.windows.net
Forward to: 168.63.129.16

This tells your on-premises DNS — whenever someone asks for anything under privatelink.blob.core.windows.net, forward that query to Azure's internal resolver instead of trying to resolve it yourself. This single change will fix the NXDOMAIN you are seeing.

Verify the A record exists in the Private DNS Zone. Go to Azure Portal → Private DNS Zones → privatelink.blob.core.windows.net → Record sets and confirm that an A record for mycoolstorage exists pointing to the private IP of your Private Endpoint. If the A record is missing, the Private Endpoint was not properly linked to the Private DNS Zone — go to your Private Endpoint resource and check its DNS configuration tab.

Test again after the fix. From a VM inside the linked VNet, run:

nslookup mycoolstorage.privatelink.blob.core.windows.net

This time it should return the private IP address (e.g., 10.x.x.x) of your storage account's Private Endpoint — not NXDOMAIN.

As a helpful tip azureprivatedns.net showing up in your SOA record is actually a good sign. It confirms that Azure has correctly registered the Private DNS Zone on its internal platform. The only remaining piece is making sure your DNS resolution path can reach Azure's resolver, which the conditional forwarder in Step 3 above will fix. For the full reference on hybrid DNS setup with Private Endpoints, see https://learn.microsoft.com/en-us/azure/private-link/private-endpoint-dns

If this answer helps you kindly accept the answer which will help others who have similar questions.

Best Regards,

Jerald Felix.

Was this answer helpful?

1 person found this answer helpful.
0 comments

Answer accepted by question author

AI answer

2026-05-26T10:16:21.6966667+00:00

azureprivatedns.net is the internal authoritative DNS infrastructure that Azure uses to host and serve Azure Private DNS zones.

When a private DNS zone is created (for example, privatelink.blob.core.windows.net), Azure stores and serves that zone as a global Azure resource. Internally, the SOA (start-of-authority) record for such a zone points to azureprivatedns.net as the primary name server and to azureprivatedns-host.microsoft.com as the responsible mail address. This indicates that Azure’s private DNS platform is the authority for that zone and handles its replication, resiliency, and responses.

In the nslookup -debug output, the line:

primary name server = azureprivatedns.net

shows that the SOA for privatelink.blob.core.windows.net is hosted on Azure’s private DNS infrastructure. This is how Azure implements Private DNS zones under the hood:

  • Private DNS zones (such as privatelink.blob.core.windows.net) are stored as global resources and are not tied to a single VNet or region.
  • Virtual networks are linked to these private zones so that VMs and other resources in those VNets can resolve records from the zone.
  • The internal Azure DNS service (azureprivatedns.net) is the authoritative platform that answers those private queries.

So, azureprivatedns.net is not a zone that needs to be created or managed. It is the internal authoritative name server domain used by Azure to host and serve Azure Private DNS zones, including the privatelink.* zones used by Private Endpoints.

References:

AI-generated content may be incorrect. Read our transparency notes for more information.

Was this answer helpful?

0 additional answers

Sort by: Most helpful
Most helpful Newest Oldest

Your answer

Answers can be marked as 'Accepted' by the question author and 'Recommended' by moderators, which helps users know the answer solved the author's problem.