Understanding Cloud DNS Routing Policies
- Published on
- Authors
- Author
- Ram Simran G
- twitter @rgarimella0124
In the era of global applications, efficiently directing user traffic is crucial for performance, reliability, and user experience. Cloud DNS routing policies allow you to control how DNS queries are resolved based on various criteria, ensuring traffic reaches the optimal endpoint. These policies are essential for load balancing, failover, and geographic optimization in distributed systems.
This blog post explores the key DNS routing policies, starting with fundamental ones illustrated with diagrams, and extends to additional techniques. We’ll explain each policy in simple terms, provide visual representations using Markdown diagrams, and discuss practical implementations across major cloud providers: AWS, Azure, and GCP. Whether you’re building a scalable web app or managing multi-region deployments, mastering these policies can significantly enhance your infrastructure.
📚 The Core DNS Routing Policies
Let’s dive into the six primary routing policies that are commonly used in cloud environments. Each addresses specific scenarios, from simple traffic direction to advanced geographic steering.
✅ 1. Simple Routing
Simple routing directs all incoming DNS queries to a single resource, such as an IP address or endpoint. There’s no load balancing or failover — 100% of traffic goes to one destination.
Use case: Hosting a basic website on a single server.
Diagram:
+-------------------+
| Users |
+-------------------+
|
v
+-------------------+ 100% +-------------------+
| DNS | ---------> | App |
+-------------------+ +-------------------+✅ 2. Weighted Routing
Weighted routing distributes traffic across multiple resources based on assigned weights. For example, you might send 70% of traffic to one endpoint and 30% to another.
Use case: Testing a new version of your app by directing a small percentage of users to it.
Diagram:
+-------------------+
| Users |
+-------------------+
|
v
+-------------------+
| DNS |
+-------------------+
| |
70% 30%
| |
v v
+----------+ +----------+
| App 1 | | App 2 |
+----------+ +----------+✅ 3. Failover Routing
Failover routing ensures high availability by directing traffic to a primary resource and switching to a secondary one if the primary becomes unhealthy.
Use case: Disaster recovery for critical services, such as switching to a backup database if the main one fails.
Diagram:
+-------------------+
| Users |
+-------------------+
|
v
+-------------------+ Primary +-------------------+
| DNS | -----------> | Primary App |
+-------------------+ +-------------------+
|
| Failover
v
+-------------------+
| Failover App |
+-------------------+✅ 4. Latency-Based Routing
Latency-based routing directs users to the resource with the lowest network latency, measured from the user’s location to available regions.
Use case: Global e-commerce sites where faster load times improve conversion rates.
Diagram:
Virginia Mumbai
o o
| |
+---------+ +---------+
| Users | | Users |
+---------+ +---------+
| |
v v
+---------+ +-------------+
| DNS | --------> | Least Latency|
+---------+ | App |
+-------------+✅ 5. Geolocation Routing
Geolocation routing directs traffic based on the user’s geographic location, such as country or state.
Use case: Compliance with data residency laws or serving region-specific content like language versions.
Diagram:
Virginia (Default) Mumbai
o o
| |
+---------+ +-----------+
| Users | | Users |
| (US) | | (India) |
+---------+ +-----------+
| |
v v
+---------+ +-----------------+
| DNS | -----> | Location-Based |
+---------+ | App |
+-----------------+✅ 6. Geoproximity Routing
Geoproximity routing calculates the physical distance between the user and resources and routes traffic to the nearest one. A “bias” value can adjust this proximity, favoring one location over another.
Use case: Balancing load between data centers while considering geographic proximity and cost.
Diagram:
Mumbai User (Bias: 0) Hyderabad User (Bias: 0)
o o
| |
+------------+ +--------------+
| App (Mumbai)| | App (Hyderabad)|
+------------+ +--------------+
Mumbai User (Bias: 50) Hyderabad User (Bias: 90)
o o
| |
+------------+ <----------> +--------------+
| App (Mumbai)| | App (Hyderabad)|
+------------+ +--------------+Here’s the new content, carefully integrated into the blog post with corrected Markdown diagrams, formatting, and explanations to match the tone and clarity of the earlier sections.
🌟 Additional Important DNS Routing Techniques
While the core DNS routing policies cover many scenarios, modern applications often require advanced techniques to improve reliability, precision, security, and efficiency. These methods are not always included in basic overviews but can be critical in global deployments.
Below, we explore several advanced routing techniques, including Round-Robin Routing, EDNS Client Subnet (ECS), Global Server Load Balancing (GSLB), Split-Horizon DNS, and Response Policy Zones (RPZ). Each includes an explanation, use cases, and a diagram for visualization.
✅ Round-Robin Routing
Round-Robin Routing is a straightforward load-balancing technique where the DNS server returns multiple IP addresses in a rotating order for each query. Unlike weighted routing, it distributes traffic evenly across endpoints without considering server health or capacity.
Use case: Evenly distributing traffic across identical servers, such as in a small-scale content delivery setup where sophisticated load balancing is unnecessary.
Diagram:
+-------------------+
| Users |
+-------------------+
|
v
+-------------------+ Rotate IPs +-------------------+
| DNS | ---------------> | App Server A |
+-------------------+ +-------------------+
| +-------------------+
| | App Server B |
+----------------> +-------------------+
| +-------------------+
| | App Server C |
+----------------> +-------------------+✅ EDNS Client Subnet (ECS)
EDNS Client Subnet (ECS) enhances location-based routing by allowing recursive resolvers to include the client’s IP subnet in DNS queries to authoritative servers. This solves issues where users behind public resolvers (like Google DNS) would otherwise be routed incorrectly based on the resolver’s location.
How it works: The resolver appends an EDNS0 option with the client’s subnet (e.g., /24). The authoritative DNS uses this information to direct traffic based on the user’s location rather than the resolver’s.
Use case: CDNs and global apps that need precise routing for users behind centralized public resolvers to ensure better performance and accuracy.
Diagram:
+-------------------+ Client Subnet +-------------------+
| User Client | -----------------> | Recursive Resolver|
+-------------------+ +-------------------+
| |
v v
+-------------------+ +-------------------+
| Public Resolver | EDNS0 w/ Subnet | Authoritative DNS |
| (e.g., Google) | -----------------> | (Uses Subnet |
+-------------------+ | for Routing) |
+-------------------+
|
v
+-------------------+
| Nearest Server |
+-------------------+✅ Global Server Load Balancing (GSLB)
Global Server Load Balancing (GSLB) is a comprehensive approach that uses DNS to intelligently distribute traffic across multiple data centers worldwide. It combines policies like latency, geolocation, and failover, often integrated with real-time monitoring of server load, network health, and conditions.
How it works: GSLB systems dynamically respond to DNS queries based on predefined rules and current infrastructure health to ensure users are routed to the optimal server.
Use case: Large-scale enterprises such as streaming platforms or e-commerce sites that require low latency, high availability, and efficient global load balancing.
Diagram:
Data Center A Data Center B Data Center C
o o o
/ | / | / | / | +-------------------+ Monitor & Select +-------------------+
| Users | -------------------------> | GSLB DNS |
+-------------------+ +-------------------+
|
v
+-------------------+
| Optimal Server(s) |
+-------------------+✅ Split-Horizon DNS
Split-Horizon DNS (also called Split-Brain DNS) serves different responses based on the source of the DNS query. This allows the DNS server to provide tailored records for internal and external networks.
How it works: The DNS server maintains multiple “views” or zone files and uses access control lists (ACLs) to match queries to the correct view based on the client’s IP.
Use case: Organizations where internal users access private services (like intranets) while external users access public services, enhancing security and performance.
Diagram:
Internal Network External Network
+-------------------+ +-------------------+
| Internal User | | External User |
+-------------------+ +-------------------+
| |
v v
+-------------------+ +-------------------+
| DNS | | DNS |
| (Internal View) | | (External View) |
+-------------------+ +-------------------+
| |
v v
+-------------------+ +-------------------+
| Private IP App | | Public IP App |
+-------------------+ +-------------------+✅ Response Policy Zones (RPZ)
Response Policy Zones (RPZ) are a security feature that allows DNS servers to rewrite or block responses for specific domains based on predefined rules. Although not a routing policy in the strict sense, RPZ shapes DNS traffic by controlling how queries are resolved.
How it works: DNS servers use RPZ rules to match domain names and trigger actions like blocking or redirecting queries (e.g., returning NXDOMAIN for malicious sites).
Use case: Enterprises that want to enforce security policies such as blocking malware domains or parental controls.
Diagram:
+-------------------+
| Users |
+-------------------+
|
v
+-------------------+ Match Rule? +-------------------+
| DNS | ----------------> | RPZ Zone |
+-------------------+ +-------------------+
| |
| Normal Response | Block/Redirect
v v
+-------------------+ +-------------------+
| Valid App | | NXDOMAIN/Error |
+-------------------+ +-------------------+✅ Combining Techniques for Sophisticated Architectures
In practice, DNS strategies are layered to meet complex requirements:
- ECS + Geolocation ensures users behind public resolvers are routed correctly based on their actual location.
- Weighted + Failover Routing helps gradually migrate traffic while maintaining high availability.
- GSLB + Monitoring balances traffic dynamically across regions with real-time failover.
Testing configurations in a staging environment is crucial to prevent unintended routing loops or downtimes.
🌐 Implementing DNS Routing Policies in Major Clouds
✅ AWS Route 53
Supports simple, weighted, failover, latency-based, geolocation, geoproximity, multivalue, and IP-based routing.
Example for Weighted Routing:
- Two A records, one weighted 70%, another 30%.
- Health checks for automatic failover.
CLI example:
aws route53 change-resource-record-sets --hosted-zone-id Z123456 --change-batch file://weighted.json
✅ Azure Traffic Manager
- Supports performance (latency), weighted, priority (failover), geographic, multivalue, and subnet routing.
- Example for Geolocation Routing:
- Create a profile.
- Assign regions to endpoints.
- Configure nested profiles.
New-AzTrafficManagerProfile -Name "myProfile" -ResourceGroupName "myRG" -TrafficRoutingMethod Geographic -MonitorProtocol HTTP -MonitorPort 80✅ GCP Cloud DNS
- Supports simple, weighted round-robin, geolocation, and failover routing.
- Example for Failover Routing:
gcloud dns record-sets create example.com --rrdatas="192.0.2.1" --type=A --ttl=300 --routing-policy-type=FAILOVER --routing-policy-data='{"primary": ["192.0.2.1"], "backup": ["203.0.113.1"], "enable_geo_fencing": false}'| Policy | AWS Route 53 | Azure Traffic Manager | GCP Cloud DNS |
|---|---|---|---|
| Simple | ✅ | ✅ | ✅ |
| Weighted | ✅ | ✅ | ✅ (WRR) |
| Failover | ✅ | ✅ (Priority) | ✅ |
| Latency | ✅ | ✅ (Performance) | Via Load Balancer |
| Geolocation | ✅ | ✅ | ✅ |
| Geoproximity | ✅ | Not directly | Not directly |
| Multivalue | ✅ | ✅ | Not native |
| IP-Based | ✅ | ✅ | Not native |
✅ Best Practices and Considerations
✔ Always enable health checks to avoid routing traffic to unhealthy endpoints.
✔ Use monitoring tools like CloudWatch (AWS), Azure Monitor, or Stackdriver (GCP) to track DNS performance.
✔ Keep costs in mind — advanced policies can increase query charges.
✔ Implement security best practices like DNSSEC to prevent spoofing.
✔ Test your setups using tools like dig or nslookup.
📌 Conclusion
Cloud DNS routing policies are essential tools for optimizing user traffic in global environments. From simple routing to advanced geoproximity strategies, these techniques enhance performance, availability, and compliance. Whether you’re experimenting with weighted routing or implementing latency-based policies at scale, mastering DNS strategies will empower you to build faster, more resilient systems across AWS, Azure, and GCP.
Start small, monitor frequently, and scale intelligently. With the right routing policies, your applications will be ready to meet global demands with confidence!
Cheers,
Sim