Why DNS Steering Is Not Load Balancing

DNS steering and load balancing are often discussed together.

That is understandable.

Both can influence where traffic goes.

Both can help with failover.

Both can support services that run in more than one location.

But they are not the same thing.

DNS steering works at the DNS layer. It influences the answer returned for a domain name.

Load balancing usually works closer to the connection path. It receives traffic and distributes requests or connections to backend servers.

This difference matters.

If you treat DNS steering as a full load balancer, you may expect behavior that DNS cannot provide. You may expect instant failover, exact traffic distribution, and per-request control. DNS was not designed for that.

DNS steering is useful, but it has limits.

A good system design understands where DNS steering ends and where load balancing begins.

A Simple Definition

DNS steering means:

Use authoritative DNS answers to influence where users connect.

Load balancing means:

Receive traffic and distribute it across multiple backend servers or service endpoints.

The key difference is this:

DNS steering gives the client an address.

Load balancing handles traffic after the client connects.

DNS steering happens before the connection.

Load balancing happens during the connection path.

What DNS Steering Does

A DNS steering system receives a DNS query and returns an answer.

Example:

User asks for:
app.example.com

Authoritative DNS answers:
app.example.com. 60 IN A 203.0.113.10

A more advanced DNS steering system may return different answers based on policy.

Example:

Requester from the Philippines:
app.example.com. 60 IN A 203.0.113.10

Requester from Singapore:
app.example.com. 60 IN A 198.51.100.20

The DNS answer can depend on:

Country
Region
ASN
Resolver IP
EDNS Client Subnet
Endpoint health
Failover policy
Weighted policy
Default policy

The authoritative DNS server gives a recommended destination.

After that, the user or application connects to the returned IP address.

DNS standards define how names, records, and TTL-based caching work. See RFC 1034 and RFC 1035.

Sources:

https://www.rfc-editor.org/rfc/rfc1034
https://www.rfc-editor.org/rfc/rfc1035

What Load Balancing Does

A load balancer usually receives the actual traffic.

Example:

Client connects to:
203.0.113.10

Load balancer receives the connection.

Load balancer sends the request to:
Backend Server 1
Backend Server 2
Backend Server 3

A load balancer may decide based on:

Connection count
Request count
Backend health
HTTP path
Headers
Cookies
TLS information
Session rules
Server weight
Application response

For example, a load balancer may send:

Request 1 to Server A
Request 2 to Server B
Request 3 to Server C

Or it may keep the same user on the same backend using session persistence.

Load balancers such as NGINX and HAProxy are designed to sit in the request path and distribute traffic to backend servers.

Source:

https://docs.nginx.com/nginx/admin-guide/load-balancer/http-load-balancer/
https://www.haproxy.org/

The Main Difference

DNS steering answers this question:

Which address should this requester receive?

Load balancing answers this question:

Which backend should handle this connection or request?

That difference may look small, but it affects the whole design.

DNS steering does not see every HTTP request.

DNS steering does not receive every TCP connection.

DNS steering cannot inspect HTTP paths, cookies, request headers, or application sessions.

DNS steering usually sees a DNS query from a recursive resolver.

That resolver may represent one user, one household, one company, one ISP, or many users.

A load balancer can usually see the actual connection or request.

That gives it more direct control.

DNS Steering Works Before The Connection

When a user opens a website, DNS usually happens first.

A simple flow looks like this:

User device
    |
    | asks DNS resolver
    v
Recursive resolver
    |
    | asks authoritative DNS
    v
Authoritative DNS
    |
    | returns IP address
    v
Recursive resolver
    |
    | returns answer to user
    v
User connects to returned IP

DNS steering can influence the returned IP.

But after the user connects, DNS is no longer in the path.

That means DNS cannot decide where each later HTTP request goes.

It already gave the address.

Load Balancing Works During The Connection

A load balancer sits closer to the traffic.

A simple flow looks like this:

User device
    |
    | connects to service IP
    v
Load balancer
    |
    | forwards traffic
    v
Backend server

The load balancer receives the connection.

It can decide which backend should handle that traffic.

If a backend fails, the load balancer can stop sending new traffic to that backend.

Depending on the protocol and setup, it may retry another backend or return an error.

This is more direct than DNS steering.

Why DNS Cannot Give Exact Traffic Split

Some DNS steering systems support weighted answers.

Example:

70 percent to Manila
30 percent to Singapore

This sounds like load balancing, but it is not exact traffic control.

Why?

Because DNS answers are cached.

A recursive resolver may ask once, receive an answer, and reuse it for many users until TTL expires.

Example:

One resolver gets Manila.
That resolver caches Manila for 60 seconds.
Many users behind that resolver may use Manila.

Another resolver may get Singapore and also cache it.

The final traffic split may not match the configured weight exactly.

DNS can influence distribution.

It cannot guarantee exact per-request distribution.

Resolver Caching Changes The Result

TTL controls how long a DNS answer may be cached.

Example:

app.example.com. 300 IN A 203.0.113.10

A TTL of 300 means the answer may be cached for 300 seconds.

During that time, the recursive resolver may not ask the authoritative DNS server again.

That means policy changes may not affect users immediately.

Example:

10:00 AM:
Resolver receives Manila answer with TTL 300.

10:01 AM:
Manila fails.

10:01 AM to 10:05 AM:
The resolver may still use the cached Manila answer.

A lower TTL may reduce this delay, but it does not remove caching behavior completely.

Some applications and systems also keep DNS answers in their own cache.

This is why DNS failover is useful, but not instant.

DNS Usually Sees The Resolver, Not The User

Another important limit is requester visibility.

The authoritative DNS server usually sees the recursive resolver IP.

It may not see the real user IP.

Example:

Real user:
Mobile phone in Manila

Recursive resolver:
Public resolver in Singapore

Authoritative DNS sees:
Resolver in Singapore

In this case, DNS steering may think the requester is in Singapore.

It may return a Singapore endpoint, even if the real user is in Manila.

EDNS Client Subnet can help in some cases by allowing a recursive resolver to pass part of the client network to authoritative DNS. But ECS is not always available, and it comes with privacy and caching concerns.

Source:

https://www.rfc-editor.org/rfc/rfc7871

Load Balancers See More Traffic Detail

A load balancer can often see details that DNS cannot see.

For HTTP traffic, it may inspect:

Host name
URL path
Request method
Headers
Cookies
Client IP, depending on deployment
TLS SNI
Backend response
Connection count

This allows rules such as:

Send /api traffic to API servers.
Send /video traffic to streaming servers.
Send logged-in users to the same backend.
Send requests away from overloaded servers.
Retry another backend if the first one fails.

DNS steering cannot do this level of request handling.

DNS only answers name resolution queries.

DNS Steering Is Coarse-Grained

DNS steering is best for high-level decisions.

Examples:

Send Philippine requesters to Manila.
Send Singapore requesters to Singapore.
Send ISP A to Endpoint Group 1.
Send ISP B to Endpoint Group 2.
Avoid unhealthy regions.
Move new lookups to a backup site.

These are coarse decisions.

They are useful for regional routing, failover, and network-aware service selection.

But they are not the same as per-request load balancing.

Load Balancing Is Fine-Grained

Load balancing is better for more detailed traffic handling.

Examples:

Distribute requests across 10 backend servers.
Remove one failed backend from rotation.
Keep a user session on the same backend.
Route /admin to a different backend pool.
Apply connection limits.
Retry failed backend connections.

These actions require the system to handle live traffic.

DNS steering does not handle live application traffic.

Common Mistake: Expecting DNS To Drain Traffic Instantly

Operators sometimes expect DNS steering to drain traffic from a failed endpoint immediately.

Example:

Endpoint A fails.
DNS changes the answer to Endpoint B.
All users should move to Endpoint B now.

This is not how DNS works.

Some users may move quickly.

Others may continue using the old answer until their resolver or application cache expires.

Some active connections may remain connected to the old endpoint until the connection fails or closes.

DNS steering helps new lookups receive a safer answer.

It does not force every existing connection to move.

Common Mistake: Expecting Exact Percentages

Another common mistake is expecting exact traffic percentage control.

Example:

Set DNS weight:
50 percent Manila
50 percent Singapore

The actual traffic may become:

60 percent Manila
40 percent Singapore

Or:

45 percent Manila
55 percent Singapore

Why?

Because resolvers cache answers.

One large ISP resolver may represent many users.

Another resolver may represent only a few users.

DNS decisions happen per DNS lookup, not per user request.

So weighted DNS is useful for rough distribution, gradual rollout, and regional preference.

It should not be treated as exact load balancing.

Common Mistake: Replacing Application Retry Logic

DNS steering should not replace application retry logic.

Example:

DNS returns Endpoint A.
Endpoint A becomes unavailable.
The application should retry safely if possible.

If the application cannot retry or reconnect properly, DNS alone may not save the user session.

Good service design often combines:

DNS steering
Load balancing
Health checks
Application retries
Timeouts
Circuit breakers
Monitoring
Rollback

DNS steering is one layer.

It should work with the other layers.

Where DNS Steering Fits

DNS steering works well at the global or regional level.

Example:

User in the Philippines
    |
    | DNS steering returns Manila service IP
    v
Manila load balancer
    |
    | distributes traffic
    v
Manila backend servers

Another user:

User in Singapore
    |
    | DNS steering returns Singapore service IP
    v
Singapore load balancer
    |
    | distributes traffic
    v
Singapore backend servers

In this design, DNS steering chooses the service location.

The load balancer handles traffic inside that location.

This is a strong pattern.

Simple Comparison Table

How To Use Both Together

A practical design uses DNS steering and load balancing together.

Example:

DNS steering:
Choose Manila, Singapore, or Tokyo.

Load balancer:
Distribute traffic across servers inside the selected location.

This design gives you two layers of control.

DNS steering handles broad traffic direction.

Load balancing handles local traffic distribution.

Example flow:

1. User opens app.example.com.
2. DNS steering returns the preferred regional service IP.
3. User connects to that IP.
4. A load balancer receives the connection.
5. The load balancer sends traffic to a healthy backend.

Each layer has a clear job.

Practical Rule For Operators

Use DNS steering when the decision is about:

Which region should answer?
Which network should use which endpoint?
Which site should be preferred?
Which backup should be used when a site is unhealthy?

Use load balancing when the decision is about:

Which backend server should handle this request?
Which connection should be retried?
Which server is overloaded?
Which URL path goes to which backend pool?
Which session should stay on which backend?

This separation makes the system easier to understand and operate.

DNS Steering Can Support Failover, But With Limits

DNS steering can help move new traffic away from unhealthy endpoints.

Example:

Normal state:
app.example.com returns Manila.

Failure state:
Manila is unhealthy.
app.example.com returns Singapore.

This works well for new DNS lookups.

But cached answers may continue to exist until TTL expires.

Because of this, DNS steering failover should be designed with safe expectations:

Use reasonable TTL values.
Monitor answer distribution.
Track fallback usage.
Keep backup endpoints ready.
Combine DNS failover with load balancer health checks.
Design applications to reconnect or retry safely.

The Main Design Principle

The main design principle is this:

DNS steering should decide where a requester should start.

Load balancing should decide how live traffic is handled after connection.

This keeps each layer responsible for the work it can do well.

DNS steering should not pretend to be a full load balancer.

Load balancers should not replace high-level DNS policy.

Both are useful.

They solve different parts of the traffic direction problem.

Key Takeaways

DNS steering is not load balancing.

DNS steering influences traffic by returning DNS answers from the authoritative DNS layer.

Load balancing receives traffic and distributes it across backend servers or service endpoints.

DNS steering is affected by resolver caching, TTL, recursive resolver behavior, and missing requester signals.

Load balancing can make more direct decisions because it usually sees the live connection or request.

Use DNS steering for regional selection, network-aware routing, and failover influence.

Use load balancing for backend distribution, request routing, connection handling, and local service health.

The best production designs often use both.

In the next article, we will discuss Latency, Geography, And Network Distance, and explain what DNS can and cannot know when choosing a destination.

Sources

RFC 1034, Domain Names, Concepts and Facilities:
https://www.rfc-editor.org/rfc/rfc1034

RFC 1035, Domain Names, Implementation and Specification:
https://www.rfc-editor.org/rfc/rfc1035

RFC 7871, Client Subnet in DNS Queries:
https://www.rfc-editor.org/rfc/rfc7871

NGINX HTTP Load Balancing documentation:
https://docs.nginx.com/nginx/admin-guide/load-balancer/http-load-balancer/

HAProxy project website:
https://www.haproxy.org/