It's important to remember, at least for corporate environments, that EDNS Client Subnet is important when working with services such as Exchange Online where the local resolver is what determines your EXO Front Door. If you're using a service like 1.1.1.1, you may be routed to an incorrect Front Door causing increased latency (primarily with search and archive mailboxes which aren't cached).
Quad9 does have a service which provides EDNS Client Subnet support, should you want to leverage it.
Cloudflare DNS does not route efficiently with AWS CloudFront anycast DNS. I tracked down insanely slow `rustup update` downloads to incorrect selection of ideal routes to the AWS resources caused by using CF to resolve the DNS. Switching to a different resolver that works with anycast and EDNS fixed it.
CF saying “we break standard DNS geo routing but work with providers to route things right” isn’t very inspiring.
> Cloudflare DNS does not route efficiently with AWS CloudFront anycast DNS. I tracked down insanely slow `rustup update` downloads to incorrect selection of ideal routes to the AWS resources caused by using CF to resolve the DNS.
Please send me details (silverlock at cloudflare) here - AWS has our geofeed.
If you can include resolution details - e.g. dig @1.1.1.1 <cloudfront-host> +nsid - with the incorrect CF results, we can provide them to AWS.
Folks did geo-routing with DNS long before ECS was included, and there’s a privacy trade-off to be had. We’re exploring ways to make this better but there is no free lunch.
Thanks for providing your info. I stopped using CF for resolution because of this almost two years ago; I don’t have a reason to think the situation changed but if I get a chance I can try to reproduce it and get back to you.
Quad9 does have a service which provides EDNS Client Subnet support, should you want to leverage it.