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:

1. User device
   This is the laptop, phone, smart TV, or server asking for a domain.
2. Recursive resolver
   This is usually operated by an ISP, company, public DNS provider, or local network.
3. 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:

1. The recursive resolver may cache the answer.
2. The user device may cache the answer.
3. The application may reuse an existing connection.
4. The requester may use a public DNS resolver far from the real user.
5. The user may connect through VPN, proxy, carrier-grade NAT, or enterprise DNS.
6. 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:

1. Sending users to a preferred regional endpoint.
2. Steering users based on ISP or ASN.
3. Avoiding unhealthy endpoints.
4. Supporting active-backup service design.
5. Reducing cross-region traffic.
6. Improving first-hop service selection.
7. 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:

1. Per-request traffic control.
2. Exact percentage-based traffic control at the connection level.
3. Instant failover for all active users.
4. Decisions based on real-time application state per user.
5. Replacing a proper load balancer.
6. Replacing application-level retry logic.
7. 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.