How do I troubleshoot Route 53 geolocation routing issues?

6 minute read

My DNS queries return an IP address of a web server in a different AWS Region. For example, a user in the United States is being routed to an IP address of a web server located in Europe.


Route 53 geolocation routing issues are caused by the following issues:

  • There's a missing default location in your geolocation routing setup.
  • The DNS resolver doesn't support the edns0-client-subnet extension of EDNS0. This leads to inaccurate determination of your location.
  • The DNS resolvers are geographically diverse.
  • There are DNS changes for resource records that haven't propagated globally.

To resolve these issues, do the following:

1.    Confirm that the resource records for your Route 53 hosted zone are properly configured for your use case. Also, confirm that there's a default resource record set. From the Route 53 console, check the default location specified in your Route 53 hosted zone configuration.

Example: Consider the following sample output:

>> dig
; <<>> DiG
9.8.2rc1-RedHat-9.8.2-0.37.rc1.45.amzn1 <<>>
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR,
id: 51385
;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 1,

;    IN            A

;; AUTHORITY SECTION:    60          IN           SOA 1 7200 900 1209600 86400

;; Query time: 65 msec
;; WHEN: Tue Feb  7 22:02:30 2017
;; MSG SIZE  rcvd: 124

In the preceding example, there isn't a default location specified in the geolocation routing configuration. So, for a non-matching geolocation, the DNS response returns NOERROR for the rcode field, and there's no result in the ANSWER section. To correct this issue, add a default location in your geolocation routing configuration.

2.    To check the IP address range of the DNS resolver, run the following commands, and then note the output.

On Linux or macOS, use dig:

for i in {1..10}; do dig +short; sleep 11; done;

On Windows, use nslookup:

for /l %i in (1,1,10) do (nslookup && timeout /t 11 /nobreak)

3.    Check if the DNS resolver supports edns0-Client-Subnet using one of the following commands and note the output.

On Linux or macOS, use dig:

dig +nocl TXT

On Windows, use nslookup:

nslookup -type=txt

Review the first TXT record returned in the Answer section of the output. The first TXT record value is the IP address of the DNS resolver. If there isn't a second TXT record, then the DNS resolver doesn't support edns0-client-subnet. If there's a second TXT record, then the DNS resolver supports edns0-client-subnet. The resolver provides a truncated client subnet IP address (/24 or /32) to the Route 53 authoritative name server. For more information, see How can I determine if my public DNS resolver supports the EDNS Client Subnet (ECS) extension?

4.    Use the Route 53 test record set from the checking tool to determine the resource records that are returned for a specific request. For more information, see Using the checking tool to see how Amazon Route 53 responds to DNS queries.

If the DNS resolver doesn't support edns0-client-subnet, then specify the DNS Resolver IP address as your value in the tool.

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

5.    (Optional) If you don't have access to the checking tool, then use dig to query the Route 53 authoritative name servers for your hosted zone with EDNS0-Client-Subnet. Use the output to determine the authoritative geolocation record response for your source IP address:

dig +subnet=<Client IP>/24 +short

6.    Route 53 name servers support the edns0-client-subnet extension of EDNS0.The resolver or local DNS server appends edns0-client-subnet to the DNS query to make a DNS lookup based on the client's source IP subnet. If this data isn't passed with the request, then Route 53 uses the source IP address of the DNS resolver to approximate the location of the client. Then, Route 53 responds to geolocation queries with the DNS record for the resolver's location. The EDNS0 data must be passed to Route 53 and the client must use a geographically closer recursive name server. If not, the result is a suboptimal location serving the incorrect resource record to the DNS query.

To fix this configuration, change the recursive DNS server that supports edns0-client-subnet. Perform the DNS resolution, and then share the output. If the recursive DNS server doesn't support the edns0-client-subnet, then try using one that does. Options that support edns0-client-subnet include Google DNS and OpenDNS resolvers.

7.    Check the geographic location of the client subnet IP address using MaxMind's GeoIP database on the MaxMind website, or your preferred GeoIP database. Verify that the DNS resolver is geographically close to the client's public IP address. If the answer or country on the MaxMind website doesn't match the answer that Route 53 gave, then Route 53's production geo data might be stale. If there's stale routing, then contact AWS Support.

8.    Check for issues with DNS propagation using a tool such as CacheCheck on the OpenDNS site.

9.    (Optional) Determine whether the geography-based routing records are associated with a Route 53 health check. And, determine whether Evaluate target health (ETH) is turned on for alias records. If either are true, then Route 53 returns the healthy endpoint that best matches the source location.

Check the status of your Route 53 health check in the Route 53 console. If ETH is turned on, then check the health status of the record endpoint. Route 53 considers an endpoint for a Classic Load Balancer with ETH turned on as healthy if at least one backend instance is healthy. For Application Load Balancers and Network Load Balancers, every target group with targets must contain at least one healthy target to be considered healthy. A target group with no registered targets is considered unhealthy. If any target group contains only unhealthy targets, then the load balancer is considered unhealthy.

Example: You have records for Texas in the US, for the US, North America, and all locations (location is Default). And, you have queries that originate from Texas with an unhealthy endpoint. Route 53 checks the US, North America, and then all locations, in that order, until a record with a healthy endpoint is found. If the US record is healthy, then Route 53 returns this endpoint. Otherwise, Route 53 returns a default record. If all applicable records are unhealthy, then Route 53 responds to the DNS query using the value of the record for the smallest geographic Region.

Note: Changes to aliased geolocation resource records might take up to 60 seconds to propagate.

Related information

How can I troubleshoot unhealthy Route 53 health checks?

Why is my alias record pointing to an Application Load Balancer marked as unhealthy when I'm using "Evaluate Target Health"?

Checking DNS responses from Amazon Route 53

AWS OFFICIALUpdated a year ago