Latency, Geography, And Network Distance: What DNS Can And Cannot Know

DNS steering often uses location.

That sounds simple.

If a user is in the Philippines, send the user to Manila.

If a user is in Singapore, send the user to Singapore.

If a user is in Japan, send the user to Tokyo.

This works well in many cases, but it is not always correct.

The nearest location on a map is not always the fastest location on the network.

This is one of the most important lessons in DNS steering.

DNS can use geography as a useful signal. It can use country, region, ASN, resolver IP, and sometimes EDNS Client Subnet. But DNS does not automatically know the real network path between the user and the service endpoint.

DNS steering should not assume that geography, latency, and network distance are the same thing.

They are related, but they are different.

What Is Latency?

Latency is the time it takes for data to travel from one point to another.

In network operations, latency is often measured as round-trip time.

Round-trip time means:

A packet goes from source to destination.
A reply comes back from destination to source.
The total time is measured.

Example:

User to Manila endpoint: 20 ms
User to Singapore endpoint: 45 ms
User to Tokyo endpoint: 80 ms

In this example, Manila looks best because it has the lowest latency.

Lower latency usually means faster response for interactive systems such as websites, APIs, login flows, games, and video startup.

But DNS usually does not measure real latency for every user before answering.

DNS often works with indirect signals.

What Is Geography?

Geography is physical location.

In DNS steering, geography usually means an estimated location based on an IP address.

Common geographic fields include:

Country
Region
City
Continent
Latitude and longitude

Example:

Requester IP: 203.0.113.50
Estimated country: Philippines
Estimated region: Metro Manila

A DNS steering policy may use this information to choose a nearby service endpoint.

Example:

If requester country is PH, return Manila endpoint.
If requester country is SG, return Singapore endpoint.
If requester country is JP, return Tokyo endpoint.

This is useful, but it is still an estimate.

IP geolocation providers also warn that IP geolocation is not perfect. Country-level accuracy is usually stronger than city-level accuracy, while mobile networks, VPNs, proxies, and some ISP practices can reduce accuracy.

Sources:

https://support.maxmind.com/knowledge-base/articles/maxmind-geolocation-accuracy
https://support.maxmind.com/knowledge-base/articles/restrictions-on-ip-geolocation

What Is Network Distance?

Network distance is not the same as map distance.

Network distance describes how close two systems are from the point of view of the internet path.

It may involve:

Number of network hops
Round-trip time
Peering relationships
ISP routing policy
Transit provider path
Congestion
Packet loss
Routing changes

Two places may be close on a map but far on the network.

Example:

User is in City A.
Endpoint is also in City A.
But the ISP routes traffic through another country first.

This can happen because of peering, upstream transit, or routing policy.

The result may be worse latency even if the endpoint is physically nearby.

The opposite can also happen.

Two places may be far on a map but close on the network because their networks have good peering or direct transport.

RFC 7871 describes this difference clearly. It explains that topological distance is only loosely related to geographic distance.

Source:

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

What DNS Can Know

A DNS steering system can know several useful things at query time.

But each signal has limits.

1. The Requested Name

DNS knows what name was requested.

Example:

video.example.com
api.example.com
login.example.com

This matters because different names may have different routing needs.

A video service may prefer edge delivery.

An API may prefer the nearest healthy region.

A login system may prefer fewer failovers and stronger consistency.

2. The Record Type

DNS knows the query type.

Example:

A
AAAA
CNAME
TXT
MX

For DNS steering, A and AAAA records are usually important because they return IPv4 and IPv6 addresses.

3. The Resolver IP

The authoritative DNS server usually sees the IP address of the recursive resolver.

Example:

Source IP seen by authoritative DNS:
Resolver IP

This resolver may be operated by an ISP, company, school, office, cloud provider, or public DNS service.

The resolver IP is often the main signal used for requester classification.

But it may not be the real user IP.

4. The Estimated Location Of The Resolver

The DNS steering system can map the resolver IP to a country, region, or city using GeoIP data.

Example:

Resolver IP location:
Singapore

Possible DNS answer:
Singapore endpoint

This can work well when the resolver is near the user.

It can work poorly when the resolver is far from the user.

5. The ASN

ASN means Autonomous System Number.

An ASN identifies a network operator.

Example:

A broadband ISP
A mobile network
A cloud provider
A university network
A corporate network

ASN can be useful because network behavior often depends on the operator.

Two users in the same country may get better performance through different endpoints because their ISPs use different routes.

Example:

ISP A in the Philippines performs better through Manila.
ISP B in the Philippines performs better through Singapore.

A country-only policy may miss this difference.

An ASN-aware policy can handle it better.

6. EDNS Client Subnet

EDNS Client Subnet, or ECS, allows some recursive resolvers to send part of the client network to authoritative DNS.

This can help DNS steering make a better location decision.

Example:

Resolver IP:
Singapore

ECS signal:
Client network in the Philippines

Possible answer:
Manila endpoint

ECS can be useful, but it is not always available.

It also creates privacy and caching concerns.

RFC 7871 describes ECS and notes known operational and privacy issues.

Source:

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

7. Endpoint Health

DNS steering can know whether an endpoint is healthy if the system receives health check data.

Example:

Manila endpoint: healthy
Singapore endpoint: healthy
Tokyo endpoint: unhealthy

Health data helps avoid returning bad endpoints.

But health data must be handled carefully.

A health check may be stale, missing, or wrong.

A safe DNS steering system should know what to do when health data is incomplete.

What DNS Cannot Know Perfectly

DNS has useful signals, but it does not know everything.

1. DNS Usually Does Not Know The Real User IP

In many cases, the authoritative DNS server sees the recursive resolver IP, not the real user IP.

Example:

Real user:
Phone in Manila

Recursive resolver:
Public resolver in Singapore

Authoritative DNS sees:
Singapore resolver IP

If the system only uses the resolver IP, it may choose Singapore.

That may or may not be the best answer for the real user.

2. DNS Does Not Know The Full Network Path

DNS usually does not know the exact route that traffic will take after the user connects.

The path may change because of:

BGP routing changes
ISP peering changes
Congestion
Transit provider issues
Packet loss
Maintenance events
Traffic engineering

DNS can use known signals, but it does not see every packet path in real time.

3. DNS Does Not Know Real Latency For Every User

DNS can estimate.

It can use measurements, logs, probes, or historical data.

But during a normal DNS query, it usually does not test every possible endpoint from the actual user before answering.

That would be too slow.

DNS answering must remain fast.

4. DNS Does Not Know Application Performance

DNS may know that an endpoint is reachable.

But reachable does not always mean good.

Example:

TCP port is open.
HTTP health check returns 200.
But the application is slow.
Database queries are delayed.
Video startup is poor.

DNS can receive health status from other systems, but it does not naturally know full application performance by itself.

5. DNS Does Not Control Resolver Caching

DNS responses include TTL.

TTL tells resolvers how long they may cache the answer.

But DNS steering cannot force every resolver and application to behave exactly the same way.

Caching can delay policy changes and failover.

DNS TTL behavior is part of standard DNS operation.

Sources:

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

Geography Can Be Good Enough

Even with limits, geography is still useful.

Country-level routing can solve many practical problems.

Example:

Philippines users should usually not be sent to Europe.
Singapore users should usually not be sent to North America.
Japan users should usually not be sent to Brazil.

Geography gives a simple first guess.

It helps reduce clearly bad answers.

It also makes routing policy easier to understand.

Example policy:

PH users use Manila.
SG users use Singapore.
JP users use Tokyo.
Other users use global default.

This kind of policy is simple and practical.

But it should not be treated as perfect.

When Geography Is Not Enough

Geography may fail when the network path does not match the map.

Example:

A user is in the Philippines.
The Manila endpoint is physically near.
But the user's ISP has poor routing to that Manila endpoint.
The Singapore endpoint has better peering.
Singapore gives lower latency.

In this case, a simple country rule may return the wrong answer.

Another example:

A user is in Indonesia.
The nearest endpoint on a map is Singapore.
But the user's ISP has a better route to Hong Kong.
Hong Kong gives better real performance.

This is why DNS steering should consider network behavior, not only country.

Why ASN Matters

ASN is one way to improve routing decisions.

A country rule says:

All users in PH use Manila.

An ASN-aware rule says:

PH users from ISP A use Manila.
PH users from ISP B use Singapore.
PH users from ISP C use Manila.
Unknown PH users use default PH policy.

This gives better control.

It accepts that different networks inside the same country can behave differently.

ASN routing is useful when operators know that certain ISPs perform better through certain endpoints.

Why Measurement Matters

Good DNS steering should not depend only on static assumptions.

Operators should measure.

Useful measurements include:

DNS query volume by country and ASN
Answer distribution by endpoint
Observed application latency by region
Error rate by endpoint
Health check status
Fallback usage
User complaints by network
Synthetic probe results
Real user monitoring, if available

Measurement helps answer practical questions:

Are PH users really faster through Manila?
Is ISP A better through Singapore?
Did latency change after a routing update?
Are users still reaching an unhealthy endpoint?
Is the fallback being used too often?

DNS steering improves when policy is guided by observed behavior.

The Role Of Safe Defaults

Because DNS cannot know everything, every DNS steering system needs safe defaults.

Example:

If country is unknown, use global endpoint.
If ASN is unknown, use country policy.
If ECS is missing, use resolver IP.
If preferred endpoint is unhealthy, use fallback endpoint.
If all regional endpoints are unhealthy, use last known safe answer or global backup.

Safe defaults protect users when signals are missing or wrong.

The goal is not perfect routing.

The goal is useful and safe routing.

Example: Country-Based Routing

Assume this setup:

Manila endpoint: 203.0.113.10
Singapore endpoint: 198.51.100.20
Tokyo endpoint: 192.0.2.30

Basic policy:

If country is PH, return Manila.
If country is SG, return Singapore.
If country is JP, return Tokyo.
Otherwise, return Singapore.

This is easy to understand.

It works well when geography is a good signal.

But it may fail for some networks.

Example: Country Plus ASN Routing

A better policy may include ASN:

If country is PH and ASN is ISP A, return Manila.
If country is PH and ASN is ISP B, return Singapore.
If country is PH and ASN is unknown, return Manila.
If country is SG, return Singapore.
If country is JP, return Tokyo.
Otherwise, return global default.

This policy is more specific.

It can handle known network differences.

But it also needs more data.

More specific policies require better monitoring, validation, and fallback logic.

Example: Geography Says One Thing, Health Says Another

Assume the requester is in the Philippines.

Normal answer:

Return Manila endpoint.

But Manila is unhealthy.

The DNS steering system should not return Manila just because it is geographically close.

Safer answer:

Return Singapore endpoint.

This shows an important rule:

Health should override geography when the preferred endpoint is not usable.

A nearby broken endpoint is worse than a farther working endpoint.

Example: Geography Says One Thing, Network Data Says Another

Assume this measured performance:

PH ISP A to Manila: 25 ms
PH ISP A to Singapore: 65 ms

PH ISP B to Manila: 110 ms
PH ISP B to Singapore: 45 ms

A country-only policy would send both ISP A and ISP B to Manila.

But the better answer is:

ISP A: Manila
ISP B: Singapore

This is where DNS steering becomes more useful.

It moves from simple geography to network-aware policy.

What Operators Should Avoid

Avoid assuming:

Nearest country is always fastest.
Same country always means low latency.
Resolver location always means user location.
City-level GeoIP is always accurate.
ECS is always present.
Health check success means full application health.
TTL changes take effect instantly.

These assumptions can create poor routing decisions.

Better assumptions:

Geography is a starting point.
ASN can improve accuracy.
Health must protect routing.
Measurements should guide policy.
Missing signals need defaults.
DNS answers influence traffic, but do not fully control it.

Practical Design Rule

Use this rule:

Start with geography, improve with network signals, protect with health, and confirm with measurements.

That rule keeps DNS steering practical.

Geography gives a simple first decision.

Network signals improve the decision.

Health prevents bad answers.

Measurements tell you whether the policy is working.

How This Fits The Article Series

The first article explained how authoritative DNS can influence traffic direction.

The second article explained the control plane and data plane.

The third article explained why DNS steering is not load balancing.

This fourth article adds another important lesson:

DNS can use location, but it should not blindly trust location.

Good DNS steering is careful.

It does not assume perfect knowledge.

It uses available signals, accepts uncertainty, and returns the safest useful answer.

Key Takeaways

Latency, geography, and network distance are related, but they are not the same.

Geography tells you where something appears to be on a map.

Latency tells you how long network communication takes.

Network distance tells you how close two systems are from the point of view of routing, hops, and packet travel time.

DNS can know the requested name, record type, resolver IP, estimated location, ASN, health state, and sometimes EDNS Client Subnet.

DNS cannot perfectly know the real user IP, the full network path, real latency for every user, or application performance for every request.

Country-based routing is useful, but it should be treated as a starting point.

ASN-aware policy, health checks, fallback logic, and measurements make DNS steering safer.

The best DNS steering systems do not ask, “Which endpoint is nearest on the map?”

They ask:

Which healthy endpoint is most likely to serve this requester well?

In the next article, we will discuss Inside Requester Classification: IP, ASN, Country, And Resolver Signals.

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

MaxMind, Geolocation Accuracy:
https://support.maxmind.com/knowledge-base/articles/maxmind-geolocation-accuracy

MaxMind, Restrictions on IP Geolocation:
https://support.maxmind.com/knowledge-base/articles/restrictions-on-ip-geolocation