Implementing DNS Load Balancing with Multiple CNAME Records for Azure Blob Storage


3 views

When implementing DNS-based load balancing for Azure Blob Storage, many developers encounter a fundamental limitation: most DNS servers (including Windows DNS Server) don't allow multiple CNAME records for the same hostname. This becomes problematic when you need to distribute traffic between identical storage accounts like:

a.blob.core.windows.net
b.blob.core.windows.net

According to RFC 1034, having multiple CNAME records for the same name is technically invalid. The DNS specification explicitly states that a domain name can only have one CNAME record at any time. However, there are practical solutions:

Solution 1: Using DNS A Records Instead

For services with static IP addresses, you can create multiple A records:

example.com.    IN  A   20.62.xxx.xxx
example.com.    IN  A   20.45.xxx.xxx

However, Azure Storage uses dynamic IPs that can change, making this approach unreliable.

Solution 2: Azure Traffic Manager

The most robust solution is using Azure Traffic Manager with performance routing:

# Azure CLI example
az network traffic-manager profile create \
  --name MyTrafficManager \
  --resource-group MyResourceGroup \
  --routing-method Performance \
  --unique-dns-name myuniquednsname

az network traffic-manager endpoint create \
  --name endpoint1 \
  --profile-name MyTrafficManager \
  --resource-group MyResourceGroup \
  --type azureEndpoints \
  --target-resource-id /subscriptions/.../resourceGroups/.../providers/Microsoft.Storage/storageAccounts/a

az network traffic-manager endpoint create \
  --name endpoint2 \
  --profile-name MyTrafficManager \
  --resource-group MyResourceGroup \
  --type azureEndpoints \
  --target-resource-id /subscriptions/.../resourceGroups/.../providers/Microsoft.Storage/storageAccounts/b

If Traffic Manager isn't an option, you can implement manual round-robin using subdomains:

# DNS configuration
cdn.example.com.    IN  CNAME   a.blob.core.windows.net.
cdn2.example.com.   IN  CNAME   b.blob.core.windows.net.

# Application code (Python example)
import random
endpoints = [
    "https://cdn.example.com",
    "https://cdn2.example.com"
]
selected_endpoint = random.choice(endpoints)
  • TTL values: Set appropriate DNS TTLs (300-600 seconds) for balance between performance and flexibility
  • Health checks: Implement application-level monitoring since DNS lacks health checking
  • Cache behavior: Clients may cache DNS resolutions beyond your TTL settings

For production environments, Azure Traffic Manager provides the most reliable solution with:

  • Built-in health probes
  • Geographic routing options
  • Performance-based routing
  • Automatic failover

The configuration can be automated via ARM templates or Terraform for infrastructure-as-code deployments.

When implementing load balancing across multiple Azure storage accounts (or similar cloud services), you might want to distribute traffic using DNS round-robin. A common scenario involves having identical content in two storage accounts (a.blob.core.windows.net and b.blob.core.windows.net) and wanting a single domain (example.com) to point to both.

Most DNS servers (including Windows DNS) enforce RFC compliance that prevents multiple CNAME records for the same name. This is because:

  • CNAME records must be unique per RFC 1034
  • They create aliasing chains that can't have multiple targets

Option 1: Use A Records Instead

For Azure Blob Storage specifically, you can resolve the endpoint IPs and use A records:

example.com. 300 IN A 52.239.154.10
example.com. 300 IN A 52.239.155.10

Option 2: DNS Provider-Specific Solutions

Some DNS providers offer weighted or round-robin CNAME-like functionality:

  • Azure DNS: Use alias records to multiple resources
  • Route 53: Implement weighted routing policies

Option 3: Front Door or Traffic Manager

Azure's native solutions provide better load balancing:

# Azure CLI example for Front Door
az network front-door create \
  --resource-group myResourceGroup \
  --name myFrontDoor \
  --accepted-protocols Http Https \
  --backend-address a.blob.core.windows.net \
  --backend-address b.blob.core.windows.net

Use nslookup or dig to verify multiple records:

dig example.com ANY
  • TTL values affect DNS caching
  • Not all clients honor round-robin
  • Health checks aren't native to basic DNS