Before Azure, understand the basic idea of DNS itself.

DNS stands for Domain Name System. It is a giant, worldwide, shared directory that connects human-friendly names to the numeric addresses that computers use. Every device on a network, including servers and websites, has an IP address such as 20.50.10.5. Typing a number like that into a browser every time would be painful, so we use names instead.

When you type a website name into a browser, your device quietly asks a DNS server, “What is the address for this name?” The server answers with a number, and then your device connects to that number. All of this takes a few milliseconds, and you never see it happen.

Azure DNS is a hosting service for DNS records, running on Microsoft’s global network.

Azure DNS lets you host your DNS zones and records inside Azure. A zone is a container that holds all the DNS records for one domain name, such as example.com. By hosting the zone in Azure, the answers to questions about your names are served from Microsoft’s worldwide network of name servers, which are the machines that answer DNS questions.

It is important to know what Azure DNS does not do. It does not sell or register domain names. You buy a domain name from a domain registrar, which could be Microsoft’s App Service Domains or any other registrar. Azure DNS then hosts the records for that domain after you point the registrar to Azure’s name servers.

A handful of words explain almost everything in DNS.

Reading a name from right to left

A domain name is read from right to left. In shop.example.com, the last part, com, is the top-level domain. Next comes example, the domain you own. Then shop, a subdomain you created. This structure forms a tree, and each level is managed by different servers.

Follow one question from your device all the way to the answer.

When your device wants the address of shop.example.com, it does not know the answer itself. A chain of helpers works together to find it.

sequenceDiagram
  participant D as User Device
  participant R as Resolver
  participant Root as Root Servers
  participant TLD as com Servers
  participant AZ as Azure DNS Name Servers
  D->>R: Address of shop.example.com?
  R->>Root: Who handles com?
  Root-->>R: Ask the com servers
  R->>TLD: Who handles example.com?
  TLD-->>R: Ask the Azure DNS name servers
  R->>AZ: Address of shop.example.com?
  AZ-->>R: Here is the address
  R-->>D: Here is the address
        

Public zones make your names reachable by anyone on the internet.

A public DNS zone in Azure DNS holds the records for an internet-facing domain. When you create one, Azure assigns your zone a set of name servers, typically four, with names that end in azure-dns.com, azure-dns.net, azure-dns.org, and azure-dns.info. Spreading them over different top-level domains adds resilience.

Steps to put a domain on Azure DNS

flowchart LR
  REG["Domain Registrar"] -->|Name server delegation| NS["Azure DNS Name Servers"]
  NS --> Z["Public Zone: example.com"]
  Z --> A["www points to web app"]
  Z --> B["mail points to mail service"]
  Z --> C["api points to API gateway"]
        

Delegating a subdomain

You can also host just a part of a domain in Azure DNS. For example, your main domain may live elsewhere, but you want Azure to manage cloud.example.com. You create a zone named cloud.example.com in Azure and then add records in the parent zone that point to Azure’s name servers for that subdomain. This is called delegation.

Each record type answers a different kind of question.

Alias records connect your DNS name directly to an Azure resource.

A normal A record holds a fixed IP address. If that address changes, your record becomes wrong, and visitors may be sent to a dead end. An alias record instead points to an Azure resource itself, such as a public IP address, a Traffic Manager profile, or a Content Delivery Network endpoint. When the resource’s address changes, the alias record follows automatically.

Private zones give friendly names to machines that must stay hidden from the internet.

Inside your Azure Virtual Networks, machines have private IP addresses such as 10.0.1.4. Remembering those is as hard as remembering phone numbers. Azure DNS Private Zones let you give private machines and services readable names like db01.internal.example.com. These names only resolve inside the virtual networks you link to the zone. Outsiders on the internet cannot see them.

Virtual network links

A private zone does nothing until you connect it to a virtual network through a virtual network link. Only networks linked to the zone can resolve its names. One private zone can be linked to many virtual networks, which is useful for sharing the same names across several networks.

Auto-registration

When you link a virtual network with auto-registration turned on, virtual machines in that network automatically get a record created in the zone, and the record is removed when the machine is deleted. This removes a lot of manual work. A virtual network can have only one registration link, but it can have several resolution-only links.

flowchart TD
  PZ["Private Zone: internal.example.com"] --- L1["Link with auto-registration"]
  PZ --- L2["Link for resolution only"]
  L1 --- V1["VNet A: VMs register their names"]
  L2 --- V2["VNet B: can look up names in the zone"]
  V1 --> M1["vm1.internal.example.com"]
  V1 --> M2["vm2.internal.example.com"]
  V2 -->|Resolves| M1
        

Machines in a VNet need a resolver, and there are a few options to choose from.

Every Azure virtual network has access to a built-in resolver at a special address, 168.63.129.16. It is a virtual public address that exists in all virtual networks and is reachable only from inside Azure. It is also called Azure-provided DNS. By default, machines use it automatically.

Hybrid companies need names to work in both the cloud and the office.

Many organizations keep some servers in their own data centers and others in Azure. Machines on one side often need to find names that live on the other. Before the Private Resolver, teams ran DNS server virtual machines in Azure just to forward questions back and forth. Azure DNS Private Resolver replaces that with a managed service.

Main building blocks

flowchart LR
  subgraph OP["On-premises Office"]
    ODNS["Office DNS Servers"]
  end
  subgraph AZ["Azure"]
    IN["Inbound Endpoint"]
    OUT["Outbound Endpoint with Rules"]
    PZ["Private DNS Zones"]
    VMS["Virtual Machines"]
  end
  ODNS -->|Questions about Azure names| IN
  IN --> PZ
  VMS --> OUT
  OUT -->|Questions about office names| ODNS
        

Private endpoints depend on DNS to work correctly.

When you create a private endpoint for a service like a storage account or database, the service gets a private address inside your virtual network. But applications still use the normal service name, such as an account name ending in a Microsoft domain. DNS must return the private address instead of the public one for machines inside your network.

Azure solves this by using special private zones with names that start with the label “privatelink”. When you link the right private zone to your virtual network, names inside the network resolve to the private address, while the same names on the public internet still resolve to the public address.

sequenceDiagram
  participant App as Application in VNet
  participant AzDNS as Azure-provided DNS
  participant PZ as privatelink Private Zone
  participant PE as Private Endpoint
  App->>AzDNS: Address of the storage service name?
  AzDNS->>PZ: Check linked private zone
  PZ-->>AzDNS: Private address of the endpoint
  AzDNS-->>App: Private address
  App->>PE: Connect privately
        

DNS is the front door that connects people to many Azure services.

flowchart TD
  U["User types www.example.com"] --> DNS["Azure DNS Zone"]
  DNS --> TM["Traffic Manager"]
  DNS --> FD["Front Door"]
  DNS --> PIP["Public IP Address"]
  TM --> E1["Endpoint in Region 1"]
  TM --> E2["Endpoint in Region 2"]
  FD --> WA["Web App"]
  PIP --> LB["Load Balancer"]
        

DNS controls where users go, so protecting it protects your whole business.

If an attacker can change your DNS records, they can send your customers to a fake website, intercept email, or take your service offline. That is why DNS security matters as much as any other part of your system.

Understanding caching explains why DNS changes do not always appear instantly.

Because answers are remembered by resolvers for the TTL period, a change you make in Azure DNS may not be seen by everyone at once. If a record had a TTL of one hour, some resolvers may keep giving the old answer for up to an hour after you change it.

When a name does not work, a calm checklist usually finds the cause.

What you can watch

A simple troubleshooting path

Azure DNS is usually inexpensive, but it helps to know what you pay for.

Azure DNS pricing is generally based on the number of hosted zones and the number of queries received. Private zones are billed in a similar way, with their own pricing. Services around DNS, such as the Private Resolver, are billed separately based on their endpoints and the queries they process.

See how different organizations use Azure DNS every day.

It helps to know where Azure DNS fits among similar tools.

An honest look helps you decide with open eyes.

Habits that keep your DNS tidy, safe, and predictable.

No. Azure DNS hosts the records for a domain but does not sell domains. You buy the domain from a registrar, which can be Microsoft’s App Service Domains or another company, and then point it to Azure DNS name servers.

A public zone answers questions from anyone on the internet and needs delegation from your registrar. A private zone answers only questions coming from virtual networks that you link to it, and is used for internal names.

The bare domain, called the zone apex, must hold required records such as NS and SOA, and DNS rules do not allow a CNAME to coexist with other records. Azure’s alias records get around this by pointing the apex directly at certain Azure resources.

Resolvers remember answers for the TTL period, so some of them keep the old answer until it expires. Lowering the TTL before planned changes shortens the delay.

Only if you need names to resolve between Azure and other networks, such as an on-premises office, or you need advanced forwarding. If everything lives inside Azure and you use private zones with Azure-provided DNS, you often do not need it.

Most often the DNS part is missing. The name must resolve to the private address from inside your network. Check that the correct privatelink zone exists, that it is linked to the virtual network, and that machines use a resolver path that reaches it.

No. DNS only tells a client which address to connect to. A load balancer actually receives traffic and spreads it across servers. DNS-based tools such as Traffic Manager can steer users to different endpoints, but they do not carry the traffic themselves.

Use role-based access control to limit who can edit, apply resource locks to important zones and record sets, and monitor the activity log for changes. Managing zones through reviewed templates adds another layer of safety.

Azure DNS is Microsoft’s cloud service for hosting DNS zones and records. It does not register domains, but once you point your registrar to its name servers, it answers questions about your names from a fast, global network. Public zones serve the internet, private zones serve linked virtual networks, and the Private Resolver connects Azure to on-premises name systems. Alias records keep names in step with Azure resources, even at the bare domain. Because DNS decides where users and applications go, it must be protected with careful permissions, locks, logs, and good housekeeping. Plan your naming, TTLs, and private DNS design early, and DNS will quietly do its job in the background.