# Azure DNS

> Source: Courseiva IT Certification Glossary — https://courseiva.com/glossary/azure-dns

## Quick definition

Azure DNS is a Microsoft service that stores the address book for your website or app. When someone types your domain name (like mysite.com), Azure DNS quickly looks up the right IP address and directs them to your server. It works like a phonebook for the internet, but you don't have to manage your own servers.

## Simple meaning

Imagine you want to visit a friend's new house, but you only have their name, not their street address. You would look up their name in a phonebook or a contact list on your phone. That list gives you the exact street address so you can drive there. Azure DNS works very much like that phonebook, but for the internet.

When you create a website or an app, it lives on a server that has a unique set of numbers called an IP address (like 192.168.1.1). Numbers are hard for people to remember. Instead, we use domain names like "www.mycoolexample.com." Azure DNS is the service that holds the records connecting these easy-to-remember names to the underlying numerical IP addresses.

You can think of Azure DNS as a massive, super-reliable phonebook that is spread across the globe. When someone types your domain name into their browser, their computer asks Azure DNS, "What is the IP address for www.mycoolexample.com?" Azure DNS quickly checks its records and sends back the correct IP address. The browser then uses that address to load your website.

One of the biggest benefits is that you don't need to buy and maintain your own DNS servers. Microsoft handles all the heavy lifting, like keeping the servers running, protecting them from cyberattacks, and making sure they are fast no matter where in the world the request comes from. You just manage the records through a simple dashboard or command line, and Azure takes care of the rest.

Because Azure DNS is part of Microsoft Azure, it works especially well if your website or app is already hosted in Azure. You can link your domain name directly to other Azure resources, like virtual machines or web apps, with just a few clicks. This makes the whole process of getting your site online much smoother and faster.

## Technical definition

Azure DNS is a cloud-based Domain Name System (DNS) hosting service that provides name resolution using Microsoft Azure's global network of authoritative DNS servers. It is a fully managed service, meaning that Microsoft handles the operational overhead of maintaining the DNS infrastructure, including server patching, scaling, and high availability. The service is based on the standard DNS protocol (RFC 1035) and supports common DNS record types including A, AAAA, CNAME, MX, NS, PTR, SOA, SRV, and TXT records.

Azure DNS uses an anycast network. Anycast routing means that DNS queries are automatically routed to the nearest DNS server in Microsoft's global network. This reduces latency and improves query response times because the user's request does not have to travel across the world. The service is backed by a Service Level Agreement (SLA) that guarantees 100% availability for valid DNS queries, provided you have configured at least two name servers for your zone.

To use Azure DNS, you first create a DNS zone. A DNS zone is a container that holds the DNS records for a specific domain (for example, "example.com"). When you create the zone in Azure, Microsoft automatically assigns a set of Azure name servers (for example, ns1-01.azure-dns.com, ns2-01.azure-dns.net, etc.). You must then configure your domain registrar to use these Azure name servers for your domain. This delegation process is critical: without it, the outside world will not know to ask Azure for your DNS records.

Inside the DNS zone, you create recordsets. Each recordset contains one or more DNS records of the same type and name. For example, you can have a single A record that maps "www.example.com" to the IP address of your web server. You can also create alias records, which are a special Azure feature. Alias records allow you to point a domain name directly to an Azure resource (like a Traffic Manager profile, an Azure CDN endpoint, or an Azure front door) without needing to manage the underlying IP address. If the underlying resource's IP address changes, Azure DNS automatically updates the alias record.

Azure DNS supports both public DNS zones (visible to everyone on the internet) and private DNS zones (visible only within a specific virtual network). Private DNS zones are essential for internal name resolution in Azure environments. For instance, you can create a private zone for "internal.contoso.com" and link it to multiple virtual networks. Virtual machines in those networks can then resolve hostnames to private IP addresses without needing a custom DNS server.

Security is handled through Azure Role-Based Access Control (RBAC). You can grant granular permissions to different users or automation accounts. For example, you can give a developer permission to create DNS records in a test zone but no access to production zones. Azure DNS also integrates with Azure Policy, allowing you to enforce naming conventions or restrict the types of records that can be created.

In terms of monitoring, Azure DNS logs query metrics and can send alerts if query volumes drop suddenly, which could indicate a delegation problem. You can also enable diagnostic logging to capture details about every DNS query received by your zone.

From an IT professional's perspective, Azure DNS replaces the need to run on-premises DNS servers for internet-facing domains. It offers built-in redundancy, global scale, and tight integration with other Azure services. It supports DNSSEC but only by manually importing signed zones; it does not automatically sign zones. It also supports custom name servers for advanced scenarios.

When implementing Azure DNS, best practices include using alias records whenever possible to reduce manual updates, separating production and test zones, and using multiple name server addresses during delegation for redundancy. The service is billed based on the number of DNS zones hosted and the number of DNS queries received, with no upfront costs.

## Real-life example

Think of Azure DNS like the headquarters of a massive international shipping company. Imagine you want to send a package to a friend in another country. You don't know their exact street address, but you know their home city and their name. You write their name and city on the package and give it to your local shipping office. That local office quickly routes it to the correct regional hub, which then sends it to the city's local delivery center, and finally, it gets delivered to your friend's door.

In this analogy, your friend's name and city together are like the domain name (www.myfriend.com). The shipping office is your local internet service provider. The regional hub and delivery center are the Azure DNS servers spread around the world. Your friend's exact street address represents the IP address of the server where their website or app lives.

Now, instead of a shipping company, Azure DNS is the database that holds the master list of all the street addresses for all the names. So when you type your friend's name into a browser, your computer sends a query asking for the address. Azure DNS, being the central directory, instantly provides the correct street address (the IP address). The shipping company (your internet connection) then takes that address and delivers your request directly to the destination.

If your friend moves to a new house (changes their server IP address), they only need to update their address in the Azure DNS directory. You don't need to tell everyone in the world about the move. The next time someone looks up the name, Azure DNS will provide the new address automatically. This is exactly what happens when you update a DNS record in Azure: you change the IP address mapping, and within minutes, the whole world sees the new address.

Azure DNS also acts like a global directory. If you are in Tokyo and your friend is in New York, the request still goes through the local Azure DNS server in Tokyo, which already has a copy of the address book. It doesn't have to travel to New York to get the IP address. This is the anycast feature in action, making the lookup fast no matter where you are.

Finally, imagine you have multiple friends who share the same apartment building. You could give everyone the same street address but with different apartment numbers. In DNS terms, that is like having multiple records of different types (A, AAAA, MX) pointing to different services but at the same IP address or same domain name. Azure DNS manages all these different types of entries in one convenient place.

## Why it matters

For IT professionals, DNS is often called the "phonebook of the internet," and it is critical for any online service. If your DNS is slow or goes down, your entire website or application becomes unreachable, no matter how well-optimized your servers are. Azure DNS matters because it offloads the burden of managing DNS infrastructure to Microsoft. You no longer need to configure and maintain physical or virtual DNS servers, apply security patches, or worry about scaling during traffic spikes.

Azure DNS also directly impacts user experience. With its anycast network, DNS queries are resolved from the nearest location, reducing the time it takes for a user's browser to find your site. Faster DNS resolution contributes to faster page loads, which influences customer satisfaction and even SEO rankings.

From a cost perspective, Azure DNS follows a pay-as-you-go model. You pay only for the zones you host and the queries you receive. There are no hardware costs or licensing fees. For small businesses, this can be a significant savings compared to running even a single extra server. For large enterprises, the ability to easily manage thousands of zones through a single interface and API is invaluable.

Security is another major reason Azure DNS matters. DNS servers are frequent targets of Distributed Denial of Service (DDoS) attacks. Azure DNS is built on Azure's global infrastructure, which includes built-in DDoS protection at the network layer. This means your DNS service is more resilient to attacks than a typical on-premises setup.

Finally, for organizations already using Azure for other services, Azure DNS integrates seamlessly. You can use alias records to point directly to Azure load balancers, web apps, or CDN endpoints without manually tracking IP addresses. This integration reduces human error and saves time during deployments or migrations.

## Why it matters in exams

Azure DNS is directly covered in several Microsoft Azure certification exams, particularly the AZ-104 (Microsoft Azure Administrator) and the Azure Fundamentals (AZ-900) exam. For the AZ-104 exam, you need to understand how to configure and manage DNS zones, create record sets, implement private DNS zones, and configure DNS settings for virtual networks. You may be asked about the steps to delegate a custom domain to Azure DNS or how to use alias records to point to Azure services.

In the Azure Fundamentals exam, Azure DNS often appears in questions about global infrastructure and high availability. You should know that Azure DNS uses anycast routing and that it provides fast name resolution globally. You also need to understand the difference between public and private DNS zones and when to use each.

For the AWS Cloud Practitioner and AWS Solutions Architect (SAA) exams, Azure DNS is not directly covered, but knowledge of DNS concepts (like A records, CNAME, MX) is transferable. However, the exam may compare Azure DNS with AWS Route 53. You might see a question that asks which Azure service is equivalent to Route 53 for DNS management.

The CompTIA Network+ and Security+ exams cover general DNS concepts, such as record types, resolution process, and security best practices like DNSSEC. While they do not test Azure-specific implementation details, understanding Azure DNS can help you apply these concepts in a cloud environment.

In the CCNA exam, DNS is part of network fundamentals. You may be asked about DNS resolution flow, authoritative and recursive servers, and the role of caching. If a question mentions a cloud-based DNS service, you should recognize it as a managed authoritative DNS offering.

For the Google Cloud certifications (ACE, Cloud Digital Leader), the concepts are similar but the service name differs (Cloud DNS). The exam will expect you to know that Azure DNS provides global resolution, integration with other Azure services, and supports standard record types.

Exam questions often test your ability to troubleshoot DNS resolution failures. You might be given a scenario where a website cannot be reached even though the server is running, and you must identify that the DNS delegation is incorrect or that an A record is missing. Another common question type involves choosing the correct record type for a specific requirement, such as using an MX record for email routing.

Because Azure DNS is a pillar topic, expect at least a few questions on the AZ-104 exam that require hands-on knowledge, such as creating a private DNS zone and linking it to a virtual network, or configuring an alias record to point to a Traffic Manager profile.

## How it appears in exam questions

Azure DNS appears in exam questions in several predictable patterns. The most common is scenario-based, where you are given a description of a problem or requirement and asked to choose the correct Azure DNS configuration. For example:

Scenario type: You host a web application in Azure. You have a custom domain name purchased from a third-party registrar. Users report that they cannot reach the site. The application is running fine. What is the most likely cause? The correct answer might be that the DNS delegation is not configured correctly, meaning the registrar still points to its own name servers instead of Azure DNS name servers.

Configuration type: You need to ensure that internal virtual machines can resolve the hostname "files.contoso.com" to a private IP address within the same virtual network. Which two actions should you perform? The answer involves creating a private DNS zone for "contoso.com" and linking the virtual network to the zone.

Troubleshooting type: After deploying a new web app, you create an A record in Azure DNS pointing to the web app's public IP address. However, users still see an old website. What is the most likely issue? The answer could be that you did not update the Time-to-Live (TTL) value, causing client DNS caches to still use the old IP address.

Another pattern involves alias records. A question may state: You need to point your custom domain to an Azure Traffic Manager profile. The Traffic Manager endpoint IP addresses may change over time. How should you configure the DNS record? The correct answer is to use an alias record, because it automatically updates if the underlying resource's IP changes.

Multi-service questions often combine Azure DNS with Azure Front Door or CDN. For example: You want to minimize latency for global users accessing your static website. You configure Azure CDN and need to point your custom domain to the CDN endpoint. What type of DNS record should you use? The answer is a CNAME record or an alias record.

For the CompTIA Network+ exam, you may see a question that asks which record type is used to resolve a hostname to an IPv6 address. That is the AAAA record. Azure DNS supports all standard record types, so the answer remains the same.

Finally, some questions test your knowledge of DNS resolution flow. They might ask: When a user types a domain name in their browser, which server does the query first contact? The answer is the recursive resolver, typically provided by the user's ISP, which then queries the authoritative DNS server (which could be Azure DNS). Understanding this flow is essential for troubleshooting questions.

## Example scenario

You are an IT administrator for a small company called "GreenLeaf Gardens." Your company has a website hosted on an Azure virtual machine. The website is accessed by customers at www.greenleafgardens.com. You purchased the domain from a registrar like GoDaddy or Namecheap. Currently, DNS is managed by the registrar, but you want to move it to Azure DNS because you plan to add more Azure services and want better integration.

First, you log into the Azure portal and create a new DNS zone called "greenleafgardens.com." After you create the zone, Azure shows you a list of four name servers, such as ns1-01.azure-dns.com, ns2-01.azure-dns.net, etc. You copy these name servers.

Next, you go to your domain registrar's website and change the name server settings for your domain. Instead of the registrar's default name servers, you enter the four Azure name servers. This step tells the entire internet: "To find the IP address for greenleafgardens.com, ask Azure DNS."

Now you need to create the actual record that points to your website. You go back to Azure DNS and create an A record. The name is "www" and the target is the public IP address of your Azure virtual machine (for example, 52.168.1.100). You set the TTL to 3600 seconds (one hour).

After a few minutes (depending on propagation), you type www.greenleafgardens.com into a browser, and it loads your website. You have successfully delegated your domain and configured DNS.

Later, your company decides to add an internal file-sharing site that only employees should access. You create a separate private DNS zone in Azure called "internal.greenleafgardens.com." You link this zone to your company's virtual network. You then add an A record for "files.internal.greenleafgardens.com" pointing to the private IP address of your file server (for example, 10.0.0.5). Now employees on the company network can access the file server by name, but the public cannot.

This scenario demonstrates the key steps: creating a public zone, delegating the domain, creating records, and using private zones for internal resolution.

## Common mistakes

- **Mistake:** Forgetting to update name servers at the registrar after creating a zone in Azure DNS.
  - Why it is wrong: Without updating the registrar, the DNS queries never reach Azure DNS. The domain still uses the old DNS provider, so any records you create in Azure are ignored.
  - Fix: After creating the zone in Azure, copy the four Azure name servers and paste them into the name server fields at your domain registrar. Then wait for propagation.
- **Mistake:** Using an A record with an IP address that is not static or may change frequently.
  - Why it is wrong: If the IP address of your resource changes, the A record becomes invalid and users cannot reach your site. You must manually update the record, which is error-prone.
  - Fix: Use an alias record instead of a regular A record when pointing to an Azure resource like a web app or Traffic Manager. Alias records update automatically if the target's IP changes.
- **Mistake:** Creating a public DNS zone but forgetting to link a private DNS zone to a virtual network.
  - Why it is wrong: A private DNS zone only works for virtual networks that are explicitly linked. If you forget to link the network, the VMs inside it cannot resolve the private names.
  - Fix: When you create a private DNS zone, go to the zone's settings, find the virtual network links option, and add the desired virtual network.
- **Mistake:** Setting TTL too high when you plan to make changes soon.
  - Why it is wrong: A high TTL means clients and intermediate DNS servers cache the old record for a long time. When you change the IP address, users will still see the old site for hours or days.
  - Fix: Before making a planned change, lower the TTL to 300 seconds (5 minutes) a few days in advance. After the change is stable, you can increase the TTL again.
- **Mistake:** Confusing CNAME records with A records for the root domain (e.g., example.com).
  - Why it is wrong: According to DNS standards, you cannot have a CNAME record at the zone apex (the root domain without a subdomain). Creating one will cause resolution failures for other DNS record types.
  - Fix: For the root domain, use an A or AAAA record (or an alias record of type A) instead of a CNAME. Use CNAME only for subdomains like www.example.com.
- **Mistake:** Not enabling diagnostic logging when troubleshooting DNS resolution issues.
  - Why it is wrong: Without logs, you cannot see which queries are hitting your Azure DNS zone. You might waste time checking other components while the problem is actually a missing DNS record.
  - Fix: Enable DNS query logging in the Azure portal for the DNS zone. Use the logs to see incoming queries, their source IPs, and whether the zone responded or not.

## Exam trap

{"trap":"The exam may present a scenario where a company has an existing on-premises DNS server and wants to use Azure DNS for both internal and external resolution. You might be tempted to create a single public zone and expect it to work for internal VMs.","why_learners_choose_it":"Learners may think that because both internal and external requests need to resolve the same domain name, a single public zone should handle both. They also might not understand the separation between public and private DNS zones.","how_to_avoid_it":"Remember that Azure DNS public zones are only accessible from the internet. For internal name resolution, you must create a separate private DNS zone and link it to the virtual network. The private zone can use the same domain name but with different records (e.g., private IP addresses). Always clarify the scope of the zone in exam questions: is it for internet users or internal users?"}

## Commonly confused with

- **Azure DNS vs Azure Traffic Manager:** Azure Traffic Manager is a DNS-based load balancer that routes traffic to different endpoints based on routing methods like performance, geographic, or priority. It is not a DNS hosting service itself. You use Azure DNS to host your domain and then configure CNAME or alias records to point to a Traffic Manager profile. (Example: If you want users in Europe to go to a European server and US users to a US server, you use Traffic Manager for routing, but Azure DNS for the actual name-to-IP mapping.)
- **Azure DNS vs Azure Front Door:** Azure Front Door is a global application delivery network that provides load balancing, SSL termination, and web application firewall. It also uses DNS at the edge. However, Front Door manages its own DNS resolution and does not replace the need for a separate DNS zone for your domain. You still use Azure DNS to point your domain to Front Door. (Example: You set up an alias record in Azure DNS pointing your domain to the Front Door endpoint. Front Door then handles the rest.)
- **Azure DNS vs Azure Private DNS:** Azure Private DNS is a feature within Azure DNS specifically for internal name resolution within virtual networks. It is not a separate service. The term "Azure DNS" usually refers to the overall service that includes both public and private zones. Confusion arises when someone says "Azure DNS" but only means the public internet-facing part. (Example: Public Azure DNS resolves example.com for everyone. Private Azure DNS resolves internal.example.com only for VMs in your virtual network.)
- **Azure DNS vs Azure Application Gateway:** Azure Application Gateway is a Layer 7 load balancer that operates based on HTTP/HTTPS traffic. It does not host DNS records. While it can use a DNS name for its frontend, it does not replace DNS hosting. You still need Azure DNS to map your custom domain to the Application Gateway's IP address or DNS name. (Example: You create a public IP for the Application Gateway, then add an A record in Azure DNS pointing your domain to that public IP.)
- **Azure DNS vs Windows Server DNS role:** Windows Server DNS is an on-premises DNS server that you install and manage yourself. Azure DNS is a fully managed cloud service. The on-premises version requires hardware, maintenance, patching, and manual high availability setup. Azure DNS handles all of that automatically. (Example: If you run a physical server in your office with the DNS role, you are responsible for its uptime. With Azure DNS, Microsoft guarantees 100% availability.)

## Step-by-step breakdown

1. **Create a DNS zone** — In the Azure portal, you navigate to the DNS zones service and create a new zone with your domain name (e.g., contoso.com). This zone becomes the container for all your DNS records. Azure automatically assigns four name servers to this zone and publishes them globally.
2. **Copy Azure name servers** — After the zone is created, the portal displays a list of name servers like ns1-01.azure-dns.com, ns2-01.azure-dns.net, etc. You need to copy these exactly. They serve as the authoritative servers that will answer queries for your domain.
3. **Delegate your domain** — Go to your domain registrar's website (where you bought the domain) and change the name server settings. Replace the existing name servers with the Azure ones. This tells the global DNS system that Azure DNS is now the authoritative source for your domain. Propagation can take up to 48 hours but often completes in minutes.
4. **Add DNS records** — Back in Azure DNS, add record sets. For a website, you typically create an A record mapping 'www' to the IP address of your web server. You can also add MX records for email, TXT records for verification, and CNAME records for aliases. Each record set has a name, type, TTL, and target.
5. **Test DNS resolution** — Use tools like nslookup, dig, or online DNS checkers to verify that your domain resolves correctly. Query the Azure name servers directly to ensure they return the correct records. For example: nslookup www.contoso.com ns1-01.azure-dns.com
6. **Configure private DNS (optional)** — If you need internal name resolution, create a private DNS zone. Specify the zone name (e.g., internal.contoso.com) and choose the visibility as private. Then create virtual network links to connect the zone to your Azure virtual networks. VMs in those networks can now resolve private hostnames.
7. **Set up alias records (optional)** — For resources like Azure Web Apps or Traffic Manager, create an alias record instead of a regular A record. In the record creation form, select 'Alias record set' and choose the target resource. Azure will automatically resolve the current IP address of that resource and update it if the resource's IP changes.
8. **Monitor and maintain** — Enable diagnostic logging for your DNS zone to see query metrics. Set up alerts for unusual changes, like a sudden drop in query count which might indicate a delegation failure. Regularly review records and remove any that are no longer in use.

## Practical mini-lesson

Azure DNS is a service that any IT professional working with Azure should understand deeply, because it is the foundation for connecting users to applications. In practice, you will rarely interact with it daily, but initial configuration must be done correctly to avoid outages.

When you first set up Azure DNS, the most critical step is delegation. Many people create the zone and add records but forget to update the registrar's name servers. This is the number one cause of "site not resolving" issues. Always verify delegation with a tool like whatsmydns.net or by querying the Azure name servers directly.

For production environments, always use alias records when pointing to Azure resources. For example, if you point your domain to an Azure Web App using a regular A record, and then later you scale up the web app or migrate to a different region, the public IP address may change. With a regular A record, your site will break until you manually update the record. With an alias record, Azure DNS handles the change automatically.

Another important consideration is TTL management. If you expect to change records soon, lower the TTL to 300 seconds a day before the change. After the change is complete and verified, you can increase the TTL again to reduce query costs and improve performance.

Private DNS zones are often overlooked. If you have multiple Azure services that need to communicate internally, a private DNS zone allows you to use friendly names instead of private IP addresses. For example, you can make a database server accessible as "db.internal.contoso.com" from any VM in your virtual network. Without a private zone, you would have to hard-code IP addresses, which breaks if the database server moves.

What can go wrong? Besides delegation issues, watch out for conflicting records. You cannot have a CNAME record at the zone apex, so do not try to create one for "contoso.com." Also, be careful with overlapping private zones: if you have two private zones with the same name in the same virtual network, resolution can become unpredictable.

For monitoring, use Azure Monitor to track query volume. A sudden drop might indicate that the delegation was changed accidentally. A sudden spike could be a DDoS attack, but Azure's built-in protection usually handles that.

Finally, remember that Azure DNS is not a web hosting service. It does not serve web pages. It only provides IP addresses. So if a user can resolve your name but still cannot load the site, the problem is elsewhere-likely the server or network connectivity.

## Commands

```
az network dns zone create --resource-group MyResourceGroup --name contoso.com
```
Creates a new DNS zone for a domain in Azure DNS under a specific resource group.

*Exam note: Tests understanding of zone creation syntax and the need to specify resource group and zone name, often contrasted with Azure Private DNS zones.*

```
az network dns record-set a add-record --resource-group MyResourceGroup --zone-name contoso.com --record-set-name www --ipv4-address 10.0.0.1
```
Adds an A record to an existing DNS zone, mapping a hostname to an IPv4 address.

*Exam note: Common exam question expects you to know the difference between `add-record` and `set-record`, and that A records are for IPv4 while AAAA is for IPv6.*

```
az network dns record-set cname set-record --resource-group MyResourceGroup --zone-name contoso.com --record-set-name blog --cname blog.contoso.net
```
Creates or updates a CNAME record to alias one domain to another.

*Exam note: Exams test that CNAME records cannot coexist with other record types at the same apex, and this command is used for subdomain aliasing.*

```
az network dns zone list --resource-group MyResourceGroup
```
Lists all DNS zones within a specific resource group.

*Exam note: Used in troubleshooting scenarios to verify zone creation; exam questions may ask about filtering zones by resource group or subscription.*

```
az network dns record-set ns show --resource-group MyResourceGroup --zone-name contoso.com --name @
```
Displays the name server (NS) records for the apex of a zone, typically used to verify delegation.

*Exam note: Tests knowledge that Azure DNS automatically creates NS and SOA records, and that these must be delegated at the registrar for public zones.*

```
az network dns record-set txt add-record --resource-group MyResourceGroup --zone-name contoso.com --record-set-name _acme-challenge --value "validation-token"
```
Adds a TXT record, commonly used for domain verification (e.g., Let's Encrypt or SPF).

*Exam note: Exams often include TXT records for email authentication (SPF, DKIM) or domain ownership verification in Azure services like App Service.*

## Troubleshooting clues

- **DNS resolution fails despite correct records** — symptom: Clients cannot resolve the domain, but records appear correctly in the Azure portal.. The domain may not be delegated to Azure DNS name servers. Azure provides name servers upon zone creation; if the registrar still points to old servers, resolution fails. (Exam clue: Questions often describe a scenario where a zone is created but resolution fails, testing that you must update NS records at the domain registrar.)
- **Changes to DNS records not propagating** — symptom: After updating a record, old values are still returned for hours.. Azure DNS uses the TTL (Time to Live) set on the record set. If TTL is high (e.g., 86400 seconds), caching resolvers retain old values until TTL expires. (Exam clue: Exam questions may ask why changes are delayed, requiring you to check the TTL value or suggest reducing it for faster propagation.)
- **Private DNS zone not resolving from virtual network** — symptom: VMs in a connected VNet cannot resolve names in a Private DNS zone.. The VNet must be linked to the private DNS zone using a virtual network link. Without the link, the VNet does not query the private zone. (Exam clue: Exam scenarios describe hybrid environments; you must add a 'virtual network link' with 'auto-registration' enabled if dynamic registration is needed.)
- **Unable to create a CNAME record at zone apex** — symptom: Azure portal shows error when trying to add a CNAME for 'contoso.com' (empty name).. DNS standards prohibit CNAME records at the zone apex (root domain) because the apex also has SOA and NS records. Use an ALIAS record (Azure-specific) instead. (Exam clue: Directly tests knowledge of RFC compliance: CNAMEs cannot coexist with other record types, and apex domains require A/AAAA or ALIAS records.)
- **Auto-registration not updating VM hostnames** — symptom: New VMs in a VNet do not appear as A records in the private DNS zone.. Auto-registration requires the VNet link to have 'registration enabled.' Also, VM hostnames must be unique within the zone, and the VM must have a private IP. (Exam clue: Exam questions may ask why a new VM's hostname is missing; answer: verify the VNet link has registration enabled or check that the VM's hostname isn't duplicated.)
- **Zone transfer failure for hybrid DNS** — symptom: On-premises DNS servers cannot receive zone transfers from Azure DNS.. Azure DNS does not support standard DNS zone transfers (AXFR/IXFR). For hybrid scenarios, use Azure DNS Private Resolver or conditional forwarders. (Exam clue: Tests that Azure DNS is an authoritative-only service; you cannot replicate zones to on-prem using zone transfers.)
- **SOA record expiration warnings** — symptom: Event logs show warnings about SOA record expiration for Azure DNS zone.. Azure DNS automatically manages SOA records, but if you manually modify the refresh/retry/expire values incorrectly, secondary resolvers may flag issues. Azure's defaults should be used. (Exam clue: Exam may present a misconfigured SOA with low expire time; you must know that Azure auto-manages SOA and manual changes can cause resolver errors.)

## Memory tip

Remember: "DNS needs delegation, or users get frustration." The most critical step is delegating your domain to Azure's name servers at your registrar.

## FAQ

**Can I use Azure DNS if my website is not hosted in Azure?**

Yes, Azure DNS works for any domain, regardless of where your website or app is hosted. You just need to delegate your domain to Azure DNS, and then create records pointing to your external servers.

**How long does it take for DNS changes to propagate after I update a record?**

Propagation time depends largely on the Time-to-Live (TTL) value you set on the record and on intermediate DNS caches. Typically, changes are visible globally within a few minutes to an hour, but it can take up to 48 hours if TTL was previously set very high.

**What is the difference between a public DNS zone and a private DNS zone?**

A public DNS zone is accessible from the internet and is used for domain names that anyone can resolve. A private DNS zone is only accessible from within specified Azure virtual networks and is used for internal name resolution.

**Can I use Azure DNS to host my domain for free?**

No, Azure DNS is not free. However, it is very cost-effective. You pay a small monthly fee per DNS zone and a per-query fee. For low-traffic websites, the cost is typically a few dollars per month.

**Does Azure DNS support DNSSEC?**

Azure DNS supports DNSSEC but only if you sign your own zone and upload the signed zone file. Azure does not automatically sign zones for you. This is a manual process and requires careful management.

**What happens if I create a private DNS zone but do not link a virtual network to it?**

The zone exists but is completely isolated. No virtual machines will be able to resolve the names in that zone until you create a virtual network link.

**Can I have multiple domains in a single Azure DNS zone?**

No, each DNS zone is for a single domain (e.g., contoso.com). If you have multiple domains, you need to create a separate zone for each one.

## Summary

Azure DNS is a fully managed, highly available cloud service that hosts your domain's DNS records. It removes the operational burden of maintaining DNS servers by leveraging Microsoft's global network of anycast-enabled name servers. For IT professionals, understanding Azure DNS is critical because DNS is the first step in any user's request to access an application. A misconfiguration here can make an entire application unreachable.

In exam contexts, especially for Azure certifications, you need to know the delegation process, the difference between public and private zones, the use of alias records, and the impact of TTL. The most common mistake is failing to update the registrar's name servers after creating the zone. The most valuable feature to remember is the alias record, which automatically tracks changes in target Azure resources.

For the AZ-104 exam, expect scenario-based questions that require you to choose between record types or troubleshoot a resolution failure. For the Azure Fundamentals exam, focus on the global infrastructure benefits and the concept of anycast routing. For CompTIA exams, Azure DNS serves as a real-world example of an authoritative DNS service.

By mastering Azure DNS, you ensure that users can find your applications reliably and quickly. It is a foundational service that, once set up correctly, requires minimal ongoing effort but delivers maximum value.

---

Practice questions and the full interactive page: https://courseiva.com/glossary/azure-dns