Microsoft Azure — Azure DNS & Traffic Manager

Azure is Microsoft's cloud computing platform offering over 200 services. This article covers azure dns & traffic manager with production-ready configurations, best practices, and hands-on examples.

Azure DNS: The Foundation of Cloud Naming

Azure DNS is a hosting service for DNS domains that provides name resolution using Microsoft Azure infrastructure. By hosting your domains in Azure, you can manage your DNS records using the same credentials, APIs, tools, and billing as your other Azure services. Azure DNS supports common DNS record types like A, AAAA, CNAME, MX, NS, PTR, SOA, SRV, and TXT. It also supports alias records, which can point to Azure resources like public IP addresses, Traffic Manager profiles, or Azure CDN endpoints. Alias records are a key differentiator because they automatically update when the underlying resource's IP changes, eliminating manual updates. For production, use Azure DNS with at least two name servers (Azure provides four) and configure TTLs appropriately: low TTLs (300 seconds) for active failover scenarios, higher TTLs (3600 seconds) for stable records to reduce query load. Avoid using CNAME records at the zone apex; instead, use alias records or A records with a static IP. Azure DNS is zone-based, meaning you create a DNS zone for your domain and then manage records within that zone. Delegation is done by updating your registrar's NS records to point to Azure's name servers. This setup is critical for any cloud-native application that requires reliable, low-latency DNS resolution.

#!/bin/bash
# Create a DNS zone in Azure
az network dns zone create \
  --resource-group myResourceGroup \
  --name example.com \
  --if-none-match

# Add an A record
az network dns record-set a add-record \
  --resource-group myResourceGroup \
  --zone-name example.com \
  --record-set-name www \
  --ipv4-address 203.0.113.10

# Add an alias record for Traffic Manager
az network dns record-set a add-record \
  --resource-group myResourceGroup \
  --zone-name example.com \
  --record-set-name app \
  --target-resource /subscriptions/.../providers/Microsoft.Network/trafficManagerProfiles/myTMProfile

Traffic Manager: Global Load Balancing with DNS

Azure Traffic Manager is a DNS-based traffic load balancer that distributes traffic to your public-facing applications across global Azure regions. It works by responding to DNS queries with the appropriate endpoint based on the traffic-routing method and the health of each endpoint. Traffic Manager supports multiple routing methods: Priority (active/passive failover), Weighted (round-robin with weights), Performance (closest region based on latency), Geographic (geographic location of the user), Multivalue (returns all healthy endpoints), and Subnet (maps IP ranges to endpoints). Each endpoint is monitored via HTTP/HTTPS/TCP health probes. If an endpoint fails health checks, Traffic Manager removes it from DNS responses. For production, always configure health probes with a short interval (10 seconds) and a low number of failures (2-3) to detect outages quickly. Use the Performance routing method for global applications to minimize latency. Be aware of DNS caching: clients and resolvers cache DNS responses based on TTL. Traffic Manager's TTL can be set as low as 5 seconds, but many resolvers ignore low TTLs. For critical failover, combine Traffic Manager with Azure Front Door or Application Gateway for faster convergence.

#!/bin/bash
# Create a Traffic Manager profile
az network traffic-manager profile create \
  --resource-group myResourceGroup \
  --name myTMProfile \
  --routing-method Performance \
  --unique-dns-name myapp \
  --ttl 30 \
  --protocol HTTP \
  --port 80 \
  --path "/health"

# Add endpoints
az network traffic-manager endpoint create \
  --resource-group myResourceGroup \
  --profile-name myTMProfile \
  --name eastus-endpoint \
  --type azureEndpoints \
  --target-resource-id /subscriptions/.../providers/Microsoft.Web/sites/myEastUsApp

az network traffic-manager endpoint create \
  --resource-group myResourceGroup \
  --profile-name myTMProfile \
  --name westeurope-endpoint \
  --type azureEndpoints \
  --target-resource-id /subscriptions/.../providers/Microsoft.Web/sites/myWestEuropeApp

Integrating Azure DNS with Traffic Manager

The true power of Azure DNS and Traffic Manager emerges when they are integrated. By creating an alias record in Azure DNS that points to a Traffic Manager profile, you get a seamless global load balancing solution. The alias record automatically resolves to the IP addresses of the healthy endpoints selected by Traffic Manager. This integration eliminates the need to manually update DNS records when endpoints change. To set this up, first create a Traffic Manager profile with your endpoints and health probes. Then, in your Azure DNS zone, create an A or AAAA record set with the alias record type, targeting the Traffic Manager profile's resource ID. Traffic Manager responds to DNS queries with the appropriate endpoint IP based on the routing method. For production, use the Performance routing method to direct users to the closest healthy region. Combine with Azure DNS Private Zones for internal resolution if needed. Monitor both services: use Azure Monitor for DNS query volume and Traffic Manager endpoint health. Set up alerts for when all endpoints are degraded. Remember that Traffic Manager is not a replacement for a load balancer; it operates at the DNS level and does not inspect traffic. For layer 7 routing, use Azure Application Gateway or Front Door.

#!/bin/bash
# Create an alias record in Azure DNS pointing to Traffic Manager
az network dns record-set a add-record \
  --resource-group myResourceGroup \
  --zone-name example.com \
  --record-set-name www \
  --target-resource /subscriptions/.../providers/Microsoft.Network/trafficManagerProfiles/myTMProfile \
  --alias-target-resource-type Microsoft.Network/trafficManagerProfiles

# Verify the record
az network dns record-set a show \
  --resource-group myResourceGroup \
  --zone-name example.com \
  --name www

Routing Methods: Choosing the Right Strategy

Traffic Manager offers six routing methods, each suited for different scenarios. Priority routing is for active-passive failover: you assign a priority to each endpoint, and Traffic Manager sends all traffic to the highest priority healthy endpoint. This is ideal for disaster recovery where you have a primary region and a standby. Weighted routing distributes traffic based on weights, useful for A/B testing or gradual rollouts. Performance routing directs users to the endpoint with the lowest latency, based on the user's DNS resolver IP. This is the most common for global applications. Geographic routing sends traffic based on the geographic location of the DNS query, useful for content localization or data sovereignty. Multivalue routing returns all healthy endpoints in the DNS response, and the client chooses one. This is good for scenarios where the client can handle multiple IPs. Subnet routing maps specific IP ranges to endpoints, useful for internal testing or VIP access. In production, avoid using Geographic routing for failover because it does not fall back to other regions if the mapped region is unhealthy. Instead, combine Geographic with Priority by using nested profiles. For most global apps, Performance routing with multiple endpoints in each region is the best choice.

#!/bin/bash
# Create a Weighted Traffic Manager profile
az network traffic-manager profile create \
  --resource-group myResourceGroup \
  --name weightedTM \
  --routing-method Weighted \
  --unique-dns-name myweightedapp \
  --ttl 60 \
  --protocol HTTP \
  --port 80 \
  --path "/health"

# Add endpoints with weights
az network traffic-manager endpoint create \
  --resource-group myResourceGroup \
  --profile-name weightedTM \
  --name v1-endpoint \
  --type azureEndpoints \
  --target-resource-id /subscriptions/.../providers/Microsoft.Web/sites/myAppV1 \
  --weight 90

az network traffic-manager endpoint create \
  --resource-group myResourceGroup \
  --profile-name weightedTM \
  --name v2-endpoint \
  --type azureEndpoints \
  --target-resource-id /subscriptions/.../providers/Microsoft.Web/sites/myAppV2 \
  --weight 10

Health Monitoring and Failover Configuration

Traffic Manager continuously monitors the health of each endpoint using HTTP/HTTPS/TCP probes. You configure the protocol, port, path, and expected status code. The probe interval can be 10 or 30 seconds, and the number of failures before marking an endpoint as degraded is configurable (default 3). For production, set the interval to 10 seconds and the failure threshold to 2 for fast detection. The health endpoint should be lightweight but reflect the actual application health. For example, an ASP.NET Core app might have a /health endpoint that checks database connectivity and cache. Avoid heavy operations like full page rendering. Traffic Manager also supports custom headers for health probes, which can be used to bypass authentication or firewalls. When an endpoint is degraded, Traffic Manager stops returning it in DNS responses. However, due to DNS caching, clients may still try the degraded endpoint for up to the TTL duration. To mitigate, set a low TTL (e.g., 30 seconds) on the Traffic Manager profile. For critical applications, combine with Azure Front Door which uses anycast and can fail over in seconds. Monitor endpoint health using Azure Monitor and set up alerts for when all endpoints are degraded. Also, consider using multi-region deployment with at least two endpoints per region for redundancy.

[ApiController]
[Route("health")]
public class HealthController : ControllerBase
{
    private readonly ApplicationDbContext _db;
    private readonly IDistributedCache _cache;

    public HealthController(ApplicationDbContext db, IDistributedCache cache)
    {
        _db = db;
        _cache = cache;
    }

    [HttpGet]
    public async Task<IActionResult> Get()
    {
        try
        {
            // Check database connectivity
            await _db.Database.CanConnectAsync();
            // Check cache
            await _cache.GetStringAsync("health");
            return Ok("Healthy");
        }
        catch (Exception ex)
        {
            return StatusCode(503, ex.Message);
        }
    }
}

Nested Traffic Manager Profiles for Complex Routing

Nested Traffic Manager profiles allow you to combine routing methods for sophisticated traffic management. For example, you can use Geographic routing at the top level to direct users to a region, and within each region, use Performance routing to select the best endpoint. To create a nested profile, you add a Traffic Manager profile as an endpoint of another profile. The child profile must be of type 'externalEndpoints' and its target is the DNS name of the child profile. Nested profiles are useful for multi-layered failover: for instance, a Priority profile with a primary region endpoint and a secondary region endpoint, where each region endpoint is itself a Performance profile with multiple endpoints. This gives you both regional failover and intra-region load balancing. Be mindful of the TTL cascade: the parent profile's TTL should be equal to or greater than the child's TTL to avoid unnecessary queries. Also, health probes propagate: if all endpoints in a child profile are degraded, the child profile endpoint is marked degraded in the parent. Nested profiles increase complexity, so document your architecture thoroughly. Use them only when necessary; for most applications, a single Performance profile with endpoints in multiple regions suffices.

#!/bin/bash
# Create child Performance profile for US region
az network traffic-manager profile create \
  --resource-group myResourceGroup \
  --name us-performance \
  --routing-method Performance \
  --unique-dns-name us-perf \
  --ttl 30

# Add endpoints to child profile
az network traffic-manager endpoint create \
  --resource-group myResourceGroup \
  --profile-name us-performance \
  --name eastus \
  --type azureEndpoints \
  --target-resource-id /subscriptions/.../providers/Microsoft.Web/sites/eastusapp

az network traffic-manager endpoint create \
  --resource-group myResourceGroup \
  --profile-name us-performance \
  --name westus \
  --type azureEndpoints \
  --target-resource-id /subscriptions/.../providers/Microsoft.Web/sites/westusapp

# Create parent Geographic profile
az network traffic-manager profile create \
  --resource-group myResourceGroup \
  --name geo-parent \
  --routing-method Geographic \
  --unique-dns-name mygeoapp \
  --ttl 60

# Add child profile as endpoint
az network traffic-manager endpoint create \
  --resource-group myResourceGroup \
  --profile-name geo-parent \
  --name us-region \
  --type externalEndpoints \
  --target us-perf.trafficmanager.net \
  --geo-mapping GEO-NA

Performance Optimization and Caching Considerations

DNS caching is the biggest challenge with Traffic Manager. DNS resolvers (ISP, corporate, public like 8.8.8.8) cache DNS responses based on the TTL. Even if you set a low TTL (e.g., 5 seconds), many resolvers ignore it and cache for longer (some up to 5 minutes). This means failover can be delayed. To mitigate, use Azure DNS with alias records and set the Traffic Manager TTL as low as possible (minimum 5 seconds). For critical applications, consider using Azure Front Door, which uses anycast and can fail over in seconds without DNS caching issues. Another optimization is to use the Performance routing method, which directs users to the closest endpoint based on the DNS resolver's IP. However, this is not the same as the user's actual IP; it's the resolver's IP. For more accurate latency routing, use Azure Front Door with latency-based routing. Also, consider using multiple Traffic Manager profiles for different user segments (e.g., internal vs external). Monitor DNS query latency using Azure Monitor and set alerts for high latency. Finally, use Azure DNS Private Zones for internal resolution to avoid public DNS caching.

#!/bin/bash
# Update Traffic Manager TTL to minimum
az network traffic-manager profile update \
  --resource-group myResourceGroup \
  --name myTMProfile \
  --ttl 5

# Verify
az network traffic-manager profile show \
  --resource-group myResourceGroup \
  --name myTMProfile \
  --query dnsConfig.ttl

Monitoring, Alerts, and Troubleshooting

Monitoring Azure DNS and Traffic Manager is essential for production reliability. Use Azure Monitor to track metrics like DNS query volume (for zones), endpoint health status, and probe latency. Set up alerts for when an endpoint is degraded or when all endpoints are degraded. For Traffic Manager, key metrics include: 'Probe Agent Count' (number of healthy endpoints), 'QpsByEndpoint' (queries per second per endpoint), and 'EndpointStatus'. For Azure DNS, monitor 'QueryVolume' and 'RecordSetCount'. Use Azure Log Analytics to query logs for DNS resolution failures. Common issues: misconfigured health probes (wrong path, port, or protocol), firewall blocking probes, and TTL misconfigurations. To troubleshoot, use tools like dig or nslookup to check DNS resolution. For example, dig @ns1-01.azure-dns.com www.example.com to query Azure DNS directly. For Traffic Manager, use nslookup myapp.trafficmanager.net to see which IPs are returned. If an endpoint is not receiving traffic, check its health status in the Azure portal. Also, verify that the endpoint's firewall allows Traffic Manager's probe IPs (which are documented and change over time). Use Azure Resource Health to check if there are any Azure platform issues.

#!/bin/bash
# Query Azure DNS directly
dig @ns1-01.azure-dns.com www.example.com

# Query Traffic Manager
nslookup myapp.trafficmanager.net

# Check endpoint health via Azure CLI
az network traffic-manager endpoint show \
  --resource-group myResourceGroup \
  --profile-name myTMProfile \
  --name eastus-endpoint \
  --query endpointStatus

# List all endpoints and their status
az network traffic-manager endpoint list \
  --resource-group myResourceGroup \
  --profile-name myTMProfile \
  --query "[].{name:name, status:endpointStatus}"

Disaster Recovery and Multi-Region Architectures

Azure DNS and Traffic Manager are key components of a multi-region disaster recovery strategy. The typical architecture involves deploying your application in at least two Azure regions (e.g., East US and West Europe) and using Traffic Manager to route traffic. For active-passive, use Priority routing: primary region gets priority 1, secondary gets priority 2. For active-active, use Performance routing to distribute traffic. In both cases, ensure each region can handle the full load if the other fails. Use Azure DNS alias records to point to the Traffic Manager profile. For database, use geo-replication (e.g., Azure SQL Database active geo-replication or Cosmos DB multi-region writes). For storage, use geo-redundant storage (GRS). Test your failover regularly: simulate a region outage by disabling the endpoint in Traffic Manager. Monitor the failover time and ensure it meets your RTO. Document the runbook for manual failover if needed. Also, consider using Azure Front Door for global HTTP load balancing with instant failover. For DNS-level failover, Traffic Manager is sufficient for most applications, but be aware of DNS caching delays. Use Azure Traffic Manager's 'Always Serve' feature to ensure endpoints are always returned even if degraded (not recommended for production).

#!/bin/bash
# Simulate failover by disabling primary endpoint
az network traffic-manager endpoint update \
  --resource-group myResourceGroup \
  --profile-name myTMProfile \
  --name eastus-endpoint \
  --endpoint-status Disabled

# Wait for TTL to expire
sleep 60

# Check that traffic goes to secondary
nslookup myapp.trafficmanager.net

# Re-enable primary
az network traffic-manager endpoint update \
  --resource-group myResourceGroup \
  --profile-name myTMProfile \
  --name eastus-endpoint \
  --endpoint-status Enabled

Cost Management and Scaling Considerations

Azure DNS and Traffic Manager have predictable pricing. Azure DNS charges based on the number of zones and the number of DNS queries. Traffic Manager charges per million DNS queries and per endpoint (after the first 1000 endpoints free). For high-traffic applications, costs can add up. To optimize, minimize the number of DNS queries by using longer TTLs for stable records. For Traffic Manager, use the 'Performance' routing method which may reduce queries by directing users to the closest endpoint. Also, consider using Azure DNS Private Zones for internal traffic to avoid public DNS costs. For scaling, Traffic Manager can handle millions of queries per second, but you may need to distribute load across multiple profiles for very high traffic. Use Azure Monitor to track query volumes and set budgets. Another cost consideration: alias records in Azure DNS are free, but they generate DNS queries to Traffic Manager, which are billed. For global applications, consider using Azure Front Door which includes DNS and traffic management with a different pricing model. Finally, use Azure Cost Management to set alerts for unexpected spikes.

#!/bin/bash
# Estimate monthly DNS queries (example)
# Assume 10 million queries per month
# Azure DNS: $0.20 per million queries = $2.00
# Traffic Manager: $0.50 per million queries = $5.00
# Endpoints: 2 endpoints free (first 1000) = $0
# Total: ~$7.00 per month

# Use Azure Pricing Calculator for accurate estimates
# https://azure.microsoft.com/en-us/pricing/calculator/

Security Best Practices for DNS and Traffic Manager

Securing Azure DNS and Traffic Manager involves protecting your DNS zones from unauthorized changes and ensuring traffic integrity. Use Azure RBAC to restrict who can modify DNS zones and Traffic Manager profiles. Assign the 'DNS Zone Contributor' role only to necessary personnel. Enable Azure Policy to enforce that alias records are used instead of CNAME at apex. For Traffic Manager, use managed identities for endpoints to avoid using connection strings. Protect health probes by using HTTPS and custom headers to prevent spoofing. Do not expose sensitive information in health probe responses. Use Azure Firewall or NSGs to restrict access to health endpoints only from Traffic Manager probe IPs (use service tags). For DNS, enable DNSSEC (Domain Name System Security Extensions) to prevent cache poisoning. Azure DNS supports DNSSEC with zone signing. Also, use Azure Private DNS Zones for internal resources to avoid exposure to the internet. Monitor for unauthorized changes using Azure Activity Logs and set up alerts for any modifications to DNS zones or Traffic Manager profiles. Finally, regularly audit your DNS records and Traffic Manager configuration for misconfigurations.

#!/bin/bash
# Enable DNSSEC for a zone (preview feature)
az network dns zone update \
  --resource-group myResourceGroup \
  --name example.com \
  --dnssec-enabled true

# Verify
az network dns zone show \
  --resource-group myResourceGroup \
  --name example.com \
  --query dnssecEnabled

Migration from Third-Party DNS to Azure DNS

Migrating from a third-party DNS provider (e.g., AWS Route53, Cloudflare, GoDaddy) to Azure DNS involves several steps. First, export your existing DNS records in a standard format (e.g., BIND zone file). Azure DNS supports importing zone files. Use the Azure CLI or portal to create the zone and import records. For large zones, use Azure PowerShell or CLI scripts. After import, verify all records are correct. Then, update the NS records at your registrar to point to Azure DNS name servers. This is the critical step: the delegation change propagates according to the TTL of the NS records (usually 48 hours). To minimize downtime, lower the TTL of your NS records at the registrar before the migration. Also, keep the old DNS provider active until propagation completes. For Traffic Manager, you can create the profile and endpoints in Azure, then update your DNS records to point to Traffic Manager. If you are migrating from another load balancer, ensure health probes are configured correctly. Test thoroughly before cutting over. Use Azure DNS's alias records to simplify future changes. Document the migration plan and have a rollback strategy. For complex migrations, consider using Azure Migrate or third-party tools.

#!/bin/bash
# Export zone from old provider (example BIND format)
# Then import into Azure DNS
az network dns zone import \
  --resource-group myResourceGroup \
  --name example.com \
  --file-name /path/to/zonefile.txt

# Verify records
az network dns record-set list \
  --resource-group myResourceGroup \
  --zone-name example.com

# Update registrar NS records (manual step)
# Get Azure DNS name servers
az network dns zone show \
  --resource-group myResourceGroup \
  --name example.com \
  --query nameServers

Azure DNS Private Resolver: Hybrid Name Resolution Without Custom VMs

Azure DNS Private Resolver is a fully managed service that provides DNS resolution between Azure VNets and on-premises networks without deploying custom DNS VMs. It uses inbound endpoints (receives DNS queries from on-premises) and outbound endpoints (sends DNS queries to on-premises via DNS forwarding rulesets). The inbound endpoint provides an IP address to forward queries from on-premises DNS servers into Azure — private DNS zones linked to the VNet are resolved automatically. Outbound endpoints are linked to DNS forwarding rulesets, which define rules for specific DNS namespaces (e.g., forward contoso.com to on-premises DNS at 192.168.1.10). In production, deploy DNS Private Resolver in the hub VNet with both inbound and outbound endpoints. Link forwarding rulesets to spoke VNets so they can resolve hybrid names without direct zone links. This is a significant improvement over running custom DNS VMs — no OS patching, no HA configuration, and auto-scaling. Key configuration: create forwarding rulesets with rules for your hybrid domains, link the ruleset to spoke VNets, and configure on-premises DNS to forward Azure zones to the inbound endpoint IP. Avoid linking a ruleset to the same VNet where the inbound endpoint resides to prevent DNS resolution loops. DNS Private Resolver supports up to 1000 forwarding rules per ruleset and 500 VNet links per ruleset.

#!/bin/bash
# Create DNS Private Resolver in hub VNet
az network dns-resolver create \
  --resource-group rg-prod \
  --name hub-resolver \
  --location eastus \
  --virtual-network hub-vnet

# Create inbound endpoint
az network dns-resolver inbound-endpoint create \
  --resource-group rg-prod \
  --dns-resolver-name hub-resolver \
  --name inbound-ep \
  --ip-configurations '[{"private-ip-allocation-method":"Dynamic","subnet":{"id":"/subscriptions/.../subnets/resolver-inbound-subnet"}}]'

# Create outbound endpoint
az network dns-resolver outbound-endpoint create \
  --resource-group rg-prod \
  --dns-resolver-name hub-resolver \
  --name outbound-ep \
  --subnet /subscriptions/.../subnets/resolver-outbound-subnet

# Create forwarding ruleset
az network dns-resolver forwarding-ruleset create \
  --resource-group rg-prod \
  --name hybrid-ruleset \
  --location eastus \
  --outbound-endpoints '[{"id":"/subscriptions/.../dnsResolvers/hub-resolver/outboundEndpoints/outbound-ep"}]'

# Add forwarding rule
az network dns-resolver forwarding-rule create \
  --resource-group rg-prod \
  --ruleset-name hybrid-ruleset \
  --name onprem-rule \
  --domain-name contoso.com. \
  --target-dns-servers '[{"ip-address":"192.168.1.10","port":53}]'

# Link ruleset to spoke VNet
az network dns-resolver forwarding-ruleset vnet-link create \
  --resource-group rg-prod \
  --ruleset-name hybrid-ruleset \
  --name spoke-link \
  --virtual-network spoke-vnet

Traffic Manager Real User Measurements: Data-Driven Routing Optimization

Traffic Manager Real User Measurements (RUM) is a feature that collects network latency measurements from actual user browsers to Azure regions, enabling data-driven routing decisions. When enabled, users' browsers measure latency to Azure regions using a JavaScript embedded in web pages, and the measurements are sent to Traffic Manager to influence the Performance routing method. This is more accurate than relying on DNS resolver IP-based latency approximation, because it measures the actual user's network path rather than their DNS resolver's location. In production, embed the RUM JavaScript in your application's landing page to collect real user latency data. Use the Heat Map in Traffic Manager to visualize latency across regions. RUM is available at no extra cost and works with Performance routing. The key benefit: users behind a corporate DNS resolver in a different geographic location will be routed to the Azure region with the lowest actual latency from their device, not from the resolver. RUM data is anonymized and aggregated. For accurate results, ensure your web application has sufficient traffic volume (at least 1000 measurements per region per day). Combine RUM with Traffic View for a complete picture of user traffic patterns and regional performance. Use the Heat Map REST API to integrate RUM data into custom dashboards.

// Embed this JavaScript in your web application
<script src="https://js.trafficmanager.net/rum.js"></script>
<script>
  // Initialize RUM with your Traffic Manager profile key
  TrafficManagerRUM.init({
    profileKey: 'YOUR_PROFILE_KEY_HERE',
    interval: 30000, // measurement interval in ms
    sampleRate: 0.1  // 10% of users participate
  });

  // Access RUM data via Heat Map API
  // GET /api/heatmap?profileId=YOUR_PROFILE_ID
</script>

# View RUM data via Azure CLI
az network traffic-manager profile show \
  --resource-group rg-prod \
  --name myTMProfile \
  --query 'monitorConfig.performanceRoutingConfig.realUserMeasurements'

Azure Private DNS Zones and Hybrid Resolution: Deep Dive

Azure Private DNS Zones provide custom DNS resolution within VNets without exposing records to the internet. Linked VNets can resolve records in the zone, and auto-registration can dynamically create A records for VMs. In production, use Private DNS Zones for internal service discovery: create zones like internal.contoso.com and add records for databases, caches, and internal APIs. Link zones only to the hub VNet and use DNS forwarding rulesets (with DNS Private Resolver) to enable spoke VNets to resolve private zone records — this avoids linking every spoke directly, reducing zone link limits. For hybrid resolution: configure on-premises DNS servers with conditional forwarders for your Azure private zones pointing to the DNS Private Resolver inbound endpoint IP. Azure Private DNS now supports 'Fallback to Internet' — if no record is found in the private zone, Azure DNS falls back to public DNS. Enable this for phased migrations where you have partial zone coverage. Key design patterns: (1) Centralized DNS: link private zones only to hub VNet, use DNS Private Resolver for spoke and on-premises resolution. (2) Distributed DNS: link each spoke VNet directly to private zones — simpler but hits zone link limits faster (max 500 VNet links per zone). For enterprise landing zones, use the centralized pattern: deploy DNS Private Resolver in the connectivity hub VNet, create forwarding rulesets for hybrid domains, and link rulesets to all spoke VNets. This scales to hundreds of spokes.

#!/bin/bash
# Create private DNS zone
az network private-dns zone create \
  --resource-group rg-prod \
  --name internal.contoso.com

# Link to hub VNet (with auto-registration)
az network private-dns link vnet create \
  --resource-group rg-prod \
  --zone-name internal.contoso.com \
  --name hub-link \
  --virtual-network hub-vnet \
  --registration-enabled true

# Add records for internal services
az network private-dns record-set a create \
  --resource-group rg-prod \
  --zone-name internal.contoso.com \
  --name db-primary
az network private-dns record-set a add-record \
  --resource-group rg-prod \
  --zone-name internal.contoso.com \
  --record-set-name db-primary \
  --ipv4-address 10.0.2.10

# Enable fallback to internet (for phased migration)
az network private-dns zone update \
  --resource-group rg-prod \
  --name internal.contoso.com \
  --resolution-policy Default

# On-premises conditional forwarder configuration (run on on-premises DNS)
# Add-VmDnsServerConditionalForwarderZone -Name "internal.contoso.com" -MasterServers 10.0.1.4 -ReplicationScope Forest