/// article

DNS Steering 101: How Authoritative DNS Influences Traffic Direction

By lordfrancs3

DNS Steering 101: How Authoritative DNS Influences Traffic Direction When a user visits a website, opens an app, or streams a video, one of the first systems involved is DNS. DNS means Domain Name System. It converts names like example.com into IP addresses that computers can connect to. This sounds simple, but DNS can do more than name resolution. When designed carefully, DNS can also influence where users are sent. That is the basic idea behind DNS steering. DNS steering is the practice of using authoritative DNS answers to influence traffic direction. Instead of always returning the same IP address to every requester, an authoritative DNS system can return different answers based on policy, location, network, health status, or other signals. What Happens During A Basic DNS Lookup A user usually does not connect to an authoritative DNS server directly. Most DNS lookups involve these parts: User device This is the laptop, phone, smart TV, or server asking for a domain. Recursive resolver This is usually operated by an ISP, company, public DNS provider, or local network. Authoritative DNS server This server is responsible for the final answer for a domain. For example, when a user opens: www.example.com The user device asks its recursive resolver: What is the IP address of www.example.com? The recursive resolver then finds the authoritative DNS server for that domain and asks it for the answer. The authoritative DNS server may return: www.example.com. 300 IN A 203.0.113.10 This means: Use IP address 203.0.113.10 for www.example.com. Cache this answer for 300 seconds. The number 300 is the TTL. TTL means Time To Live. It tells resolvers how long they may cache the DNS answer. DNS behavior is defined by long-standing DNS standards, including RFC 1034 and RFC 1035. Sources: https://www.rfc-editor.org/rfc/rfc1034 https://www.rfc-editor.org/rfc/rfc1035 Where DNS Steering Happens DNS steering happens at the authoritative DNS layer. The authoritative DNS server does not only answer: What is the IP address of this name? It can also apply logic before answering: Who is asking? Where is the requester likely located? Which network is the requester using? Which service endpoint is healthy? Which routing policy applies? What answer is safest right now? Based on those checks, the DNS answer can change. Example: Requester from the Philippines: www.example.com. 60 IN A 203.0.113.10 Requester from Singapore: www.example.com. 60 IN A 198.51.100.20 Requester from another region: www.example.com. 60 IN A 192.0.2.30 The domain name is the same. The DNS answer changes based on policy. That is DNS steering. Simple Example: Sending Users To A Nearby Service Imagine a company has three service locations: Manila endpoint: 203.0.113.10 Singapore endpoint: 198.51.100.20 Tokyo endpoint: 192.0.2.30 A user in the Philippines opens: video.example.com The DNS steering system may answer with the Manila endpoint. A user in Singapore opens the same domain. The DNS steering system may answer with the Singapore endpoint. A user in Japan opens the same domain. The DNS steering system may answer with the Tokyo endpoint. The goal is simple: Return the most suitable answer for the requester. The most suitable answer is not always the nearest one. It may depend on health, capacity, network path, contract rules, cost, or business policy. DNS Steering Is Influence, Not Full Control This is one of the most important ideas in DNS steering. DNS steering does not fully control user traffic. It influences traffic by returning a DNS answer. After that, several things can happen: The recursive resolver may cache the answer. The user device may cache the answer. The application may reuse an existing connection. The requester may use a public DNS resolver far from the real user. The user may connect through VPN, proxy, carrier-grade NAT, or enterprise DNS. The IP address seen by authoritative DNS may not be the real user IP. Because of this, DNS steering is best understood as a decision system that gives a recommended destination through DNS. It is not the same as a network load balancer. It does not sit directly in the packet path. It does not see every HTTP request. It does not control every connection after resolution. This limitation is not a weakness. It is part of how DNS works. Good DNS steering design respects this limitation. What Signals Can DNS Steering Use? A DNS steering system can use different signals when choosing an answer. Common signals include: Source IP This is the IP address seen by the authoritative DNS server. In many cases, this is the recursive resolver IP, not the real user IP. Country Or Region The system may map the requester IP to a country, region, or city using GeoIP data. This can help send users to a nearby endpoint. ASN ASN means Autonomous System Number. An ASN identifies a network operator, such as an ISP, cloud provider, or large enterprise network. For example, one policy may prefer one endpoint for ISP A and another endpoint for ISP B. Health Status The system may know whether an endpoint is healthy or unhealthy. If an endpoint is down, DNS steering can avoid returning it. Policy A policy defines what answer should be returned under certain conditions. For example: If requester country is PH, return Manila endpoint. If Manila endpoint is unhealthy, return Singapore endpoint. If no rule matches, return global default endpoint. EDNS Client Subnet EDNS Client Subnet, or ECS, allows some recursive resolvers to send part of the client network to authoritative DNS. This can improve requester classification. It also creates privacy, caching, and operational concerns. ECS is defined in RFC 7871. Source: https://www.rfc-editor.org/rfc/rfc7871 Why TTL Matters TTL is very important in DNS steering. A low TTL allows changes to take effect faster. A high TTL reduces DNS query volume and improves cache efficiency. Example: TTL 30 seconds: Changes may take effect faster, but DNS query volume may increase. TTL 300 seconds: Resolvers cache longer, but failover may be slower. There is no perfect TTL for every system. The right TTL depends on the use case. For a static website, a longer TTL may be fine. For failover-sensitive traffic, a shorter TTL may be better. But even with a short TTL, DNS steering is not instant. Resolvers and applications may still cache answers in ways operators cannot fully control. DNS Steering And Failover DNS steering is often used for failover. Example: Primary endpoint: 203.0.113.10 Backup endpoint: 198.51.100.20 Normal answer: app.example.com. 60 IN A 203.0.113.10 If the primary endpoint becomes unhealthy, the authoritative DNS system may answer: app.example.com. 60 IN A 198.51.100.20 This can help new DNS lookups reach the backup endpoint. But existing users may still have the old answer cached until the TTL expires. This is why DNS failover should be designed with realistic expectations. DNS can help move traffic. DNS cannot instantly move every active connection. DNS Steering And Multiple Answers Sometimes DNS returns more than one IP address. Example: api.example.com. 60 IN A 203.0.113.10 api.example.com. 60 IN A 203.0.113.11 api.example.com. 60 IN A 203.0.113.12 This can distribute traffic across multiple endpoints. However, client behavior varies. Some clients use the first answer. Some retry another answer if the first fails. Some resolvers rotate answer order. Some applications cache the result internally. Because of this, multiple DNS answers can help, but they should not be treated as exact traffic control. What DNS Steering Is Good At DNS steering is useful for: Sending users to a preferred regional endpoint. Steering users based on ISP or ASN. Avoiding unhealthy endpoints. Supporting active-backup service design. Reducing cross-region traffic. Improving first-hop service selection. Applying high-level traffic direction policy. It is especially useful when the same service is available in multiple locations. What DNS Steering Is Not Good At DNS steering is weak for: Per-request traffic control. Exact percentage-based traffic control at the connection level. Instant failover for all active users. Decisions based on real-time application state per user. Replacing a proper load balancer. Replacing application-level retry logic. Fixing poor network paths after the client already connected. DNS steering should work with other systems. It should not carry the full responsibility for traffic reliability. A Simple DNS Steering Decision Flow A basic DNS steering decision may look like this: Receive DNS query | Identify requester signal | Check matching policy | Check endpoint health | Select safest valid answer | Return DNS response with TTL A more careful system also handles missing data: If requester cannot be classified, use default policy. If preferred endpoint is unhealthy, use backup endpoint. If health data is stale, use safe fallback. If policy is invalid, return last known safe answer. This is where DNS steering becomes more than a simple DNS record lookup. It becomes a policy decision system. The Main Design Principle The main design principle is this: DNS steering should return the safest useful answer using the signals available at query time. That sentence matters. Safest means the answer should avoid known bad endpoints. Useful means the answer should still help the user reach the service. Signals available means the system should not assume perfect information. At query time means the decision must be fast. Authoritative DNS systems must answer quickly. A slow DNS answer creates a poor user experience before the website, app, or video stream even starts. Practical Example Assume this policy: Users from ISP A in the Philippines should use Manila. Users from ISP B in the Philippines should use Singapore. All other users should use the global endpoint. If any preferred endpoint is unhealthy, use the backup endpoint. A DNS steering system may evaluate a query like this: Domain requested: video.example.com Requester ASN: ISP A Requester country: PH Manila endpoint health: healthy Policy match: ISP A Philippines Answer: Manila endpoint Response: video.example.com. 60 IN A 203.0.113.10 Another query: Domain requested: video.example.com Requester ASN: ISP A Requester country: PH Manila endpoint health: unhealthy Policy match: ISP A Philippines Answer: backup endpoint Response: video.example.com. 60 IN A 198.51.100.20 Same domain. Different condition. Different answer. That is DNS steering in action. Why This Matters Modern services often run across many places: Cloud regions Data centers CDN nodes Streaming edges API clusters Backup origins Hybrid infrastructure Users also come from many networks: Home broadband Mobile networks Corporate networks Public DNS resolvers VPNs Cloud networks A single static DNS answer may not be enough. DNS steering gives operators a way to make smarter authoritative DNS decisions. It helps connect users to better service endpoints while keeping the domain name simple. Key Takeaways DNS steering uses authoritative DNS answers to influence where users connect. It can use signals such as requester IP, country, ASN, health status, policy rules, and sometimes EDNS Client Subnet. DNS steering is useful, but it is not full traffic control. Caching, recursive resolvers, TTL, VPNs, and client behavior all affect the final result. Good DNS steering design does not assume perfect information. It returns the safest useful answer based on the signals available at query time. In the next article, we will discuss the difference between the control plane and the data plane of DNS steering, and why separating them matters in production systems.