Stuck with traffic routed to the wrong CloudFront edge location? We can help you.

CloudFront routes traffic based on the distribution’s price class, associated geolocation databases, and EDNS0-Client-Subnet support.

At Bobcares we assist our customers with several AWS queries as part of our AWS Support Services for AWS users, and online service providers.

Today, let us see how our Support Techs resolve this CloudFront issue.

How to fix traffic routed to the wrong CloudFront edge location?

Depending on the combination of distribution’s price class, associated geolocation databases, and EDNS0-Client-Subnet support, 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.

In order to resolve the error, check the below three factors:

• Firstly, the price class supports the edge location that you expect.
• Next, the DNS resolver supports Anycast routing.
• Finally, the DNS resolver supports EDNS0-Client-Subnet.

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:

Please remeber 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, which 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:

Remember 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

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.

To avoid incorrect routing when the DNS resolver does support EDNS0-Client-Subnet, confirm that a public geolocation database associate with the client-subnet range that’s sending the query to the DNS resolver.

If the DNS resolver is forwarding the truncate 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 correctly map 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 return from 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 route to the Manchester edge location.

[Need assistance with CloudFront? We are available 24*7]

Conclusion

Today, we saw how our Support Techs resolved Traffic routed to the wrong CloudFront edge location.