Incorrect geo-located DNS response from 1.1.1.1

[agentx]

I’d like to report an anomaly with 1.1.1.1 when it comes to geo-located responses specifically while using a particular ISP.

I’m based out of Chennai, India (MAA) and ACT Fibernet is my ISP. I’ll provide more detail below, along with a comparison with a different ISP (Airtel) with 1.1.1.1.

Even though I’m located in MAA with CF presence, I’m only connecting to HYD based on debug information (same for 1.0.0.1 also):

Server:  one.one.one.one
Address:  1.1.1.1
Non-authoritative answer:
id.server text ="HYD"

Traceroute result from the affected ISP (ACT Fibernet):

Tracing route to one.one.one.one [1.1.1.1] over a maximum of 30 hops:
1    <1 ms    <1 ms    <1 ms  192.168.1.150
2    31 ms     2 ms     4 ms  broadband.actcorp.in [103.16.203.186]
3     2 ms     2 ms     2 ms  broadband.actcorp.in [103.16.203.97]
4     3 ms     2 ms     3 ms  broadband.actcorp.in [103.16.203.177]
5    15 ms    14 ms    14 ms  broadband.actcorp.in [183.82.14.133]
6    16 ms    15 ms    16 ms  broadband.actcorp.in [183.82.14.158]
7    16 ms    16 ms    16 ms  broadband.actcorp.in [183.82.12.38]
8    14 ms    14 ms    14 ms  one.one.one.one [1.1.1.1]
Trace complete.

Here are a couple examples where 1.1.1.1 redirects me to a location that’s nowhere nearby.

Google services (incl Youtube):

Server:  one.one.one.one
Address:  1.1.1.1
Non-authoritative answer:
Name:    google.com
Addresses:  2404:6800:4009:80a::200e  172.217.3.238

Traceroute result for above:

Tracing route to nuq05s01-in-f14.1e100.net [172.217.3.238] over a maximum of 30 hops:
1    <1 ms    <1 ms    <1 ms  192.168.1.150
2     4 ms     2 ms     2 ms  broadband.actcorp.in [103.16.203.186]
3     2 ms     2 ms     2 ms  broadband.actcorp.in [103.16.203.97]
4     2 ms     2 ms     2 ms  broadband.actcorp.in [103.16.203.89]
5     2 ms     1 ms     1 ms  broadband.actcorp.in [103.16.203.173]
6     *        *        *     Request timed out.
7     4 ms     3 ms     3 ms  74.125.253.16
8     2 ms    10 ms     2 ms  108.170.253.105
9    35 ms    35 ms    35 ms  209.85.249.59
10    99 ms   102 ms    99 ms  216.239.63.96
11   183 ms   186 ms   183 ms  108.170.235.216
12   208 ms   208 ms   208 ms  72.14.239.126
13   222 ms   263 ms   221 ms  72.14.239.159
14   240 ms   240 ms   240 ms  209.85.249.50
15   240 ms   240 ms   240 ms  209.85.250.97
16   238 ms   238 ms   238 ms  108.170.249.161
17   239 ms   239 ms   239 ms  108.170.225.135
18   239 ms   239 ms   239 ms  nuq05s01-in-f14.1e100.net [172.217.3.238]
Trace complete.

As you can see, that’s not near MAA

CDN (example cdn.speedof.me):

Server:  one.one.one.one
Address:  1.1.1.1
Non-authoritative answer:
Name:    s2.gs1.wpc.alphacdn.net
Addresses:  2606:2800:11f:bb5:f27:227f:1bbf:a0e  72.21.81.189
Aliases:  cdn.speedof.me  cdn.wpc.75c3.gammacdn.net

Traceroute result:

Tracing route to 72.21.81.189 over a maximum of 30 hops
1    <1 ms    <1 ms    <1 ms  192.168.1.150
2     2 ms     2 ms     2 ms  broadband.actcorp.in [103.16.203.186]
3     2 ms     2 ms     2 ms  broadband.actcorp.in [103.16.203.97]
4     2 ms     2 ms     2 ms  219.65.111.125.STATIC-Chennai.vsnl.net.in [219.65.111.125]
5     2 ms     2 ms     2 ms  172.31.167.57
6    25 ms    25 ms    25 ms  172.31.29.245
7   207 ms   207 ms   207 ms  ix-ae-1-602.tcore3.njy-newark.as6453.net [66.198.70.9]
8   211 ms   211 ms   211 ms  if-ae-1-3.tcore4.njy-newark.as6453.net [216.6.57.6]
9   210 ms   211 ms   219 ms  if-ae-11-14.tcore2.nto-new-york.as6453.net [63.243.186.5]
10   211 ms   213 ms   211 ms  if-ae-12-2.tcore1.n75-new-york.as6453.net [66.110.96.5]
11   211 ms   211 ms   211 ms  66.110.96.61
12   214 ms   208 ms   208 ms  152.195.68.139
13   210 ms   210 ms   210 ms  72.21.81.189
Trace complete.

Not MAA either, even though they have local presence.

Finally, here are some samples from my Airtel connection and 1.1.1.1 responds correctly (even MAA instead of HYD too!).

Server:  one.one.one.one
Address:  1.1.1.1
Non-authoritative answer:
id.server text ="MAA"

Google services:

Server:  one.one.one.one
Address:  1.1.1.1
Non-authoritative answer:
Name:    google.com
Addresses:  2404:6800:4007:802::200e 172.217.160.142

Traceroute:

Tracing route to maa03s29-in-f14.1e100.net [172.217.160.142] over a maximum of 30 hops:
1    <1 ms    <1 ms    <1 ms  192.168.1.150
2     *        *        *     Request timed out.
3     5 ms     5 ms     5 ms  61.95.240.129
4     5 ms     5 ms     5 ms  182.79.141.174
5     7 ms     7 ms     6 ms  72.14.211.198
6     6 ms     6 ms     6 ms  108.170.253.97
7     6 ms     7 ms    18 ms  216.239.59.231
8     6 ms     6 ms     5 ms  maa03s29-in-f14.1e100.net [172.217.160.142]
Trace complete.

CDN (cdn.speedof.me):

Server:  one.one.one.one
Address:  1.1.1.1
Non-authoritative answer:
Name:    s2.gs1.wpc.alphacdn.net
Addresses:  2606:2800:10c:1d4d:734:abf:1d16:1174  68.232.45.189
Aliases:  cdn.speedof.me  cdn.wpc.75c3.gammacdn.net

Traceroute:

Tracing route to 68.232.45.189 over a maximum of 30 hops
1    <1 ms    <1 ms    <1 ms  192.168.1.150
2     *        *        *     Request timed out.
3     5 ms     5 ms     5 ms  61.95.240.129
4     6 ms     5 ms     6 ms  182.79.208.16
5     6 ms     6 ms     6 ms  182.79.164.113
6     6 ms     5 ms     5 ms  68.232.45.189
Trace complete.

Along with this, here are the subnet info for both ISPs:

ACT Fibernet : 106.51.0.0/22
Airtel : 122.165.113.0/24

I hope this info is helpful enough to resolve this issue!

[Judge]

Ya, unfortunately this is due to ISP peering. 1^4 is an anycast address, just like Cloudflare’s regular IPs, so some ISPs may not have the most optimized routes set up and they may even be routed to a different data center.

[matteo]

The issue here is double. First, as @Judge said, the ISP is pushing the 1.1.1.1 queries to a wrong location. That is something Cloudflare cannot solve.

The second issue with the Google IP is due to the fact that Cloudflare doesn’t send any ECDS Client Subnet, so Google replies with a general (assuming US) response.

This can be worked on with a collaboration between Google and Cloudflare, but isn’t actually a guarantee since it really depends on what agreements have ISP and what is the ideal Google POP for a given Cloudflare DNS POP.

[agentx]

Thanks for the response @matteo

The second issue with the Google IP is due to the fact that Cloudflare doesn’t send any ECDS Client Subnet, so Google replies with a general (assuming US) response.

In that case, why does using a different ISP with same 1.1.1.1 gets an address that is localized to an extent (at least country, instead of US)?

i.e Different ISP (i.e Airtel) with 1.1.1.1 gets an address that is not just within the same country but is also same city, instead of such a drastic generalization. Does the location i.e MAA instead of HYD matter even though both are in the same country?

What about non-Google, like the example site cdn.speedof.me?

The performance of 1.1.1.1 is drastically affected in sites like YouTube when latency/location of the response plays a big role - giving 8.8.8.8 an advantage. We’re talking 2ms vs 200ms

First, as @Judge said, the ISP is pushing the 1.1.1.1 queries to a wrong location. That is something Cloudflare cannot solve.

I can understand - I can complain to my ISP but that hardly works unfortunately.

[matteo]

Because the actual Cloudflare POP is different. HYD vs MAA. All of them have the same issue. If you do use ECDS Subnet to differentiate IPs vs. using an anycast network like Cloudflare. The first can have issues with DNS resolvers that do not use ECDS and resolve to remote locations, the seconds gives this control to ISPs, which you are experiencing with the two ISPs.

[jerome1]

I have the same issue with tls://1.1.1.1 from France on Orange (or any other DNS server that doesn’t use ECS)
I’m near Paris, the DNS datacenter is the one near Paris ( Paris, France - (CDG) ):

1.1.1.1 — the Internet’s Fastest, Privacy-First DNS Resolver

However…

• 1.1.1.1 sends me in Spain (ECS disabled)

$> dig +short @1.1.1.1 secure-cdn3-vod-mlflux-net.akamaized.net
a1869.dscw16.akamai.net.
2.22.22.120
2.22.22.161

$> traceroute 2.22.48.33
traceroute to 2.22.48.33 (2.22.48.33), 64 hops max, 52 byte packets
 1  home (x.x.x.x)  0.629 ms  0.324 ms  0.267 ms
 2  80.10.235.169 (80.10.235.169)  1.481 ms  1.574 ms  1.308 ms
 3  ae107-0.ncidf203.aubervilliers.francetelecom.net (193.249.213.242)  1.709 ms  1.913 ms  1.806 ms
 4  ae41-0.niidf201.aubervilliers.francetelecom.net (193.252.98.161)  10.269 ms  12.137 ms  5.982 ms
 5  81.253.184.182 (81.253.184.182)  2.298 ms  2.255 ms  2.199 ms
 6  hundredgige0-10-0-0.madtr3.madrid.opentransit.net (193.251.240.143)  17.357 ms
    hundredgige0-2-0-3.madtr3.madrid.opentransit.net (193.251.131.136)  17.402 ms
    hundredgige0-7-0-6.madtr3.madrid.opentransit.net (193.251.132.18)  17.516 ms
 7  tiscali-5.gw.opentransit.net (193.251.150.74)  16.803 ms  16.820 ms  17.079 ms
 8  xe-4-0-1.cr2-par7.ip4.gtt.net (89.149.181.142)  32.264 ms  32.022 ms  37.684 ms
 9  as5580-gw.cr0-par2.ip4.gtt.net (46.33.93.10)  32.067 ms  31.437 ms  31.080 ms
10  akamai-20940-gw.par02-1.fr.as5580.net (78.152.32.98)  34.706 ms  33.244 ms  33.428 ms
11  * * *
12  a2-22-48-33.deploy.static.akamaitechnologies.com (2.22.48.33)  53.027 ms  47.093 ms *

• 8.8.8.8 sends me directly to the destination (ECS enabled)

$> dig +short @8.8.8.8 secure-cdn3-vod-mlflux-net.akamaized.net
a1869.dscw16.akamai.net.
173.223.11.142
173.223.11.166

$> traceroute 173.223.11.175
traceroute to 173.223.11.175 (173.223.11.175), 64 hops max, 52 byte packets
 1  home (x.x.x.x)  0.624 ms  0.248 ms  0.169 ms
 2  80.10.235.169 (80.10.235.169)  1.507 ms  1.446 ms  0.963 ms
 3  ae107-0.ncidf203.aubervilliers.francetelecom.net (193.249.213.242)  3.913 ms  3.487 ms  2.505 ms
 4  ae41-0.niidf201.aubervilliers.francetelecom.net (193.252.98.161)  2.195 ms  2.109 ms  2.200 ms
 5  81.253.184.182 (81.253.184.182)  3.034 ms  2.865 ms  2.679 ms
 6  akamai-4.gw.opentransit.net (193.251.150.114)  6.749 ms
    akamai-5.gw.opentransit.net (193.251.150.150)  8.536 ms
    akamai-4.gw.opentransit.net (193.251.150.114)  10.071 ms
 7  a173-223-11-175.deploy.static.akamaitechnologies.com (173.223.11.175)  2.136 ms  2.006 ms  1.999 ms

Actually, when I use a DNS server with ECS disabled (1.1.1.1 for example) I can’t reliably access Netflix or even LinkedIn for example. Either it fails, or the connection drops every 5 seconds for streaming services (Netflix, Molotov, …)

[german.garciadoego]

The problem is that Cloudflare boasts of being the fastest DNS … but it is not according to the performance of geo-location …
All this is because they do not want to enable EDNS (ECS) because it is not safe for them …
That is why Google dns are still better at the level of geo-location performance, since they have enabled this function.

Regards!!!

[matteo]

@german.garciadoego

The problem is that Cloudflare boasts of being the fastest DNS

They say they are the quickest to reply, the actual response location isn’t really up to them.

@german.garciadoego

All this is because they do not want to enable EDNS (ECS) because it is not safe for them …

It’s not that it’s safe, it’s that they correctly say that it’s not privacy centric. It will expose your location to the remote DNS server. If you need that function simply use 8.8.8.8 or 9.9.9.9.

[german.garciadoego]

What I always wonder is how much longer they will take to decide if they will give or not ECS support … They have been mentioning in different posts that they will take it into account and never gave a specific answer … It would be nice if someone from Cloudflare would light up this query that many other people did too … Either to say they will never support ECS or if they will …

[matteo]

They won’t, that is a certain fact. They may create a new DNS IP that supports it, but I really doubt it.

[Judge]

@german.garciadoego

Cloudflare boasts of being the fastest DNS … but it is not according to the performance of geo-location …

According to dnsperf, it’s both the fastest authoritative and public resolver https://www.dnsperf.com/. Even if it is slower for some DNS servers that use EDNS, it’s a fair trade-off to not give up user privacy.

[sourav.satpathy]

Please check my below response from another thread -

@sourav.satpathy

Please be aware that ACT is not hijacking at all. Cloudflare’s 1.1.1.1 endpoints are everywhere, not just in Singapore. In this particular case with ACT’s internal routing, it’s reaching 1.1.1.1 located in Cloudflare’s Hyderabad node which is there in ACT’s own network.

You can verify if that’s the case by looking at the link below:

https://1.1.1.1/cdn-cgi/trace

You should see Cloudflare’s response with appropriate ‘colo’ tag along with the datacenter location that’s responsible for this. In my and your case, it would be colo=HYD just like yours, because ACT is routing most of Cloudflare to their Hyderabad location.