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:
(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).
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.
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.
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.
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 .
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.
The difference is ~ 200ms of latency, which really shows in desktop applications (like outlook).
Its worth nothing this appears to be random. At times I do get AUS results, while other times i get USA/Canada. I get that ECS isn’t exposed for privacy reasons, but perhaps a “bypass” capability in Cloudflared (which is what im using for DNS over HTTPS) may be ideal until geo-location data can be updated accordingly?
I know it is incredibly frustrating to see ~200ms latency. We are working on a plan to remediate this. We will share an update with the community very soon on how we are going to solve this.
Almost a year has passed and the problems are still there … more than 6 months ago they indicated that it was under consideration to enable EDNS … We continue in the sweet wait using GOOGLE DNS, with which if things work correctly …
Are you going to take a lot more time to consider it ???
I said “ALMOST” a year … and it was not a month … If you verify the link that I put, you will see that these problems come from the beginning of the year, when cscharff had already commented that they were “considering” …
With respect to Google, they had mentioned that it was solved … however, most of the time certain connections, in my case, are directed to Peru … rarely within Argentina (EZE).
So I do not see that it is very solved that we say …
I don’t think this will ever be in the roadmap. Of course I am not on the team, but the premise of 1.1.1.1 is privacy and EDNS Client Subnet is the opposite of that. If that’s what you need fine, otherwise there are fine alternatives depending on your location.
.