126.96.36.199 supoer EDNS Client Subnet?. Thanks.
No it does not, here is the explanation.
To clarify, Cloudflare resolvers DO support EDNS.
What they intentionally don’t support is sending a copy of your network address to third parties.
They do not at the end, it’s useless if it isn’t retransmitted.
I can agree they do not refuse it.
I think the confusion is that the title mentions EDNS support, but the first post asks for ECS support.
188.8.131.52 (and virtually every reasonable DNS server in public Internet) supports EDNS(0) - this is just a draft to extend RFC1035 DNS protocol with support for larger packet sizes than 512B and additional options.
184.108.40.206 doesn’t currently support ECS (EDNS Client Subnet option) draft - that defines how client’s source network should be conveyed between resolver and authoritative DNS servers.
Will EDNS CLIENT SUBNET support at some point?
Like many people in the forum, without this function, our queries will often seek resolution from more distant servers.
In my particular case, I am in the Federal Capital - Buenos Aires - Argentina, I have the Telecentro company as ISP … When I configure the servers of POOL.NTP.ORG (0.pool.ntp.org, 1.pool.ntp.org, 2.pool.ntp.org or 3.pool.ntp.org) as an NTP service, when I consult them, I am answered by very distant servers, having 6 servers here in Argentina … This does not happen if I use Google servers DNS …
I understand that 220.127.116.11 DNS points to privacy / security, and enabling EDNS CLIENT SUBNET would pass part of the IP violating privacy.
But I think CLOUDFLARE would gain much more by enabling this function than it would lose … It would help many people to solve routing problems and win more people using their DNS than today, they can not use it for this problem.
Thank you very much for the effort and work you do every day to improve a service that is FREE and QUALITY. I leave a greeting to all the TEAM CLOUDFLARE and we hope to have soon news on this topic.
Keep it up !!!
Cloudflare has DNS servers in Buenos Aires. If you’re being routed to Cloudflare’s Buenos Aires data center, an updated DNS geolocation service will think that you’re in Buenos Aires without ECS.
The problems are that 18.104.22.168 is a pretty new service, and geolocation databases need to be updated, and that cheap geolocation databases may intentionally choose to pinpoint all of Cloudflare’s IP addresses to their corporate headquarters in the United States.
So it can mostly be solved without resorting to ECS. But “can” and “mostly” aren’t really good enough when you’re having issues with an important service now.
Hi, thanks for your response.
Both Google DNS (22.214.171.124 / 126.96.36.199) and Cloudflare DNS (188.8.131.52 / 184.108.40.206) have servers in Buenos Aires. They are hosted in the CABASE datacenter (Camara Argentina de Internet), which is an IXP in the region.
Because with Google’s DNS it works correctly and not with Cloudflare’s?
I understand that this happens because Google DNS uses EDNS CLIENT SUBNET and those of Cloudflare do not …
Is my guess correct?
I would guess so, yes.
Thanks for your answer … I assumed it …
I was reading on other issues that you have problems with the Cloudfrees dns, not having EDNS CLIENT SUBNET support …
We hope to have news soon.
Well I mean we have it… but at the moment are not sending it intentionally.
Of course, this has been discussed in another issue and it is clear that the servers dns cloudflare has such support, but it is not retransmitting.
Greetings and thanks!!!
Yes it is, i have changed it.
Good afternoon. For reasons that affect my network, because the dns responses of 220.127.116.11 are not exact for not using EDNS CLIENT SUBNET, I must migrate to Google DNS with which everything works perfect.
If at any time they were to enable EDNS CLIENT SUBNET in 18.104.22.168, please do me the favor of notifying me so I try.
Thank you very much!!!
Please do verify, since Google and Akamai’s networks are now working fine with closest server location even without EDNS Client Subnet. It may be that the issues have been solved.
Hi, thanks for your response. Among other things, the NTP service POOL.NTP.ORG is still querying distant servers with 22.214.171.124 … with 126.96.36.199 it takes the local NTP servers well.
You should maybe use a local NTP pool, they exist…