Amazon Route 53 latency-based routing is returning a server in an AWS Region far away from the client. For example, when a user in the US tries to access my website, Route 53 returns the IP address of a server in Europe. How do I prevent clients from being routed to AWS Regions far from their location?

Route 53 resolves to the AWS Region with the lowest latency based on the location of the DNS query if the following are true:

Route 53 calculates latency based on:

  • The source IP of the recursive DNS resolver sending the query to the Route 53 authoritative name server.
  • The source IP of the client making the recursive query, if the DNS resolver supports the extension EDNS0-Client-Subnet.

Route 53 name servers support EDNS0-Client-Subnet by default. If a recursive DNS resolver supports EDNS0-Client-Subnet, the DNS resolver sends Route 53 a truncated version of the client's IP address. Route 53 then uses that truncated IP address to determine the lowest latency AWS Region.

The AWS Region with the lowest latency might not be physically closest to the DNS resolver. You might experience unwanted routing behavior if the client isn't in the same location as the DNS resolver or if the resolver's IP address has different location information.

Use the following steps to troubleshoot unwanted latency-based routing behavior:

1. Check the IP address range used by the DNS resolver in a particular AWS Region. Run the following commands 5 or 6 times for a period of 11 seconds. Be sure to note the output each time.

On Linux or macOS, use dig:

for i in {1..10}; do dig +short resolver-identity.cloudfront.net; sleep 11; done;

On Windows use, nslookup:

nslookup resolver-identity.cloudfront.net

2. Confirm that the DNS resolver supports Anycast using the output. If the output always contains the same single IP address, the DNS resolver doesn't support Anycast. If the IP address changes when you run the command multiple times, the DNS resolver supports Anycast.

When a DNS resolver supports Anycast, there are multiple edge locations for DNS resolvers, and a user's edge location is chosen based on optimal latency, which might result in an unexpected location for the resolver IP address.

3. Find the client IP address. From the client machine, visit the following URL in a browser to see the client IP address: https://checkip.amazonaws.com/

Or, use curl:

curl https://checkip.amazonaws.com/

4. Check if the DNS resolver supports EDNS0-Client-Subnet using one of the commands below. Be sure to note the output.

On Linux or macOS, use dig:

dig +nocl TXT o-o.myaddr.l.google.com @<DNS Resolver>

On Windows, use nslookup:

nslookup -type=txt o-o.myaddr.l.google.com <DNS Resolver>

5. Check the first TXT record returned in the Answer section of the output. This value is the nearest DNS server advertising Anycast. If there's no second TXT record, the DNS resolver doesn't support EDNS0-Client-Subnet. If there's a second TXT record, the DNS resolver also supports EDNS0-Client-Subnet. The resolver provides and then sends a truncated client subnet (/24 or /32) to the Route 53 authoritative name server.

6. Check that the TTL value of the response is 60 seconds. If the TTL isn't 60 seconds, the response is a cached response. Repeat your dig or nslookup command until the response TTL value is 60 seconds.

7. If you have access to the Route 53 DNS Checking Tool, simulate queries from a specific DNS resolver or client IP address. Use these queries to find which latency resource record set Route 53 returns.

If the DNS resolver doesn't support EDNS0-Client-Subnet, specify the Resolver IP address as your value in the tool.

If the DNS resolver supports EDNS0-Client-Subnet, specify the EDNS0 client subnet IP as your value in the tool. Choose More Options, and then specify the Subnet mask, too. Don't specify a Resolver IP address.

Note: This tool directly queries the Route 53 latency measurement database to determine the precalculated latency between AWS Regions and an internet network. The tool doesn't actually send DNS queries over the internet or to any DNS resolvers. The simulation tool doesn't check if the DNS resolver supports EDNS0-Client-Subnet. Results from the simulator and an actual DNS query might differ.

8. (Optional) If you don't have access to the Route 53 DNS Checking Tool, use dig to query the Route 53 authoritative name servers for your hosted zone with EDNS0-Client-Subnet. Use the output to determine the lowest latency AWS Region from your source IP:

dig lbr.example.com +subnet=<Client IP>/24 @ns-xx.awsdns-xxx.com +short

Note: Latency between hosts on the internet can change over time due to changes in network connectivity and routing.

9. For clients that support EDNS0-Client-Subnet, change the client DNS queries exit point to a location geographically closer to the client. If the resolver supports EDNS0-Client-Subnet, the client DNS queries might exit from a different location than the client location and result in unexpected routing behavior.

For clients that don't support EDNS0-Client-Subnet, change the DNS resolver that the client uses to a different recursive DNS resolver located geographically closer to the client. If the resolver doesn't support EDNS0-Client-Subnet, the client DNS queries might use a DNS resolver in a different geographic location from the client and result in unexpected routing behavior.

10. (Optional) If the DNS resolver doesn't support EDNS0-Client-Subnet, switch to a public recursive DNS resolver that does support EDNS0-Client-Subnet. Then, compare your old latency routing response results from Route 53 with your new results. For example, two public DNS resolvers that currently support EDNS0-Client-Subnet are GoogleDNS (8.8.8.8 and 8.8.4.4) and OpenDNS (208.67.222.222 and 208.67.220.220).

Troubleshooting example

A company has latency-based routing records for two Elastic Load Balancers located in Virginia (us-east-1) and Ireland (eu-west-1). Users in the US use a corporate DNS resolver located in Europe, or connect to the corporate office in Europe over VPN.

If the corporate DNS resolver isn't capable of sending EDNS0-Client-Subnet data (truncated client IP address information) to the authoritative name servers, Route 53 considers the DNS resolver IP address in Europe to be the source of the query. Route 53 then performs a lookup in its latency database and incorrectly determines that the load balancer in Ireland has the lowest latency.

However, if the corporate DNS resolver is capable of sending EDNS0-Client-Subnet data, Route 53 considers the truncated client IP in the US as the source of the DNS query. Route 53 then performs a lookup in its latency database and correctly determines that the load balancer in Virginia has the lowest latency.


Did this page help you? Yes | No

Back to the AWS Support Knowledge Center

Need help? Visit the AWS Support Center

Published: 2017-09-06

Updated: 2018-11-20