Azure DNS: hosting the phone book, public and private
Every connection your systems make starts with a question: what IP address is this name? Answering that question, reliably and fast, for both the public internet and the private world inside your virtual network, is the entire job of Azure DNS — and it is astonishing how many "the network is down" incidents are really "the name did not resolve" in a trench coat.
The Domain Name System is the internet's phone book: it "translates (resolves) a service name to an IP address." Azure DNS is Microsoft's managed service for hosting your DNS zones and answering those lookups, using Azure's global network of name servers. You bring your domain and your records; Azure runs the highly available infrastructure that serves them. No DNS servers to patch, no zone files to hand-edit on a box at 3am.
Hosting is not registering — keep them straight
The first thing to get right, because it trips people up constantly: Azure DNS hosts domains, it does not register them. Registering yourcompany.com — claiming the name — is what you do at a domain registrar. Hosting it is running the name servers that answer questions about that name. You register the domain somewhere, then point it at Azure DNS by delegating it, and from then on you manage your records — the A records, CNAMEs, MX, TXT — in Azure with the same credentials, APIs, tools, and billing as the rest of your Azure estate. That last part is the quiet win: your DNS stops being a separate silo with its own login.
Two zones for two worlds
Azure DNS answers to two very different audiences, and it splits into two zone types to serve them:
- Public DNS zones — for internet-facing names. This is what tells the whole world that
www.yourcompany.comlives at a particular IP. Anyone, anywhere, can resolve these. - Private DNS zones — for names that only make sense inside your virtual networks. Azure Private DNS resolves domain names within a VNet "without the need to configure a custom DNS solution." It is how one VM finds another by a friendly name instead of a brittle IP, and it can autoregister your VMs' records for you so the phone book stays current on its own.
Public zones answer the internet. Private zones answer your virtual network. Most hybrid networking pain is one of these two failing to answer at all.
Why hybrid networking is secretly a DNS problem
Connect an on-premises datacenter to Azure and you will discover a hard truth: the tunnel is the easy part. The moment your on-prem servers need to resolve an Azure private name — or your Azure VMs need to resolve an on-prem one — you are in name-resolution territory, and that is where hybrid projects quietly stall. Azure's answer is the DNS Private Resolver, a managed service that lets you query Azure private zones from on-premises and vice versa "without deploying VM based DNS servers." Before it existed, teams ran their own DNS forwarder VMs just to bridge the two worlds — a fiddly, patch-hungry box that broke at the worst times. The Private Resolver retires that chore. If you remember one thing about hybrid, remember that half of it is DNS.
Beyond public and private zones and the Private Resolver, the same product line includes Traffic Manager, a DNS-based load balancer that steers users across regions by handing back different answers, and DNS Security Policy, which can filter and log DNS queries at the virtual-network level and block known-malicious domains at resolution time. Same phone book, extra powers: routing and a security checkpoint, both expressed through the humble DNS lookup.
The takeaway
Azure DNS is managed hosting for your DNS zones on Microsoft's global network — it answers the question "what IP is this name?" so you do not run name servers yourself. Use public zones for internet-facing domains and private zones for names inside your virtual networks, remember that hosting is not the same as registering, and reach for the DNS Private Resolver the moment on-prem and Azure need to resolve each other's names. "Public zones for the outside, private zones plus the Private Resolver for the hybrid inside, and check DNS first when something 'cannot connect'" is the answer of someone who has debugged enough outages to know where they usually start.