/// article

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

By lordfrancs3

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