When users access my website, Amazon Route 53 latency-based routing returns the IP address of a server in a Region that is far away. For example, if a user in the USA tries to access my website, Route 53 responds with a record from a server in Europe. How can I troubleshoot issues with users being routed to suboptimal Regions?

When you associate endpoints in multiple AWS Regions with the same resource record and use a latency-based routing policy, Route 53 resolves to the Region with the lowest latency based on the location of the DNS query.

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, only if the DNS resolver supports the extension EDNS0-Client-Subnet.
    Note: Route 53 name servers support EDNS0-Client-Subnet by default. When a recursive DNS resolver that supports EDNS0-Client-Subnet sends Route 53 a truncated version of the client IP address, Route 53 uses the client IP address to determine the lowest latency Region.

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

Find DNS resolver IP and Anycast support

Check the IP address range used by the resolver in a particular Region. Run the following commands 5 or 6 times for a period of 11 seconds. Then, 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

Note: 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 the 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.

Find the client IP address

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

Or, use curl in the AWS Command Line Interface (AWS CLI):

curl http://checkip.amazonaws.com/

Check if the DNS resolver supports EDNS0-Client-Subnet

Before proceeding, be sure to confirm that the DNS resolver supports Anycast, as previously described. Then, check if the DNS resolver supports EDNS0-Client-Subnet using the following commands and 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>

In the query output, the first TXT record returned in the Answer section 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.

Note: Be sure that the TTL value of the response is 60 seconds. If the TTL isn't 60 seconds, the response is a cached response. Repeat the command until the response TTL value is 60 seconds.

Simulate queries from the DNS resolver or client IP address

Use the Route 53 DNS Checking Tool to simulate queries from a specific DNS resolver or client IP address to find which latency resource record set returned by Route 53.

  • 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 Subne 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.

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 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.

Clients with support for EDNS0-Client-Subnet

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.

Change where the client DNS queries exit to a location geographically closer to the client.

Clients without support for EDNS0-Client-Subnet

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.

Change the DNS resolver that the client uses to a different recursive DNS resolver located geographically closer to the client.

Optional: If the DNS resolver doesn't support EDNS0-Client-Subnet and Route 53 routes users to suboptimal Regions as a result, switch to a public recursive DNS resolver that supports EDNS0-Client-Subnet. Then, compare your old latency routing response results from Route 53 with your new results. Some 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 USA 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 USA 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-08-15