Azure DNS Configuration

Mastering Azure DNS Configuration: A Comprehensive Guide

Introduction: The Backbone of Cloud Connectivity

In the realm of cloud computing, the ability to resolve names to IP addresses is the silent engine that keeps our applications running. Azure DNS is a hosting service for DNS domains that provides name resolution using Microsoft Azure infrastructure. When you deploy virtual machines, load balancers, or databases, you need a reliable way for these components to find each other. Without a robust DNS strategy, your cloud architecture becomes a collection of isolated islands, forcing you to rely on hardcoded IP addresses that are difficult to manage, prone to change, and impossible to scale.

Understanding how to configure Azure DNS is not just about knowing which buttons to click in the portal; it is about architecting a naming strategy that supports security, performance, and operational efficiency. Whether you are managing a single web application or a multi-region enterprise environment, DNS dictates how your traffic flows and how your services communicate. This lesson will guide you through the intricacies of Azure DNS, from the fundamental concepts of public and private zones to the advanced configuration patterns required for hybrid networking.

Understanding the Azure DNS Ecosystem

To master Azure DNS, you must first distinguish between the two primary ways DNS functions within the Azure ecosystem: Azure DNS (Public) and Azure Private DNS. While they share the same underlying technology, they serve fundamentally different purposes and operate within different scopes.

Azure Public DNS

Azure Public DNS is a service for hosting your public-facing domains (like example.com). It allows you to manage your DNS records using the same credentials, APIs, and billing cycles you use for your other Azure services. By hosting your domains in Azure, you benefit from the global footprint of Microsoft’s name servers, which ensures that your DNS queries are answered from the closest geographic location to the user, thereby reducing latency.

Azure Private DNS

Azure Private DNS provides a reliable, secure DNS service for your virtual networks. It allows you to use your own custom domain names rather than the default Azure-provided names. This is critical for internal services that should not be exposed to the public internet. Because Private DNS zones are linked to your virtual networks, only resources within those networks—or those connected via VPN or ExpressRoute—can resolve these names.

Callout: Public vs. Private DNS Zones It is essential to understand that Public DNS zones are globally distributed and accessible from anywhere on the internet, whereas Private DNS zones are scoped strictly to the virtual networks you define. Private DNS zones do not require you to register a domain name with a registrar; you can create a private zone named internal.corp and it will work perfectly within your Azure environment without ever touching the public internet.

Setting Up Your First Azure DNS Zone

Regardless of whether you are working with public or private DNS, the process of setting up a zone follows a similar logical progression. You define the zone, create the records, and ensure the configuration is linked to the appropriate resources.

Step-by-Step: Creating a Private DNS Zone

1. Navigate to the Portal: Search for "Private DNS zones" in the Azure portal and click "Create."
2. Define Scope: Select your subscription and resource group. Provide a name for your zone (e.g., app.internal).
3. Deployment: Click "Review + create." Once the deployment finishes, you have a blank zone ready for records.
4. Link the Virtual Network: This is the most important step. Without linking, the virtual machines in your network cannot resolve the names in the zone. Navigate to "Virtual network links," click "Add," and select the VNet you want to integrate.
5. Enable Auto-Registration: If you want your VM hostnames to appear in the DNS zone automatically, check the "Enable auto-registration" box. This eliminates the need to manually create A records every time you spin up a new server.

Warning: Auto-Registration Limitations While auto-registration is a massive time-saver, it only works for virtual machines. If you are using Azure Kubernetes Service (AKS), App Services, or Load Balancers, you will still need to manage those records manually or via an automated CI/CD pipeline.

Managing DNS Records: The Practical Workflow

Once your zone is created, you need to populate it with records. Azure DNS supports all standard record types, including A, AAAA, CNAME, MX, PTR, SOA, SRV, and TXT.

Understanding Common Record Types

• A Records: The bread and butter of DNS. They map a hostname to an IPv4 address.
• CNAME Records: These map a hostname to another hostname (an alias). Use these for services like Azure App Service, where the underlying IP address might change.
• TXT Records: Frequently used for domain verification (like proving you own a domain for Microsoft 365 or SSL certificate validation).
• PTR Records: Used for reverse DNS lookups, mapping an IP address back to a hostname.

Automating with Azure CLI

For teams practicing Infrastructure as Code (IaC), managing DNS via the portal is inefficient. You should use the Azure CLI or PowerShell to ensure consistency.

# Create a new A record in a private zone
az network private-dns record-set a add-record \
  --resource-group MyResourceGroup \
  --zone-name app.internal \
  --record-set-name web-server-01 \
  --ipv4-address 10.0.0.5

This command directly updates the DNS zone. By integrating this into your deployment scripts, you ensure that every time an infrastructure change occurs, the DNS records remain synchronized without manual intervention.

Advanced Configuration: Split-Brain DNS and Hybrid Scenarios

A common requirement in enterprise environments is "split-brain" DNS. This occurs when you want an internal user to resolve portal.company.com to an internal private IP, while an external user resolves the same domain to a public-facing IP address.

Implementing Split-Brain DNS

To achieve this, you create a Public DNS zone for your domain and a Private DNS zone with the exact same name. You then link the Private DNS zone to your internal virtual networks. When a VM inside your VNet performs a lookup for portal.company.com, the Azure DNS resolver will prioritize the Private DNS zone over the public internet, effectively serving the private IP address.

Integrating with On-Premises Networks

When you connect your on-premises data center to Azure via VPN or ExpressRoute, you face the challenge of name resolution across the boundary. Your on-premises servers do not automatically know about your Azure Private DNS zones.

To solve this, you use Azure DNS Private Resolvers. This is a service that provides an inbound endpoint (which you can point your on-premises DNS servers to) and an outbound endpoint (which allows Azure to forward queries to your on-premises DNS servers).

1. Inbound Endpoints: You configure your on-premises DNS server to forward requests for *.azure.internal to the IP address of your Azure Private Resolver inbound endpoint.
2. Outbound Endpoints: You create "DNS Forwarding Rulesets" in Azure to send specific domain queries from Azure back to your on-premises DNS servers.

Tip: Resolver Scaling Azure DNS Private Resolvers are highly scalable and managed by Azure. Avoid the temptation to build your own "DNS proxy" VMs unless you have highly specific requirements that the native service cannot fulfill. Building your own proxy introduces a maintenance burden and a single point of failure.

Troubleshooting Common DNS Pitfalls

Even with a perfectly designed architecture, DNS issues are inevitable. They are often the most frustrating bugs to track down because they are silent failures—the application just stops connecting, and the logs often point to the application layer rather than the networking layer.

The "Caching" Trap

The most common cause of "it’s not working" is DNS caching. Modern operating systems, web browsers, and even application runtimes (like Java or .NET) cache DNS lookups for specific durations, known as Time-To-Live (TTL). If you update a record and the change doesn't appear to take effect, it is almost always because a client is still holding onto the old IP address.

• How to troubleshoot: Use nslookup or dig to bypass local caches. If nslookup returns the correct IP but your application still fails, you are dealing with application-level caching, not network-level DNS issues.

Incorrect VNet Linking

Another frequent mistake is forgetting to link a new VNet to an existing Private DNS zone. When you create a new VNet, it is completely isolated from your Private DNS zones by default. Always verify your "Virtual network links" tab in the Private DNS zone settings whenever you add new network infrastructure.

The "Public vs. Private" Confusion

If you have a Private DNS zone named example.com and you also own the public domain example.com, you must be extremely careful. If you accidentally create a record in the Private zone that also exists in the Public zone, the Private zone will "shadow" the public one for your internal VMs. This can lead to situations where internal users cannot reach your public website because their DNS resolver is directing them to your internal staging server.

Best Practices for Azure DNS Management

To keep your environment manageable and secure, follow these industry-standard practices:

1. Use Infrastructure as Code (IaC): Never create DNS records manually in the portal for production environments. Use Bicep, ARM templates, or Terraform. This ensures that your DNS configuration is version-controlled and auditable.
2. Implement Role-Based Access Control (RBAC): DNS is a critical service. Do not give every developer "Contributor" access to your DNS zones. Use custom RBAC roles to grant "Private DNS Zone Contributor" only to the network engineering team.
3. Monitor with Azure Monitor: Set up alerts for DNS query volume and response times. If you see a sudden spike in DNS queries, it could indicate a misconfigured application or, in worse cases, a potential security breach or a loop in your DNS forwarding rules.
4. Keep TTLs Appropriate: For records that change frequently (like during a migration), use a low TTL (e.g., 60 seconds). For stable infrastructure, use a longer TTL (e.g., 3600 seconds) to reduce the load on the DNS service and speed up client resolutions.
5. Use Private Endpoints: When using PaaS services like Azure SQL or Storage Accounts, use Private Endpoints. These endpoints automatically integrate with your Private DNS zones, ensuring that your traffic stays within the Microsoft backbone and never touches the public internet.

Security Considerations

DNS is a common vector for reconnaissance and data exfiltration. If an attacker gains control over your DNS, they can redirect your traffic to malicious servers.

• Restrict Zone Access: Ensure that only authorized virtual networks have access to your Private DNS zones.
• Audit Logs: Enable Azure Diagnostic Logs for your DNS zones and stream them to a Log Analytics workspace. Monitor for unusual patterns, such as a high volume of requests for non-existent domains (NXDOMAIN errors), which could indicate an attacker probing your internal network.
• DNSSEC: While Azure Public DNS supports DNSSEC, it is a complex topic. If you decide to implement it, ensure you have a robust key management strategy in place, as a misconfiguration can result in your entire domain becoming unresolvable.

Scaling DNS for Enterprise

As your organization grows, managing individual DNS zones becomes tedious. You should move toward a hub-and-spoke networking model. In this model, you have a "Hub" VNet that hosts your central DNS Private Resolver. All your "Spoke" VNets are linked to this central hub.

This architecture centralizes your DNS management. Instead of having to update links and forwarding rules across 50 different VNets, you manage them in one place. It also makes it easier to implement centralized logging and security policies.

Callout: The Hub-and-Spoke Advantage By centralizing DNS in a Hub VNet, you ensure that every Spoke VNet inherits the same naming resolution capabilities. This eliminates configuration drift and significantly reduces the surface area for human error when scaling your cloud infrastructure.

Real-World Example: A Secure Three-Tier Web App

Imagine you are deploying a three-tier web application consisting of a web front-end, an API layer, and a database.

1. Front-End: The web app is public-facing. You use Azure Public DNS for www.myapp.com to point to a public Load Balancer.
2. API Layer: The API is internal. You create a Private DNS zone api.internal. You link your API VNet to this zone.
3. Database: You use an Azure SQL Database with a Private Endpoint. During the creation of the Private Endpoint, you select "Integrate with private DNS zone." Azure automatically creates the necessary CNAME record in your api.internal zone, pointing db.api.internal to the private IP of the database.

In this scenario, your web app communicates with the API using a clean, human-readable URL (api.internal), and the API communicates with the database using db.api.internal. If you ever need to migrate your database to a new instance, you simply update the record in the Private DNS zone, and your API immediately starts pointing to the new database without requiring any code changes.

Troubleshooting: The "Why is this not resolving?" Checklist

When you encounter a DNS issue, follow this systematic approach to isolate the problem:

1. Verify the Link: Is the VNet containing the client VM actually linked to the Private DNS zone? (Check the "Virtual network links" blade).
2. Check the Resolver: Are you using the default Azure DNS (168.63.129.16)? If you have configured a custom DNS server on your VNet, that custom server must know how to resolve Azure Private DNS zones, or it must be configured to forward those requests to the Azure recursive resolver.
3. Test with nslookup: Run nslookup my-service.internal 168.63.129.16. By forcing the query to the Azure resolver, you can determine if the record exists in Azure. If this works, but a standard nslookup fails, your local OS or custom DNS server is the culprit.
4. Check for Typos: It sounds simple, but a trailing dot or a missing character in a FQDN is the most common cause of failure.
5. Look for Overlapping Zones: Do you have multiple zones with the same name? Azure will resolve based on the most specific link. If you have a zone linked to a specific VNet and another zone linked to the global subscription, the VNet-specific one will take precedence.

Integrating DNS with CI/CD Pipelines

To truly master Azure DNS, you must treat it as code. When you deploy an application using GitHub Actions or Azure DevOps, your pipeline should handle the DNS record creation.

Example: Azure DevOps Task

- task: AzureCLI@2
  inputs:
    azureSubscription: 'MyServiceConnection'
    scriptType: 'bash'
    scriptLocation: 'inlineScript'
    inlineScript: |
      az network private-dns record-set a add-record \
        --resource-group MyRG \
        --zone-name myapp.internal \
        --record-set-name $(Build.BuildId) \
        --ipv4-address $(AppServicePrivateIP)

By using the BuildId or a unique identifier as the record name, you ensure that every deployment gets its own unique, resolvable address. This is incredibly useful for "Blue/Green" deployments, where you can spin up a new version of your app, test it via its unique DNS name, and then swap the production record once you have verified everything is working.

Common Questions (FAQ)

Q: Can I use Azure Private DNS with on-premises resources? A: Yes, but you need an Azure DNS Private Resolver. The resolver provides an inbound endpoint that your on-premises DNS servers can forward queries to.

Q: Is Azure DNS free? A: Azure Public DNS has a monthly fee per zone and per million queries. Azure Private DNS is billed per zone and per query, but the costs are generally very low for standard workloads. Always check the official Azure pricing page for the latest rates.

Q: What happens if I delete a Private DNS zone? A: All records within that zone are permanently deleted. Any applications relying on those records will immediately lose the ability to resolve the names, causing service outages. Always use "Resource Locks" on your DNS zones to prevent accidental deletion.

Q: Can I have more than one Private DNS zone for the same domain? A: You can, but it is a complex configuration. Azure will resolve based on the linkage scope. Generally, it is best practice to have one zone per domain to avoid confusion.

Q: Does Azure DNS support wildcard records? A: Yes, Azure DNS supports wildcard records (e.g., *.myapp.internal). These are useful for routing all subdomains to a single load balancer or reverse proxy.

Key Takeaways for Success

• DNS is Infrastructure: Treat DNS with the same rigor as you treat your VMs and databases. Use IaC, version control, and RBAC to manage it.
• Understand the Resolver: Know that 168.63.129.16 is the "magic" IP for Azure DNS. If your systems are not using it, they need to be configured to forward to it.
• Centralize where possible: Use the Hub-and-Spoke model with Private Resolvers to simplify management as your organization scales.
• Automation is mandatory: Manual DNS updates are a recipe for human error. Automate record creation within your CI/CD pipelines.
• Security first: Protect your zones with resource locks and monitor them for suspicious activity using Azure Monitor and Log Analytics.
• Plan for Hybrid: If you have on-premises connectivity, design your DNS strategy before you connect the networks to avoid resolution conflicts.
• Test and Verify: Use tools like nslookup and dig frequently to verify your configuration. Don't assume that because a record is in the portal, it is resolving correctly for your clients.

By mastering these concepts, you transition from someone who simply "makes it work" to an architect who builds resilient, scalable, and secure networking environments. Azure DNS is a powerful tool, and when configured correctly, it disappears into the background—which is exactly what a good networking service should do.