1.1.1.1 supports ECS?

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.

1.1.1.1 (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.
1.1.1.1 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.

3 Likes

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 1.1.1.1 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.

Regards!!!

1 Like

It is under consideration.

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 !!!

Regards!!!

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 1.1.1.1 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 (8.8.8.8 / 8.8.4.4) and Cloudflare DNS (1.1.1.1 / 1.0.0.1) 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?

Greetings.

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.

Regards!!!

1 Like

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.

Hopefully soon!

Greetings and thanks!!!

1 Like

Yes it is, i have changed it.

Good afternoon. For reasons that affect my network, because the dns responses of 1.1.1.1 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 1.1.1.1, 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 1.1.1.1 … with 8.8.8.8 it takes the local NTP servers well.
Regards!!!

You should maybe use a local NTP pool, they exist…

Finally I did what you recommended Matteo, I put as time servers those of POOL.NTP.ORG but of Argentina (AR.POOL.NTP.ORG). With this I patch the issue of time servers, but it is not a 100% real solution … It should be done by geolocation automatically using the standard NTP …

In any case, assuming that they are new servers and like everything else, when they are just launched, they have to polish and fine-tune their operation. With the passage of time I calculate that all this will be solved.

Greetings and thanks to all!!!

The problem is that it’s difficult to optimize that without providing the client’s subnet which I believe it’s how the NTP pool works. The pools are located per country specifically to reduce issues with location.

Of course, I understand … that’s why both I and other people think that sending a response to the subnet client would be a very good decision … so that everything works properly.
I understand that some privacy would be lost, which is the main objective of 1.1.1.1 …
Surely they must be working to accept this function … or perhaps seeing if there is any way to do something in between …

Regards!

If it’s confirmed that the geoip database used by the NTP Pool – I believe it’s one of the popular corporate ones, but I’m not certain – has the wrong location for Cloudflare’s Buenos Aires IP addresses, it can be fixed and updated.

ECS isn’t necessary.

Edit: The caveats I wrote above apply, but there’s no reason not to pursue it.