Why is the traffic for my web content getting routed to the wrong CloudFront edge location?

Short description

CloudFront routes traffic based on the distribution's price class, associated geolocation databases, and EDNS0-Client-Subnet support. Depending on the combination of these factors, your website's viewers might be routed to an unexpected edge location. This can increase the overall latency for retrieving an object from a CloudFront edge location.

To troubleshoot routing to an unexpected edge location, check the following:

• The price class supports the edge location that you expect.
• The DNS resolver supports Anycast routing.
• The DNS resolver supports EDNS0-Client-Subnet.

Resolution

The price class supports the edge location that you expect

Check the edge locations that are included in the price class of your CloudFront distribution. You can update the price class of your distribution if you want to include other edge locations.

The DNS resolver supports Anycast routing

If the DNS resolver supports Anycast routing, then there are multiple edge locations that the DNS resolver uses. This means that a requester's edge location is based on optimal latency, which might result in an unexpected location for the resolver's IP address.

To check if the DNS resolver supports Anycast, run one of these commands multiple times:

Note: In these example commands, be sure to replace example.com with the DNS resolver domain name that you're using.

On Linux or macOS, run a dig command, similar to the following:

dig +nocl TXT o-o.myaddr.l.example.com

On Windows, run an nslookup command, similar to the following:

nslookup -type=txt o-o.myaddr.l.example.com

If the output includes the same IP address each time you run the command, then the DNS resolver doesn't support Anycast. If the output includes a different IP address each time you run the command, then the DNS resolver supports Anycast. This might explain an unexpected edge location.

The DNS resolver supports EDNS0-Client-Subnet

To determine how you can avoid incorrect routing, first check if the DNS resolver supports EDNS0-Client-Subnet by running one of these commands:

Note: In these example commands, be sure to replace example.com with the DNS resolver domain name that you're using.

On Linux or macOS, run a dig command, similar to the following:

dig +nocl TXT o-o.myaddr.l.example.com

On Windows, run an nslookup command, similar to the following:

nslookup -type=txt o-o.myaddr.l.example.com

Note: Check the TTL value, and be sure to run the command when the TTL expires. Otherwise, you might get a cached response from the recursive resolver.

If the DNS resolver doesn't support EDNS0-Client-Subnet, then the output is similar to the following:

$ dig +nocl TXT o-o.myaddr.l.example.com  +short
"192.0.2.1"

In the previous example, 192.0.2.1 is the IP address of the closest DNS server that's using Anycast. This DNS resolver doesn't support EDNS0-Client-Subnet. To avoid incorrect routing, you can do one of the following:

• Change to a DNS resolver to a recursive DNS resolve that's located geographically closer to your website's clients.
• Change to a DNS resolver that does support EDNS0-Client-Subnet.

If the DNS resolver supports EDNS0-Client-Subnet, then the output contains a truncated client subnet (/24 or /32) to the CloudFront authoritative name server, similar to the following:

$ dig +nocl TXT o-o.myaddr.l.example.com @8.8.8.8 +short
"192.0.2.1"
"edns0-client-subnet 198.51.100.0/24"

In the previous example, 192.0.2.1 is the closest DNS resolver IP address. Additionally, the client-subnet range is 198.51.100.0/24, which is used to respond to DNS queries. To avoid incorrect routing when the DNS resolver does support EDNS0-Client-Subnet, confirm that a public geolocation database is associated with the client-subnet range that's sending the query to the DNS resolver. If the DNS resolver is forwarding the truncated version of the client IP addresses to CloudFront name servers, then CloudFront checks a database that's based on several public geolocation databases. The IP addresses must be correctly mapped in the geolocation database so that requests are routed correctly.

If the DNS resolver supports EDNS0-Client-Subnet, you can verify the edge location that traffic is routed to by first resolving your CloudFront CNAME by running a DNS lookup command like dig:

$ dig dftex7example.cloudfront.net. +short
13.224.77.109
13.224.77.62
13.224.77.65
13.224.77.75

Then, run a reverse DNS lookup on the IP addresses that are returned by the previous command:

$ dig -x 13.224.77.62 +short
server-13-224-77-62.man50.r.cloudfront.net.

In the previous example, the traffic is routed to the Manchester edge location.

Tip: For an additional test, you can use a public DNS resolver that supports EDNS0-client-subnet, such as 8.8.8.8 or 8.8.4.4. Send queries with edge location IP addresses to the public DNS resolver. Then, check the results of the DNS queries to see whether CloudFront has the correct information about your EDNS0-client-subnet.

---