What is DNS and How Does It Work in Azure?

What You'll Learn

You'll learn what DNS does, how name resolution works, what Azure DNS zones are, and which DNS record types you need to know for real-world Azure deployments.

Prerequisites

You should understand what an IP address is — a number that identifies a computer on a network. This guide explains how DNS translates names into those numbers.

The Problem DNS Solves

Think of DNS as a phone book for the internet.

You know someone's name (like google.com), but to actually connect to them, you need their phone number (their IP address, like 142.250.80.46). DNS is the system that translates names into numbers so you don't have to memorize IP addresses.

Without DNS, you would need to remember that YouTube is at 172.217.164.206, Gmail is at 142.250.185.37, and your company's internal database server is at 10.0.2.15. That's not realistic.

DNS lets you use names that make sense to humans. The computer translates those names into IP addresses behind the scenes.

How DNS Resolution Works

Here's what happens when you type "google.com" in your browser:

1. Your computer asks a question: "What's the IP address for google.com?"
2. It checks its local cache first. If you visited google.com recently, your computer already knows the IP address and uses that. If not, it moves to step 3.
3. It asks a DNS resolver. This is usually a server run by your internet provider (ISP) or a public DNS service like 8.8.8.8 (Google's DNS). The resolver does the heavy lifting.
4. The resolver follows a chain of DNS servers:
   • It asks the root DNS servers: "Who handles .com domains?"
   • The root server says: "Ask the .com nameservers."
   • It asks the .com nameserver: "Who handles google.com?"
   • The .com nameserver says: "Ask Google's authoritative DNS servers."
   • It asks Google's DNS server: "What's the IP for google.com?"
   • Google's server responds: "142.250.80.46"
5. The IP address comes back to your browser. Your browser connects to that IP address and loads the website.

This happens in milliseconds. The results are cached at multiple levels so repeated lookups are instant.

DNS Record Types Explained

DNS zones store different types of records. Each record type serves a specific purpose. Here are the most common ones you'll work with in Azure.

A Record

Maps a domain name to an IPv4 address.

Example:

• google.com → 142.250.80.46
• webapp.contoso.com → 20.112.45.78

Use this when you want a name to point to a specific server's IP address. Most web servers, VMs, and public-facing services use A records.

CNAME Record

Maps a domain name to another domain name (an alias).

Example:

• www.contoso.com → contoso.com
• blog.contoso.com → contoso.azurewebsites.net

Use this when you want one name to point to another name instead of directly to an IP. This is helpful because if the IP address of contoso.com changes, the CNAME still works — you don't have to update every alias.

Important: A CNAME cannot be used for the root domain (like contoso.com itself). It only works for subdomains (like www.contoso.com or blog.contoso.com).

MX Record

Tells email servers where to deliver email for your domain.

Example:

• contoso.com MX record → mail.contoso.com (priority 10)

Use this to route email. The priority number matters — lower numbers are tried first. You can have multiple MX records for redundancy.

TXT Record

Stores arbitrary text data. Often used for domain verification and email security (SPF, DKIM, DMARC).

Example:

• contoso.com TXT record → "v=spf1 include:_spf.google.com ~all"

Use this when a service asks you to "prove you own this domain" by adding a specific text value to your DNS. Microsoft 365, Google Workspace, and many SaaS tools use TXT records for verification.

NS Record

Specifies which DNS servers are authoritative for your domain.

Example:

• contoso.com NS records → ns1-azure.com, ns2-azure.com

You don't usually create these manually — they're automatically set when you create a DNS zone. They tell the world which DNS servers know the truth about your domain.

Azure DNS Zones

An Azure DNS zone is where you manage DNS records for a domain.

Instead of managing DNS at your domain registrar (like GoDaddy or Namecheap), you can manage it in Azure. You create a DNS zone in Azure, point your domain's nameservers to Azure's DNS servers, and then manage all your A records, CNAME records, and other DNS entries directly in the Azure portal.

Why use Azure DNS?

• Your DNS records live in the same place as your Azure resources (VMs, App Services, etc.)
• You can automate DNS updates using ARM templates, Bicep, or Azure CLI
• Integration with Azure Private DNS for internal name resolution
• High availability and global distribution built in

Azure DNS supports two types of zones: public DNS zones and private DNS zones.

Public DNS Zones

A public DNS zone hosts DNS records for a domain that's accessible from the internet.

Example: You own contoso.com. You create a public DNS zone in Azure for contoso.com and add these records:

• contoso.com A record → your web server's public IP
• www.contoso.com CNAME → contoso.com
• api.contoso.com A record → your API server's public IP

Anyone on the internet can look up these names and get the IP addresses.

Use case: Hosting the DNS for your public-facing website or application.

Private DNS Zones

A private DNS zone provides name resolution for resources inside your Azure virtual networks.

These names are NOT resolvable from the internet. Only resources inside linked VNets can resolve them.

Example: You create a private DNS zone called internal.contoso.com and link it to your VNet. You add these records:

• db-server.internal.contoso.com → 10.0.2.5 (a VM's private IP)
• app-server.internal.contoso.com → 10.0.1.10

Now your VMs can connect to db-server.internal.contoso.com instead of memorizing 10.0.2.5. If the VM's IP changes, you update the DNS record and everything still works.

Use case: Internal naming for VMs, databases, and services that don't need to be reachable from the internet.

When to Use Azure Private DNS Zones

Here's the scenario: You have VMs in an Azure VNet. They need to talk to each other. You could use IP addresses, but IPs are hard to remember and they can change.

Azure provides default DNS for VNets (VM names resolve to something like vm1.internal.cloudapp.net), but what if you want custom names like db-server.mycompany.local or api.internal.contoso.com?

That's when you create a private DNS zone.

Steps:

1. Create a private DNS zone (like internal.contoso.com).
2. Link the DNS zone to your VNet.
3. Add DNS records for your VMs and services.
4. (Optional) Enable auto-registration so Azure automatically creates DNS records when VMs are created.

Now your VMs can resolve each other by name without you configuring anything on each VM. The private DNS zone acts like an internal phone directory.

Key feature: Auto-registration When you link a private DNS zone to a VNet and enable auto-registration, Azure automatically creates A records for VMs in that VNet. When a VM is created, its name and private IP are registered in the DNS zone. When the VM is deleted, the record is removed.

This is powerful for environments where VMs are created and destroyed frequently. You don't have to manually manage DNS records.

Common Mistakes

Confusing public and private DNS zones. Public zones are for internet-facing domains. Private zones are for internal names only your Azure resources can resolve. You can't use a private DNS zone to host your company's website.

Forgetting to link a private DNS zone to a VNet. Creating a private DNS zone is not enough. You must link it to at least one VNet. If you don't link it, resources in your VNet can't resolve the names.

Not understanding DNS propagation delay. When you create or update DNS records in a public DNS zone, the changes aren't instant everywhere. DNS resolvers cache records based on TTL (time to live). If your TTL is 3600 seconds (1 hour), it can take up to an hour for the change to propagate globally. This is not an Azure problem — it's how DNS works.

Using IP addresses instead of DNS names. Hard-coding IP addresses in your application makes your infrastructure fragile. If the IP changes (because you redeployed a VM or moved a service), your app breaks. Use DNS names. Update the DNS record when the IP changes, and your app keeps working.

What's Next

DNS is a foundational networking concept. Once you understand how it works, you'll see it everywhere in Azure:

• Custom domain names for App Service — You use a CNAME record to map www.contoso.com to your App Service's default domain (contoso.azurewebsites.net).
• Azure Front Door and Traffic Manager — Both use DNS to route traffic globally.
• Private endpoints — When you create a private endpoint for a storage account or SQL database, Azure automatically creates a DNS record in a private DNS zone so your VMs can resolve the private endpoint by name.

Understanding DNS makes configuring these services easier. You're not just following steps — you know why each DNS record matters.

This maps directly to the AZ-104 "configure name resolution" objective. The exam tests whether you understand when to use public vs private DNS zones, how to link a private DNS zone to a VNet, and how auto-registration works.