/// article

Weighted, Geo, ASN, And Failover Routing: Steering Techniques Compared

By lordfrancs3

DNS can do much more than return a fixed IP address. An authoritative DNS server can return different answers depending on policy, network information, endpoint health, or distribution rules. This allows operators to influence where users connect without changing the application itself. This idea is commonly called DNS steering. Several steering techniques are widely used: Weighted routing Geographic routing ASN-aware routing Prefix-based routing Failover routing They solve different problems. The important word is influence. DNS can influence which destination a client learns about. It cannot guarantee which network path the client takes, how long the client keeps an address cached, whether an existing TCP connection is reused, or whether traffic will follow an exact percentage. Understanding that boundary is essential before designing a DNS steering system. The Problem Imagine that www.example.com is available from three infrastructure locations. +----------------------+ | www.example.com | +----------+-----------+ | DNS decision | +-----------------+-----------------+ | | | v v v 192.0.2.10 198.51.100.10 203.0.113.10 Site A Site B Site C All three locations can serve the website. The question is: Which address should DNS return? A simple DNS configuration could return all three addresses. That may be enough for some environments. But operators might have additional requirements. For example: Send 70 percent of traffic to Site A and 30 percent to Site B. Send users in one region to Site A and users in another region to Site B. Send subscribers of a particular network provider to Site C. Send a specific client prefix to a specific endpoint. Stop returning Site A when health checks show that it is unavailable. These requirements lead to different steering techniques. Core Concept DNS steering changes the DNS answer based on policy. A basic authoritative answer might look like this: www.example.com. 300 IN A 192.0.2.10 A steering system might instead evaluate information associated with the query before choosing the answer. Conceptually: DNS Query | v +--------------------+ | Determine context | +---------+----------+ | v +--------------------+ | Apply policy | +---------+----------+ | v +--------------------+ | Select eligible IP | +---------+----------+ | v DNS Response The policy might consider: Health Prefix ASN Geography Weight Default policy These inputs do not all perform the same job. A useful mental model is: Technique Main Job Prefix-based Match a known network ASN-aware Match a network operator or provider Geographic Match an approximate location Weighted Distribute queries among destinations Failover Remove unavailable destinations This distinction becomes important when several policies are combined. First, Understand Who DNS Actually Sees One of the most important concepts in DNS steering is understanding where the query comes from. A typical lookup looks like this: User | v Stub Resolver | v Recursive DNS Resolver | v Authoritative DNS The authoritative DNS server normally receives the query from the recursive resolver. It may therefore see: Recursive resolver IP rather than: Actual user IP RFC 1034 describes the resolver and authoritative name server model that forms the foundation of DNS operation. This matters greatly for geographic, ASN, and prefix steering. Suppose a user is in Manila but uses a recursive DNS service whose query infrastructure appears somewhere else. If the authoritative DNS server bases its decision only on the recursive resolver’s IP address, it could classify the request differently from the user’s actual network. EDNS Client Subnet EDNS Client Subnet, commonly called ECS, attempts to improve network-sensitive DNS responses. RFC 7871 defines an EDNS option that allows a recursive resolver to provide part of the originating client’s network prefix to an authoritative DNS server. Instead of the authoritative server seeing only: Resolver: X it may receive information similar to: Resolver: X Client network hint: 198.51.100.0/24 The authoritative server can then make a more specific routing decision. Conceptually: Client 198.51.100.x | v Recursive Resolver | | ECS: 198.51.100.0/24 v Authoritative DNS | v Prefix / ASN / Geo policy ECS is built using EDNS mechanisms described by RFC 6891. However, ECS is not something operators should assume will always exist. RFC 7871 itself identifies privacy, caching, and operational concerns. It is an Informational RFC rather than an Internet Standards Track specification. A DNS steering system therefore needs sensible behavior both with and without ECS. 1. Weighted Routing Weighted routing is one of the simplest steering techniques. You assign relative weights to destinations. For example: Site A: 70 Site B: 30 The intended distribution is approximately: Site A ############################### 70% Site B ############# 30% Possible DNS answers: www.example.com -> 192.0.2.10 www.example.com -> 192.0.2.10 www.example.com -> 198.51.100.10 www.example.com -> 192.0.2.10 Over enough DNS decisions, the selection process can approach the configured ratio. When Weighted Routing Is Useful Weighted steering works well for: Gradual infrastructure migrations Introducing a new location Canary deployments Capacity distribution Controlled testing Gradual traffic shifts Active-active deployments For example, when introducing Site B: Stage 1 Site A: 95 Site B: 5 Stage 2 Site A: 80 Site B: 20 Stage 3 Site A: 50 Site B: 50 This allows operators to increase exposure gradually. Where Weighted Routing Fails A DNS weight does not equal an exact percentage of application traffic. Consider this configuration: Site A: 50 Site B: 50 It is tempting to assume that HTTP traffic will also be split exactly 50/50. That assumption is wrong. DNS caching changes the result. Suppose Resolver A serves 100,000 users while Resolver B serves 1,000. Resolver A receives: 192.0.2.10 Resolver B receives: 198.51.100.10 The DNS decision was: 50% Site A 50% Site B But user traffic could become approximately: Site A: 100,000 users Site B: 1,000 users DNS query distribution and application traffic distribution are different measurements. Caching is a fundamental part of DNS. RFC 1034 defines TTL as the time limit controlling how long resource records can remain cached. Other factors also affect weighted results: Resolver cache populations Application DNS caching Client connection reuse Unequal user activity Long-lived connections Endpoint capacity Retries Resolver behavior Weighted DNS should therefore be treated as probabilistic steering, not precise traffic accounting. 2. Geographic Routing Geographic routing chooses an answer based on the estimated geographic location associated with the DNS request. Example policy: Philippines -> Site A Singapore -> Site B United States -> Site C Default -> Site A Conceptually: DNS Query | v Geographic lookup | +------------+------------+ | | | v v v Region A Region B Region C | | | v v v 192.0.2.10 198.51.100.10 203.0.113.10 Geo routing is commonly used when infrastructure exists in several regions. When Geographic Routing Is Useful Geographic routing can help with: Regional infrastructure placement Reducing unnecessary long-distance connections Regional application deployments Localization Regulatory boundaries Regional capacity management Keeping users near intended infrastructure For example: Users associated with Region A | v 192.0.2.10 Users associated with Region B | v 198.51.100.10 This looks simple. The difficult part is determining what “associated with Region A” actually means. Geography Is an Estimate An authoritative DNS server usually sees the recursive resolver. Without ECS, geographic routing may effectively mean: Location of resolver rather than: Location of user These can differ. Several situations make geographic classification less reliable: Public recursive DNS services Centralized enterprise resolvers VPN services Mobile carrier infrastructure Network address translation Resolver anycast Corporate networks Users crossing regional boundaries ECS can provide a network prefix that may improve the classification, but ECS availability cannot be assumed. RFC 7871 also documents privacy and cache implications associated with sending client subnet information. Geographic Routing Does Not Measure Network Quality Another common mistake is assuming: Nearest geographically = fastest That is not always true. Consider: User | +------ 800 km ------ Site A | +----- 1,500 km ----- Site B Site B might still perform better if: The ISP peers directly with Site B. Site A requires several transit networks. Site A is congested. Site B has better upstream connectivity. Routing policy sends traffic along a better path. DNS geographic steering understands geography. It does not automatically understand Internet routing quality. That limitation leads us to ASN-aware steering. 3. ASN-Aware Routing An Autonomous System Number, or ASN, identifies an autonomous system participating in Internet routing. ISPs, cloud networks, large enterprises, carriers, and other network operators commonly operate autonomous systems. ASN-aware DNS steering asks a different question. Instead of: Where is this request located? it asks: Which network does this request belong to? Conceptually: DNS request | v Determine network prefix | v Map prefix to ASN | v Apply ASN policy Example: ISP A -> Site A ISP B -> Site B ISP C -> Site C Others -> default policy Why ASN Steering Can Be Useful Imagine two infrastructure locations. Site A | Provider X | | Internet | | Provider Y | Site B Users from ISP A might have excellent connectivity to Site A. Users from ISP B might have much better connectivity to Site B. Both groups may be located in the same city. A geographic rule would treat them as equivalent. An ASN rule can distinguish them. Example: Same geographic area ISP A users ----------> Site A ISP B users ----------> Site B This can be useful when operators have real network knowledge such as: Known peering relationships Transit behavior ISP-specific congestion patterns Carrier-specific paths Infrastructure connected directly to certain networks Where ASN Steering Fails The same resolver visibility problem appears again. Without ECS, the authoritative server may identify: ASN of recursive resolver instead of: ASN of actual client That distinction matters. Consider: User on ISP A | v Public DNS Resolver | v Authoritative DNS The authoritative server might classify the query using the public DNS provider’s network. The steering decision would then be based on the wrong ASN for the user. ECS can help because it can provide part of the client’s network prefix. But again, ECS should be treated as an optional signal rather than a universal feature. ASN databases also change as routing announcements change. Operators must keep network-to-AS mappings current. 4. Prefix-Based Routing Prefix steering is more specific than ASN routing. Instead of matching an entire network operator, the DNS policy matches a particular IP prefix. Example: 198.51.100.0/24 -> Site A 203.0.113.0/24 -> Site B Default -> Site C Conceptually: Query context | v 198.51.100.0/24 ? | yes | v 192.0.2.10 This allows very precise policy rules. Why Prefix Routing Exists An ISP may operate many prefixes. Those prefixes may represent: Different regions Different access networks Different upstream providers Different peering points Different network generations Different customer groups An ASN rule might be too broad. For example: ASN ExampleNet | +-- Prefix A -> Site A works best | +-- Prefix B -> Site B works best | +-- Prefix C -> Site B works best An ASN-wide rule would lose that distinction. Prefix policies allow finer control. Longest Prefix Matching When prefix rules overlap, the more specific prefix generally needs to take priority. Consider: 198.51.100.0/24 -> Site A 198.51.100.0/25 -> Site B A client associated with: 198.51.100.42 matches both prefixes. The /25 is more specific. Conceptually: 198.51.100.0/24 |-----------------------------------------------| 198.51.100.0/25 |-----------------------| Client 198.51.100.42 ^ The more specific policy should normally be selected. Longest-prefix matching is also part of ECS-aware cache handling described by RFC 7871. Where Prefix Routing Fails Prefix routing gives operators more control, but it also creates more operational work. Networks change. Prefixes may be: Added Removed Split Aggregated Moved Announced by another network Reassigned Large prefix policy tables can also become difficult to understand. For example: 198.51.100.0/20 198.51.100.0/21 198.51.104.0/22 198.51.104.0/23 198.51.105.0/24 Without clear policy rules and change management, overlapping prefixes can produce unexpected answers. Prefix steering should therefore be used where the additional precision provides a clear operational benefit. 5. Failover Routing Failover steering solves a different problem. The question is no longer: Which destination is preferred? The question becomes: Which destinations are currently eligible to receive new DNS-directed traffic? Consider: Primary 192.0.2.10 Secondary 198.51.100.10 Normal operation: www.example.com | v 192.0.2.10 If health checks determine that Site A should no longer receive new traffic: www.example.com | v 198.51.100.10 Conceptually: Health Check | v Primary OK? / \ yes no / \ v v 192.0.2.10 198.51.100.10 Failover Should Usually Be an Eligibility Layer Failover is often better understood as a filter around other steering policies. Imagine this configuration: Site A weight: 60 Site B weight: 30 Site C weight: 10 Under normal conditions: Eligible destinations: Site A Site B Site C Now Site B becomes unavailable. The system should first remove Site B from consideration. Eligible destinations: Site A Site C Weighted routing can then operate across the remaining destinations. Conceptually: All destinations | v Health filtering | v Eligible destinations | v Prefix / ASN / Geo policy | v Weighted selection | v DNS answer This illustrates why failover and weighted routing are not really competing techniques. They operate at different stages of the decision. DNS Failover Is Not Instant Failover This is one of the most important operational lessons in DNS steering. Suppose: www.example.com TTL = 300 seconds A recursive resolver receives: 192.0.2.10 Thirty seconds later, that destination fails. Your authoritative system might immediately change its answer to: 198.51.100.10 But the recursive resolver can still have the old answer cached. Authoritative DNS 198.51.100.10 X Recursive cache 192.0.2.10 DNS cannot remotely erase that cache. RFC 1034 defines TTL as the time limit on how long an RR can remain cached. This means DNS failover should be thought of as: Steering future DNS resolutions away from a failed destination. It does not guarantee immediate movement of every active user. Serve-Stale Makes This Even More Interesting Some recursive resolvers can return expired DNS information when authoritative resolution is temporarily unavailable. RFC 8767 describes this behavior as serving stale data to improve DNS resiliency. That is useful during DNS outages. But it also means operators should avoid thinking of TTL expiration as an absolute guarantee that an old answer can never appear again. DNS behavior during failures involves several systems: Authoritative DNS Recursive resolver Resolver cache Client cache Application Network Destination server A steering system controls only part of this chain. Negative Caching Matters Too Suppose an operator accidentally returns: NXDOMAIN during an outage. That negative answer may itself be cached. RFC 2308 defines negative caching behavior for DNS. This can create a worse incident. Instead of clients receiving a less desirable destination, they may believe the hostname does not exist. That is why operators should be very careful about using NXDOMAIN as part of failover logic. An unavailable backend does not normally mean the DNS name stopped existing. Comparing the Five Techniques Here is a practical comparison. Technique Decision Input Main Purpose Main Weakness Weighted Configured ratios Distribute DNS selections Does not guarantee traffic percentages Geographic Approximate location Regional steering Resolver location may differ from user ASN-aware Network operator ISP or carrier steering Resolver ASN may differ from user ASN Prefix-based Network prefix Precise network policies Policy maintenance becomes complex Failover Health state Avoid unhealthy destinations DNS caches delay complete traffic movement Another way to view them: Precision ^ | Prefix | ********** ASN | ******** Geo | ****** Weighted | *** | +--------------------> Policy specificity Failover does not fit neatly on this scale because it answers a different question: whether a destination should remain eligible. A Practical Combined Example Consider three service locations. Site A 192.0.2.10 Site B 198.51.100.10 Site C 203.0.113.10 The operator wants the following behavior: Never send new DNS-directed traffic to an unhealthy site. A specific network prefix should use Site B. A particular ISP should use Site C. Users associated with Region A should prefer Site A. Everyone else should be distributed between Site A and Site B. If no special rule applies, return a safe default. Conceptually: DNS Query | v Determine context | v Remove unhealthy destinations | v Prefix match? / \ yes no | | v v Prefix ASN match? policy / \ yes no | | v v ASN Geo match? policy / \ yes no | | v v Geo Weighted policy default This is only a conceptual model. Real implementations may arrange policy stages differently. The important design rule is consistency. Operators should be able to answer: If several rules match the same DNS request, which rule wins? If that question has no clear answer, the steering design is already too difficult to operate safely. A Practical DNS Query Test Operators can inspect DNS answers using dig. For example: dig www.example.com A To display only the returned address: dig www.example.com A +short During testing, query more than one recursive resolver and compare the result. You can also query an authoritative server directly: dig @ns1.example.com www.example.com A If your test environment supports ECS, BIND’s dig can construct queries containing an ECS prefix. Conceptually: dig @ns1.example.com www.example.com A +subnet=198.51.100.0/24 This is useful for controlled testing of network-specific policies. Do not assume that ordinary public DNS queries will always carry ECS information. DNS Can Influence Traffic, But It Does Not Control the Internet DNS steering is powerful because it operates before a client connects to the destination. But its control stops there. DNS can influence: Which IP address is returned Which destination is preferred Which destinations remain eligible Which networks receive particular answers Approximate distribution of DNS selections DNS cannot fully control: The Internet route selected by BGP Network latency Packet loss TCP connection state Existing client connections HTTP session state Resolver cache behavior beyond DNS rules Application-specific caching Client retry logic Exact traffic percentages HTTP operates at the application level and has its own request and connection behavior, as defined in RFC 9110. TCP also maintains transport-layer connection state independently of DNS resolution, as described by RFC 9293. Changing a DNS response therefore does not magically move an existing TCP connection. Design Risks DNS steering introduces policy into a system that many operators expect to be simple. That creates several risks. 1. Overly Complex Policies Consider: Prefix overrides ASN ASN overrides country Country overrides region Region applies weights Weights depend on health Health has multiple states This may be technically possible. It may also become extremely difficult to troubleshoot. Start with the smallest rule set that solves the actual requirement. 2. Assuming Resolver IP Equals User IP This mistake affects: Geographic routing ASN routing Prefix routing Always distinguish: DNS query source from: Actual application client They may represent different networks. 3. Treating Weight as Exact Traffic Distribution A weight of: 80 / 20 does not guarantee: 80% / 20% HTTP traffic DNS caching makes that impossible to promise accurately from DNS alone. 4. Using Very Low TTLs Everywhere Operators sometimes set TTLs extremely low because they want faster steering changes. That has costs. Lower TTLs generally cause more frequent DNS resolution and greater dependence on the availability of authoritative infrastructure. TTL should match the operational requirement rather than simply being made as small as possible. RFC 1034 explicitly describes TTL as the mechanism controlling how long cached resource records may be retained. 5. Assuming Geo Means Lowest Latency Geography is only one input. Real Internet performance depends on: BGP routing Peering Transit Congestion Capacity Routing policy Network failures Geographic distance cannot describe all of these. 6. Making Failover Too Sensitive Suppose one health probe fails. Should the DNS system immediately remove the destination? Maybe not. A single failed probe could result from: Packet loss Temporary probe failure Monitoring node problems Short application pause Network congestion Health policy needs enough evidence to avoid unnecessary route changes. At the same time, it must react quickly enough to real failures. This balance belongs to health-check design, which should be treated separately from basic DNS policy. 7. Forgetting About Recovery Failover gets most of the attention. Recovery matters just as much. Consider: Primary fails | v Secondary activated | v Primary recovers | ? Should traffic immediately return? Should it return gradually? Should the recovered endpoint remain under observation first? Could weighted routing return a small percentage before full restoration? Operators should define recovery behavior before an incident occurs. Operator Rules A few rules make DNS steering much easier to operate. Rule 1: Always Have a Default Every steering policy should eventually lead to an answer. Example: Prefix policy | no match v ASN policy | no match v Geo policy | no match v Default Unknown networks should not become accidental outages. Rule 2: Prefer Specific Policies Over Broad Policies A useful conceptual hierarchy is: Specific prefix | v ASN | v Geography | v General policy This is not a protocol requirement. It is an operational pattern that makes policy easier to understand. Rule 3: Treat Health as Eligibility An unhealthy destination should usually be excluded before distribution rules choose among destinations. Candidates | v Health filter | v Eligible candidates | v Steering policy This keeps availability logic separate from routing preference. Rule 4: Never Assume ECS Your policy must work when ECS is absent. Think of ECS as additional context. Do not make basic DNS resolution depend completely on receiving it. RFC 7871 describes ECS as a mechanism for carrying network information, but it also documents cache and privacy concerns. Rule 5: Know What You Are Measuring Measure at least three things separately: DNS queries DNS answers Application traffic They are related. They are not identical. For example: 50% DNS selections does not necessarily produce: 50% HTTP requests Rule 6: Log the Reason for a Decision When troubleshooting a steering system, the final answer alone is often insufficient. Operators should be able to determine why a policy returned a destination. Conceptually: Query: www.example.com Context: Prefix matched: no ASN matched: ISP-B Geo: Region-A Health: Site A = healthy Site B = healthy Decision: ASN policy Answer: 198.51.100.10 Without decision visibility, complex DNS policies become difficult to troubleshoot. Rule 7: Test Policies From Multiple Networks Do not test geo or ASN steering from one workstation and assume everything works. Test from: Different ISPs Different recursive resolvers Different regions Networks with ECS Networks without ECS IPv4 IPv6, where supported You need to observe the system from more than one point of view. Common Mistakes Mistake 1: “DNS Load Balancing Means Equal Traffic” No. DNS controls answers. Application load depends on many additional systems. Mistake 2: “The Authoritative Server Knows the User IP” Usually not. It normally sees the recursive resolver unless additional client subnet information is available. Mistake 3: “Geo Routing Always Sends Users to the Fastest Server” No. Geography and network performance are different measurements. Mistake 4: “ASN Routing Is Always More Accurate Than Geo” Not necessarily. If the authoritative server sees a public resolver’s network, both ASN and geographic classification may be based on the resolver rather than the user. Mistake 5: “Prefix Routing Should Handle Everything” Prefix routing can become difficult to maintain when thousands of specific policies accumulate. Use specificity only where it provides a clear benefit. Mistake 6: “Failover Happens Immediately” DNS updates can happen quickly at the authoritative server. Cached answers can continue directing clients toward the previous destination. Existing connections can also continue independently of DNS. Mistake 7: “TTL Is a Global Expiration Switch” TTL controls DNS caching behavior, but real systems include recursive caches, application caches, and serve-stale behavior. RFC 8767 specifically describes circumstances where resolvers may serve expired DNS information after refresh attempts fail. Key Takeaways Weighted, geographic, ASN-aware, prefix-based, and failover routing solve different problems. Think of them this way: WEIGHT "How should selections be distributed?" GEO "Which approximate location does this request represent?" ASN "Which network operator does this request represent?" PREFIX "Does this request belong to a specific network?" FAILOVER "Which destinations are currently allowed to receive new traffic?" Weighted routing is good for gradual distribution, but it cannot guarantee exact traffic percentages. Geographic routing is useful for regional policies, but geographic proximity does not guarantee good network performance. ASN-aware routing can account for network-provider differences, but resolver visibility can reduce accuracy. Prefix-based routing gives the most specific network policy, but large prefix tables create operational complexity. Failover routing helps stop new DNS-directed traffic from going toward unhealthy infrastructure, but caching prevents DNS failover from being instantaneous. The most important lesson is simple: DNS steering influences where new connections may go. It does not directly control every connection, packet, route, cache, or application session. Good DNS steering begins by respecting that boundary. The remaining articles can build on this model by examining topics such as health evaluation, policy ordering, failure handling, observability, testing, operational safeguards, and production-readiness practices. The important point is that DNS steering is not one routing algorithm. It is a collection of policy tools. Good engineering comes from understanding what each tool can do, what information it depends on, and where its control ends. Sources RFC 1034: Domain Names – Concepts and Facilities Defines the core DNS architecture, resolvers, authoritative name servers, resource records, caching, and TTL concepts. RFC 1034, RFC Editor RFC 1035: Domain Names – Implementation and Specification Defines the DNS protocol, message formats, queries, responses, and resource record representation. RFC 1035, RFC Editor RFC 6891: Extension Mechanisms for DNS, EDNS(0) Defines the extension framework used by modern DNS mechanisms, including the foundation used by ECS. RFC 6891, RFC Editor RFC 7871: Client Subnet in DNS Queries Documents EDNS Client Subnet and discusses tailored DNS responses, caching, prefix scope, operational concerns, and privacy considerations. RFC 7871, RFC Editor RFC 8767: Serving Stale Data to Improve DNS Resiliency Describes resolver behavior for using expired cached DNS information when normal refresh attempts fail. RFC 8767, RFC Editor RFC 2308: Negative Caching of DNS Queries Defines caching behavior for negative DNS responses such as NXDOMAIN and NODATA. RFC 2308, RFC Editor RFC 9110: HTTP Semantics Defines HTTP semantics and helps separate DNS steering decisions from application-layer behavior. RFC 9110, RFC Editor RFC 9293: Transmission Control Protocol, TCP Defines TCP operation and connection behavior, useful for understanding why changing DNS does not move an established TCP connection. RFC 9293, RFC Editor