[Feature request] Geolocation/Client Subnet support for Cloudfront domains

#1

I’ve noticed that since launch Cloudflare will often return records for distant Cloudfront edges, even when querying a local 1.1.1.1 edge.

This is a painful interaction for a CDN product that is supposed to reduce global latency.

I believe that it is a Cloudflare issue because other recursive resolvers, and the identity.cloudfront.net resolver do not seem to ever suffer from this degradation:

2018/08/27 21:43:52 [resolver=1.1.1.1:53,msgId=61668,host=13.33.28.138,rtt=220.251322ms]
2018/08/27 21:43:53 [resolver=8.8.8.8:53,msgId=8640,host=54.230.245.245,rtt=55.775511ms]
2018/08/27 21:43:53 [resolver=identity.cloudfront.net:53,msgId=33957,host=54.230.245.213,rtt=47.597676ms]

(RTT measured by TCP open to one of the A RRs, this example was from “MEL” Cloudflare resolver).

I’m currently running a longer-term test to figure out how often this happens, but it’s often enough to be annoying. It seems to affect all Cloudfront domains (e.g. all of the Atlassian sites).

Cloudfront uses DNS rather than Anycast to select the closest edge. It’s not clear to me exactly how this is interacting with Cloudflare, but they definitely support EDNS and this shouldn’t be happening.

#2

The issue there may be that Cloudflare’s 1.1.1.1 doesn’t support EDNS. With some vendors they have worked to provide a better experience, maybe Cloudfront is not there or is coming.

#3

Oh, yikes. I swear I had read that Cloudflare was sending an anonymized client subnet. Must have been another resolver.

Very convenient then that if there is no EDNS, that most of the time it actually does resolve to a local edge.

#4

I would assume that they use the edge’s IP to locate themselves to the EDNS DNS instead of yours for those with whom they worked.

#5

Yes, that’s what I thought was happening initially! But going by the literal interpretation of the page you linked, no Client Subnet data is sent at all.

#6

I think they are not sending any EDNS IP. Because all Cloudflare’s IPs are geolocated to the US, but they have probably given a list of IP <-> PoP relations to Akamai, Google and the likes. That is not something that is public, but I would assume neither Google nor Akamai would launch a DDoS towards Cloudflare so they feel safe doing that.

#7

Looks like you’re spot on.

From the 8.8.8.8 resolver (74.125.41.9 locally) I can see that an OPT record with EDNS Client Subnet is sent.

From 1.1.1.1 (162.158.1.47 locally) an OPT record is sent but without any extensions.

I guess this is really a feature request, then.

This also seems to affect CNAME flattening in authoritative DNS product as well, which is a bummer. Changing to another DNS host might be on the horizon for me, can’t afford the $200/mo/domain it would take to use be able to use Cloudflare’s CDN in Australia :frowning: .

#8

What kind of back end are you running?

#9

I’ll try to reach out. Even without ECS, they should be able to geolocate you approximately using the Cloudflare’s PoP location. If they absolutely do need ECS, we’ll try to work something out.