How do I troubleshoot issues with IP-based routing in Route 53?

Resolution

Example scenario

You have IP-based routing records for clients with the CIDR 172.32.0.0/16 and 172.33.0.0/16 pointing towards two Elastic Load Balancing (ELB) load balancers. One ELB load balancer is located in Virginia (us-east-1) and the other is in Ireland (eu-west-1). Clients with CIDR 172.32.0.0/16 resolve the domain to the load balancer in us-east-1. Clients with CIDR 172.33.0.0/16 resolve the domain to the load balancer in eu-west-1. However, clients aren't receiving the expected output.

Note: IP-based routing isn't supported for private hosted zones.

To troubleshoot IP-based routing, complete the following steps:

1.    Confirm that you correctly configured the IP-based resource records for your Route 53 hosted zone for your use case. Open the Route 53 console, and check the default location that's specified in your Route 53 hosted zone configuration.

Note: 

• If CIDR blocks aren't specified in the CIDR collection that matches the source IP address, then Route 53 answers with the default "*" location.
• Route 53 answers with NODATA if the following are true:
  A default “*” location isn't specified.
  The query originates from a CIDR block that doesn't match any specified CIDR blocks in the CIDR collection.
• Route 53 matches DNS queries that have a CIDR that's longer than your specified CIDR to the shorter specified CIDR in the CIDR collection. For example, if you specify 2001:db8::/32 as the CIDR in your CIDR collection and receive a query from 2001:0db8:1234::/48, then the CIDR matches. If, you specify 2001:db8:1234::/48 in your CIDR collection and receive a query from 2001:db8::/32, then it doesn't match. Route 53 answers with the record for the “*” location.

For CIDR collection and CIDR block limit quotas, see Quotas on records.

2.    Check if the client resolves correctly.

If the client is resolving within the virtual private cloud (VPC) and using VPC DNS .2 resolver, then IP-based routing doesn't work. This is because the .2 resolver doesn't support EDNS Client Subnet (ECS).

If the client is resolving outside of the VPC, then run the following command to verify that your DNS resolver supports EDNS0:

Linux or macOS

dig TXT o-o.myaddr.google.com -4

Windows

nslookup -type=txt o-o.myaddr.google.com

The following example output shows DNS resolvers that don't support EDNS0:

$ dig TXT o-o.myaddr.google.com -4

; <<>> DiG 9.11.4-P2-RedHat-9.11.4-26.P2.amzn2.5.2 <<>> TXT o-o.myaddr.google.com -4
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 38328
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
;; QUESTION SECTION:
;o-o.myaddr.google.com. IN TXT

;; ANSWER SECTION:
o-o.myaddr.google.com. 60 IN TXT "3.209.83.70"

The following example output shows DNS resolvers that do support EDNS0:

$ dig TXT o-o.myaddr.google.com -4 @8.8.8.8

; <<>> DiG 9.11.4-P2-RedHat-9.11.4-26.P2.amzn2.5.2 <<>> TXT o-o.myaddr.google.com -4 @8.8.8.8
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 30624
;; flags: qr rd ra; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 512
;; QUESTION SECTION:
;o-o.myaddr.google.com. IN TXT

;; ANSWER SECTION:
o-o.myaddr.google.com. 60 IN TXT "172.253.8.137"
o-o.myaddr.google.com. 60 IN TXT "edns0-client-subnet 54.82.0.0/24"

3.    To check DNS resolution, use your hosted zone's authoritative name server to resolve the record. Run the following command. In the following example command, replace example.com with your domain.

dig A example.com +subnet=172.3.0.0/16 @ns-1875.awsdns-42.co.uk

Or, use dig or nslookup to verify that the DNS resolution works as expected. In the following example commands, replace example.com with your domain.

dig example.com @8.8.8.8
nslookup example.com 8.8.8.8

4.    If you configure health check records for IP-based resource records, then use these records to verify the health status. If a health check fails for a record with a default (*) location, then Route 53 returns the default location as a DNS query response.

Related information

IP-based routing