Add a server in Brazil

[bogachev-1001]

Very sad with adguard no server in Brazil, any hope?

[ameshkov]

We might add one in the future, thank you!

[marcelloinfoweb]

🥺 please add an Adguard DNS in Brazil.

[maisondasilva]

+1

[fabioeidi20]

+1 please raise the priority of this FR, the ping times are unacceptable at 200ms!

[fabioeidi20]

There are brazilian companies that would offer free bandwidth on their servers through partnerships, such as:

UEPG Internet Exchange (from the public university called Universidade Estadual de Ponta Grossa): https://ix.uepg.br/

EdgeUno: https://edgeuno.com/

Misaka: https://www.misaka.io/

There are other options too. I recommend checking some brazilian free servers on Ubuntu and Linux Mint's mirrors: https://launchpad.net/ubuntu/+archivemirrors https://linuxmint.com/mirrors.php

I just checked all 3 but couldn’t find an option for DNS-based ad/threat-blocking…? Am I missing something…?

[ameshkov]

We tested Sao Paulo recently for a few days. Not too happy with the results compared to the Miami servers that most of the users are routed to now.

Btw, guys, could you please tell me what connectivity do you have to 94.140.14.14?

Here are two questions:

1. What do you see when you open https://dns.adguard.com/info.txt?
2. What's the ping value?

[fabioeidi20]

94.140.14.14

The URL gives me: dns2-dp-mia-4

Pinging 94.140.14.14 directly:

My ISP is located in Sao Paulo btw

[maisondasilva]

My ISP is Santa Catarina

dns2-dp-lon-2

PS C:\Users\Maison> ping 94.140.14.14

Disparando 94.140.14.14 com 32 bytes de dados:
Resposta de 94.140.14.14: bytes=32 tempo=126ms TTL=55
Resposta de 94.140.14.14: bytes=32 tempo=126ms TTL=55
Resposta de 94.140.14.14: bytes=32 tempo=126ms TTL=55
Resposta de 94.140.14.14: bytes=32 tempo=126ms TTL=55

Thanks

[marcelloinfoweb]

My ISP is in Viçosa, MG

dns2-dp-mia-2

C:\Users\marcelo.caetano> ping 94.140.14.14

Disparando 94.140.14.14 com 32 bytes de dados:
Resposta de 94.140.14.14: bytes=32 tempo=114ms TTL=55
Resposta de 94.140.14.14: bytes=32 tempo=114ms TTL=55
Resposta de 94.140.14.14: bytes=32 tempo=114ms TTL=55
Resposta de 94.140.14.14: bytes=32 tempo=114ms TTL=55

Estatísticas do Ping para 94.140.14.14:
Pacotes: Enviados = 4, Recebidos = 4, Perdidos = 0 (0% de
perda),
Aproximar um número redondo de vezes em milissegundos:
Mínimo = 114ms, Máximo = 114ms, Média = 114ms

[SHJordan]

We tested Sao Paulo recently for a few days. Not too happy with the results compared to the Miami servers that most of the users are routed to now.

Btw, guys, could you please tell me what connectivity do you have to 94.140.14.14?

Here are two questions:

1. What do you see when you open https://dns.adguard.com/info.txt?
2. What's the ping value?

C:\Users\iopdev>ping 94.140.14.14

Disparando 94.140.14.14 com 32 bytes de dados:
Resposta de 94.140.14.14: bytes=32 tempo=93ms TTL=52
Resposta de 94.140.14.14: bytes=32 tempo=92ms TTL=52
Resposta de 94.140.14.14: bytes=32 tempo=92ms TTL=52
Resposta de 94.140.14.14: bytes=32 tempo=92ms TTL=52

Estatísticas do Ping para 94.140.14.14:
    Pacotes: Enviados = 4, Recebidos = 4, Perdidos = 0 (0% de
             perda),
Aproximar um número redondo de vezes em milissegundos:
    Mínimo = 92ms, Máximo = 93ms, Média = 92ms

dns2-dp-mia-7

[SHJordan]

Routing us for miami is NOT the solution i know you can achieve.

[fabioeidi20]

While the AdGuard team considers this FR, an alternative for small business and home users might be to host your own DNS server on premises with AdGuard Home (https://kb.adguard.com/en/home/overview).

It's quite similar to the cloud-hosted AdGuard DNS, with the advantage that you can add your custom block lists (something that the cloud-version doesn't offer yet)

By setting a low-latency DNS like 1.1.1.1 or 8.8.8.8 as upstream resolvers in AdGuard Home, you can basically achieve a similar result as AdGuard DNS (in terms of blocking/filtering/etc), but with a much lower resolution latency overall.

I'm using AdGuard Home in a raspberry pi and it works perfectly. Avg latency to resolve an un-cached DNS is around 40-50ms

[SHJordan]

While the AdGuard team considers this FR, an alternative for small business and home users might be to host your own DNS server on premises with AdGuard Home (https://kb.adguard.com/en/home/overview).

It's quite similar to the cloud-hosted AdGuard DNS, with the advantage that you can add your custom block lists (something that the cloud-version doesn't offer yet)

By setting a low-latency DNS like 1.1.1.1 or 8.8.8.8 as upstream resolvers in AdGuard Home, you can basically achieve a similar result as AdGuard DNS (in terms of blocking/filtering/etc), but with a much lower resolution latency overall.

I'm using AdGuard Home in a raspberry pi and it works perfectly. Avg latency to resolve an un-cached DNS is around 40-50ms

how can It be used in conjuction with AG for Windows ,AGVPN and is it possible to propagate from my computer to the router?

[fabioeidi20]

To use AdGuard Home with Windows, first you would need to turn off DNS Protection in the Windows AdGuard app. I don't have AdGuard VPN, but I'm alsmot sure there's also an option to turn off using AdGuard VPN's DNS settings.

The whole point of using AdGuard Home is that it affords your entire home network with the same DNS-based filtering of ads, trackers, malicious sites, etc that AdGuard cloud version does, but with a much lower latency to resolve DNS to IP's. While the cloud version is giving you latency around 90ms, if you use AdGuard Home with 1.1.1.1 as the upstream DNS you may get avg latency < 40ms

To have your entire home network use AdGuard Home, set it up as I said earlier (e.g. in a raspberry pi, VM, etc), then go to your DHCP server (which is probably your wifi router) and configure it to have the DNS server point to the IP of the raspberry pi (or VM) where AdGuard Home is running. It's quite simple

[SHJordan]

would it be detrimental to only run it on one machine? wouldn't it do a double firewall effect?

[ameshkov]

@fabioeidi20 thanks for mentioning AGH. Here's also an article about setting up AGH on a public server, might be useful: https://adguard.com/en/blog/adguard-home-on-public-server.html

[SHJordan]

i saw that you would still need a domain in order to filter HTTPS queries... or did i get something wrong?

[fabioeidi20]

The functionalities offered by the AdGuard app for Windows and AdGuard home are not identical. AGH does “DNS sinkholing”, but does not perform traffic inspection (it cannot look at network packets going from the internet to your PC or phone and make a decision on whether to block, alter or allow such traffic).

AdGuard for Windows can do both: “DSN sinkholing” plus traffic inspection, i.e. looking at incoming packets and e.g. cleaning parts of a cookie, removing or altering the browser user agent that your PC sends to websites, etc.

So I guess there’s nothing “detrimental” in running AGH at the network level and AG for Windows on your PC (I have that set up in my house), because the PC app has the extra benefit of content filtering. The whole point why I suggested AGH is to solely to mitigate the “latency issue” that this FR is intended to address, because the cloud-hosted AdGuard DNS servers are in Miami and you’ve seen our pings from Brazil to that server (all in the range of 90-200ms, which makes loading web pages “feel slow”). With an on-premises AGH (or the self-hosted option ameskov mentioned) you might lower the latency to <40ms and everything on your network will “feel faster”

The advantage of also having AGH at the network level is that it can also do “DNS sinkholing” for other devices on which you can’t have the AdGuard app, such as Smart TV’s, smart speakers, IoT devices, surveillance cameras, etc… all these can still be targets for exploitation and can also send some of your private data to the internet, so doing DNS sinkholing on them might reduce (but not eliminate) some of those risks

[SHJordan]

The functionalities offered by the AdGuard app for Windows and AdGuard home are not identical. AGH does “DNS sinkholing”, but does not perform traffic inspection (it cannot look at network packets going from the internet to your PC or phone and make a decision on whether to block, alter or allow such traffic).

AdGuard for Windows can do both: “DSN sinkholing” plus traffic inspection, i.e. looking at incoming packets and e.g. cleaning parts of a cookie, removing or altering the browser user agent that your PC sends to websites, etc.

So I guess there’s nothing “detrimental” in running AGH at the network level and AG for Windows on your PC (I have that set up in my house), because the PC app has the extra benefit of content filtering. The whole point why I suggested AGH is to solely to mitigate the “latency issue” that this FR is intended to address, because the cloud-hosted AdGuard DNS servers are in Miami and you’ve seen our pings from Brazil to that server (all in the range of 90-200ms, which makes loading web pages “feel slow”). With an on-premises AGH (or the self-hosted option ameskov mentioned) you might lower the latency to <40ms and everything on your network will “feel faster”

The advantage of also having AGH at the network level is that it can also do “DNS sinkholing” for other devices on which you can’t have the AdGuard app, such as Smart TV’s, smart speakers, IoT devices, surveillance cameras, etc… all these can still be targets for exploitation and can also send some of your private data to the internet, so doing DNS sinkholing on them might reduce (but not eliminate) some of those risks

I see... i am still trying to set DoH or even DoT on it... can you give me a hand? also, should i trust default settings on AGHome? cause it uses Quad9 by default if i'm not mistaken and you said to try cloudflare/google for instance.

[SHJordan]

is there a way to use controld quic on chromium?

[marcelloinfoweb]

It is not so significant, comparing the advantages between the services, Next Dns is better, even with the request limitation

[marcelloinfoweb]

For the IP issue that changes in some ISP, I use Raspberry that periodically accesses an API Address of NextDNS that updates the address on the site, without having to access.

ControlD is free for 30 days, after that is paid.

The boring and inconvenient side is the limit. Sometimes I get a couple of days, but for me it's acceptable.

[ameshkov]

We launched another test in Sao Paulo a few hours ago. Most of the South America users are now routed to it. So far, it seems to be handling high load well. The testing period is 2 weeks. If nothing extraordinary happens during that period, we'll keep Sao Paulo and make a public announcement.

[SHJordan]

We launched another test in Sao Paulo a few hours ago. Most of the South America users are now routed to it. So far, it seems to be handling high load well. The testing period is 2 weeks. If nothing extraordinary happens during that period, we'll keep Sao Paulo and make a public announcement.

That's very great news. Are you considering placing DNS servers on other states as well for a more loaded balance? It would be wise to split between Sao Paulo - SP, Recife - PE, Fortaleza - CE and Salvador - BA. which would net a good mix of balance in the latency as well. Not asking for nodes on each of the 26 estates, just more coverage for north and northeast regions of Brazil as well.

[ameshkov]

We generally tend to have fewer, but more "powerful" locations instead of having as many PoPs as possible. Otherwise, with the number of AdGuard DNS users, organizational and maintainance costs will skyrocket.

[ztheory]

@D13410N3 Sent you an e-mail to your noc@ address.

[D13410N3]

@ztheory thanks, I've received contact list, working on this

[ztheory]

IPv4 prefixes are now showing in the ix.br LG:
https://lg.ix.br/search/?q=94.140.15.0%2F24

[D13410N3]

No answer from all contacts you've sent at this moment. Still waiting...

[ztheory]

@D13410N3 It took 2-3 days for us to hear back from those contacts.

[D13410N3]

@jakecharlie Hello.
And still no feedback from all of them

[ztheory]

@jakecharlie - These things take time. Even the world's largest ISPs typically only have 1 or a few people who handle most peering-related items and have large backlogs. It can take days or weeks to hear back about unexpected route selection and requires patience and persistence.

Part of maintaining a network means maintaining good relationships with your upstream providers and peering partners, and I'm not sure it's in AdGuard's best interest to ask their upstream provider, who as of right now seems to be doing what they're supposed to, as well as unaffiliated networks, to start making everyone work for them because of unexpected behavior of a few unaffiliated networks.

You've done your part by reporting these issues and supplying traceroutes. Now perhaps let AdGuard do their job by reporting these issues and playing the waiting game which is communicating with large-scale networks.

[fabioeidi20]

Just to update the thread, my ISP AS28573 (Claro NXT Telecomunicacoes Ltda) still routes through dns2-dp-mia-5

I believe that's one of the laggards responding to the update requests you guys were discussing earlier...

[D13410N3]

@userjohnmichael There were additional messages later, they were sent several times, but no any response was received.

Looks like it's not so "global" problem because about 80% of AdGuard DNS users from Brazil are routed through Sao Paolo.

Anyway, we're still trying to find solution, sorry for this issue.

[marcelloinfoweb]

Hello, any news about Claro, Vivo/Telefonica and Tim?

For now I'm using ControlD.com 3rd Party AdGuard Filter, because they already implemented your syntax and has a server in Sao Paulo too, but without the latency problem. If Adguard team manage to resolve the latency issue with these three ISPs, please let us know here so we can migrate to you.

Thank you in advance. I wish you all a good week.

I recommend using nextdns

[marcelloinfoweb]

@marcelloinfoweb

I appreciate your suggestion.

The problem with NextDNS is that it still does not support Adguard public dns list syntax, so many domains in the list (https://adguardteam.github.io/AdGuardSDNSFilter/Filters/filter.txt) which are blocked in adguard dns, are still not blocked in NextDNS when activating the Adguard DNS list.

That is, NextDNS does not support adguard dns wildcard rules with multiple *s as well as @@ exceptions.

So it's not a 1:1 conversion, it's just a quick fix, but it misses a lot, so I don't recommend it if you're going to use the adguard dns list inside it.

Since ControlD supports the adguard syntax, it becomes a 1:1 conversion.

Example: If you have the Shopee android app installed, the tracker "log-collector.shopee.com.br" will not be blocked in NextDNS, only in Adguard dns and ControlD, as it needs syntax support to interpret the domain in the list "log-collector.shopee."

Echo show and Fire TV devices from Amazon trackers "device-metrics-us-2.amazon.com" and "device-metrics-us.amazon.com". Same thing. Need to interpret the domain "device-metrics-us*.amazon.com" in the public list of adguard dns.

And several other cases that NextDNS simply lets go and only Adguard DNS and ControlD can read that it is on the list and manage to block it.

Obviously I prefer to use Adguard public DNS itself even to help the project, but with the current latency issue sending Claro, Vivo and Tim traffics to New York and Miami, I'm preferring to use an alternative until the problem is resolved.

I think this has already been fixed.

[SHJordan]

I would like to know an official answer if will they gave up or not on the routing issue tho...

[ameshkov]

We didn't give up, just realized that it may take long time to solve. In any case the location is used by 80% of brazilian users so we decided to keep the servers, hence the announcement.

Meanwhile, no response via the official channels so far.

[D13410N3]

@jakecharlie Our ISP can't fix it by itself.
We can't use transit providers tools to fix it too.

The only way to fix it is contacting and working together with these ISPs - but Claro is totally ignoring us.

40% of Claro traffic comes to NY
55% - Miami
5% - Chicago
Literally 0% - Sao Paolo

Most of these traffic comes throughout transit providers - like Cogent and TATA. But there is no way to use their tools to "restrict" Claro come to NA

[D13410N3]

@stefanogo Thanks for your response. All provided addresses were already used fo communication - no answers were received

[ghost]

Did you receive any feedback from Claro (ipv4/ipv6) and Tim (ipv6) about the route problem? Are either of these two already working with the Adguard team on this? Or are you still not receiving any response from these two? Thanks in advance

I just did the traceroute and it's still the same thing. See below:

CLARO:

~ $ traceroute 94.140.14.14
traceroute to 94.140.14.14 (94.140.14.14), 30 hops max, 60 byte packets
1 192.168.0.1 (192.168.0.1) 20.172 ms 19.545 ms 18.705 ms
2 10.58.192.1 (10.58.192.1) 25.777 ms 24.971 ms 23.948 ms
3 c9110829.virtua.com.br (201.17.8.41) 25.350 ms 24.877 ms 26.274 ms
4 embratel-H0-2-1-0-agg01.rjont0.embratel.net.br (200.214.5.1) 25.675 ms 24.776 ms 23.534 ms
5 200.244.19.115 (200.244.19.115) 179.666 ms * 178.577 ms
6 ebt-B12121-intl02.nyk.embratel.net.br (200.230.252.122) 179.188 ms 135.407 ms 133.677 ms
7 ebt-B101-intl01.nyk.embratel.net.br (200.230.252.197) 133.608 ms 131.091 ms 127.878 ms
8 ae11.cr1-nyc2.ip4.gtt.net (209.120.132.221) 132.017 ms 133.358 ms 134.290 ms
9 ae19.cr9-chi1.ip4.gtt.net (141.136.108.189) 143.162 ms 142.686 ms 157.485 ms
10 ip4.gtt.net (76.74.1.82) 145.672 ms 144.500 ms 145.447 ms
11 vl201.chi-cs1-dist-1.cdn77.com (138.199.0.231) 167.542 ms 151.274 ms 150.628 ms
12 * * *
13 * * *
14 * * *
15 * * *
16 * * *
17 * * *
18 * * *
19 * * *
20 * * *
21 * * *
22 * * *
23 * * *
24 * * *
25 * * *
26 * * *
27 * * *
28 * * *
29 * * *
30 * * *
~ $ traceroute 2a10:50c0::ad1:ff
traceroute to 2a10:50c0::ad1:ff (2a10:50c0::ad1:ff), 30 hops max, 80 byte packets
1 2804:14d:5c95:4594:3a3f:b3ff:feaa:3178 (2804:14d:5c95:4594:3a3f:b3ff:feaa:3178) 19.061 ms 18.359 ms 20.205 ms
2 2804:14d:5c95:4::1 (2804:14d:5c95:4::1) 25.471 ms * *
3 2804:14d:5c00:b6::1 (2804:14d:5c00:b6::1) 23.643 ms 24.534 ms 23.323 ms
4 * * *
5 * * *
6 * * *
7 * * *
8 ae11.cr1-nyc2.ip6.gtt.net (2001:668:0:3:ffff:2:0:f91) 130.221 ms 2001:668:0:3:ffff:2:0:1112 (2001:668:0:3:ffff:2:0:1112) 131.032 ms ae11.cr1-nyc2.ip6.gtt.net (2001:668:0:3:ffff:2:0:f91) 129.682 ms
9 * * 2001:668:0:3:ffff:2:0:1112 (2001:668:0:3:ffff:2:0:1112) 118.213 ms
10 * * dns.adguard.com (2a10:50c0::ad1:ff) 154.076 ms
~ $

TIM BRASIL:

~ $ traceroute 94.140.14.14
traceroute to 94.140.14.14 (94.140.14.14), 30 hops max, 60 byte packets
1 * * *
2 * * *
3 * * *
4 * * *
5 5.178.44.38 (5.178.44.38) 64.208 ms 63.149 ms 62.398 ms
6 ae0.sanpaolo1.spa.seabone.net (195.22.219.153) 69.897 ms ae1.sanpaolo1.spa.seabone.net (195.22.219.155) 46.291 ms ae0.sanpaolo1.spa.seabone.net (195.22.219.153) 45.295 ms
7 datacamp.sanpaolo1.spa.seabone.net (195.22.219.205) 44.596 ms datacamp.sanpaolo1.spa.seabone.net (195.22.219.201) 77.609 ms datacamp.sanpaolo1.spa.seabone.net (195.22.219.205) 37.657 ms
8 vl201.sao-eq4-dist-1.cdn77.com (138.199.0.67) 36.796 ms 68.207 ms vl204.sao-eq4-dist-2.cdn77.com (138.199.0.73) 156.294 ms
9 dns.adguard.com (94.140.14.14) 155.364 ms 154.283 ms 123.967 ms
~ $ traceroute 2a10:50c0::ad1:ff
traceroute to 2a10:50c0::ad1:ff (2a10:50c0::ad1:ff), 30 hops max, 80 byte packets
1 * * *
2 * * *
3 * * *
4 * * *
5 2001:41a8:5220:2::41 (2001:41a8:5220:2::41) 67.993 ms * 65.666 ms
6 * 2001:41a8:5200:2::81 (2001:41a8:5200:2::81) 40.746 ms 54.289 ms
7 datacamp.miami16.mia.seabone.net (2001:41a8:4020:2::1ae) 140.912 ms * 136.577 ms
8 datacamp.miami16.mia.seabone.net (2001:41a8:4020:2::1ae) 145.179 ms vl201.mia-cl2-dist-1.cdn77.com (2a02:6ea0:1:2::241) 148.866 ms datacamp.miami16.mia.seabone.net (2001:41a8:4020:2::13a) 161.402 ms
9 datacamp.miami16.mia.seabone.net (2001:41a8:4020:2::13a) 162.007 ms vl203.mia-cl2-dist-2.cdn77.com (2a02:6ea0:1:2::245) 169.748 ms dns.adguard.com (2a10:50c0::ad1:ff) 157.213 ms
~ $

[D13410N3]

@stefanogo Hello. No any updates at this time - even our upstream in Sao Paolo can not do anything with this

[miixms]

there is a server, I think this can be closed @D13410N3 @ameshkov

[petergithubuser]

Claro is still sending traffic to USA in IPV4/IPV6 and Tim is still sending traffic to USA in IPV6...

Claro
~ $ traceroute 94.140.14.14
traceroute to 94.140.14.14 (94.140.14.14), 30 hops max, 60 byte packets
1 192.168.0.1 (192.168.0.1) 2.295 ms 2.870 ms 2.678 ms
2 10.58.192.1 (10.58.192.1) 12.604 ms 12.536 ms 12.290 ms
3 c9110829.virtua.com.br (201.17.8.41) 14.140 ms 13.945 ms 13.758 ms
4 embratel-H0-2-1-0-agg01.rjont0.embratel.net.br (200.214.5.1) 13.522 ms 13.232 ms 14.170 ms
5 * 200.244.19.115 (200.244.19.115) 136.975 ms *
6 ebt-B12121-intl02.nyk.embratel.net.br (200.230.252.122) 136.391 ms 129.622 ms 137.085 ms
7 ebt-B101-intl01.nyk.embratel.net.br (200.230.252.197) 120.245 ms 135.264 ms 118.376 ms
8 ae11.cr1-nyc2.ip4.gtt.net (209.120.132.221) 137.693 ms 136.776 ms 146.072 ms
9 ae21.cr9-chi1.ip4.gtt.net (141.136.108.245) 143.087 ms 144.378 ms 143.654 ms
10 ip4.gtt.net (76.74.1.82) 135.478 ms 143.447 ms 134.122 ms
11 vl203.chi-cs1-dist-2.cdn77.com (138.199.0.233) 141.340 ms vl201.chi-cs1-dist-1.cdn77.com (138.199.0.231) 142.050 ms 143.640 ms
12 * * *
13 * * *
14 * * *
15 * * *
16 * * *
17 * * *
18 * * *
19 * * *
20 * * *
21 * * *
22 * * *
23 * * *
24 * * *
25 * * *
26 * * *
27 * * *
28 * * *
29 * * *
30 * * *
~ $ traceroute 2a10:50c0::ad1:ff
traceroute to 2a10:50c0::ad1:ff (2a10:50c0::ad1:ff), 30 hops max, 80 byte packets
1 2804:14d:5c95:4594:3a3f:b3ff:feaa:3178 (2804:14d:5c95:4594:3a3f:b3ff:feaa:3178) 6.488 ms 7.351 ms 7.028 ms
2 * * *
3 2804:14d:5c00:b6::1 (2804:14d:5c00:b6::1) 17.136 ms 19.510 ms 19.193 ms
4 * * *
5 * * *
6 * * *
7 * ae11.cr1-nyc2.ip6.gtt.net (2001:668:0:3:ffff:2:0:f91) 113.699 ms *
8 ae11.cr1-nyc2.ip6.gtt.net (2001:668:0:3:ffff:2:0:f91) 116.259 ms 2001:668:0:2:ffff:0:8d88:6cf5 (2001:668:0:2:ffff:0:8d88:6cf5) 139.248 ms ae11.cr1-nyc2.ip6.gtt.net (2001:668:0:3:ffff:2:0:f91) 120.324 ms
9 2001:668:0:3:ffff:2:0:1716 (2001:668:0:3:ffff:2:0:1716) 156.605 ms 146.211 ms 2001:668:0:2:ffff:0:8d88:6cf5 (2001:668:0:2:ffff:0:8d88:6cf5) 145.601 ms
10 2001:668:0:3:ffff:2:0:1716 (2001:668:0:3:ffff:2:0:1716) 143.402 ms * 139.759 ms
11 * dns.adguard.com (2a10:50c0::ad1:ff) 156.905 ms *
~ $

Tim
~ $ traceroute 94.140.14.14
traceroute to 94.140.14.14 (94.140.14.14), 30 hops max, 60 byte packets
1 * * *
2 * * *
3 * * *
4 * * *
5 * * *
6 * * *
7 * * *
8 213.144.160.100 (213.144.160.100) 75.940 ms 79.762 ms 5.178.44.38 (5.178.44.38) 68.721 ms
9 * * *
10 195.22.219.201 (195.22.219.201) 72.171 ms 195.22.219.205 (195.22.219.205) 70.530 ms 64.785 ms
11 vl212.sao-asc4-dist-1.cdn77.com (169.150.194.77) 63.470 ms vl211.sao-asc4-dist-1.cdn77.com (169.150.194.75) 61.353 ms 29.256 ms
12 dns.adguard.com (94.140.14.14) 33.870 ms 43.456 ms 42.440 ms
~ $ traceroute 2a10:50c0::ad1:ff
traceroute to 2a10:50c0::ad1:ff (2a10:50c0::ad1:ff), 30 hops max, 80 byte packets
1 * * *
2 * * *
3 * * *
4 * * *
5 * * *
6 * * 2001:41a8:5220:2::41 (2001:41a8:5220:2::41) 88.567 ms
7 * 2001:41a8:5220:2::41 (2001:41a8:5220:2::41) 89.699 ms 89.341 ms
8 * 2001:41a8:4020:2::13a (2001:41a8:4020:2::13a) 193.633 ms *
9 vl201.mia-cl2-dist-1.cdn77.com (2a02:6ea0:1:2::241) 192.924 ms vl204.mia-cl2-dist-2.cdn77.com (2a02:6ea0:1:2::247) 190.663 ms 2001:41a8:4020:2::1ae (2001:41a8:4020:2::1ae) 190.292 ms
10 dns.adguard.com (2a10:50c0::ad1:ff) 191.834 ms vl202.mia-cl2-dist-1.cdn77.com (2a02:6ea0:1:2::243) 189.564 ms dns.adguard.com (2a10:50c0::ad1:ff) 191.093 ms
~ $

[marcelloinfoweb]

λ tracert 94.140.14.14

Rastreando a rota para dns.adguard.com [94.140.14.14]
com no máximo 30 saltos:

1 1 ms 1 ms 1 ms 192.168.31.1
2 4 ms 7 ms 3 ms 100.64.0.1
3 15 ms 16 ms 16 ms 10.128.32.9
4 16 ms 17 ms 15 ms as60068.saopaulo.sp.ix.br [187.16.210.94]
5 15 ms 15 ms 15 ms vl212.sao-asc4-dist-1.cdn77.com [169.150.194.77]
6 15 ms 15 ms 16 ms dns.adguard.com [94.140.14.14]

Rastreamento concluído.

[SHJordan]

λ tracert 94.140.14.14

Rastreando a rota para dns.adguard.com [94.140.14.14] com no máximo 30 saltos:

1 1 ms 1 ms 1 ms 192.168.31.1 2 4 ms 7 ms 3 ms 100.64.0.1 3 15 ms 16 ms 16 ms 10.128.32.9 4 16 ms 17 ms 15 ms as60068.saopaulo.sp.ix.br [187.16.210.94] 5 15 ms 15 ms 15 ms vl212.sao-asc4-dist-1.cdn77.com [169.150.194.77] 6 15 ms 15 ms 16 ms dns.adguard.com [94.140.14.14]

Rastreamento concluído.

Which ISP? Gonna have to try later if it is fixed for me using BrisaNET.

BTW, this is what i got using the ISP of VIVO at my work:

λ tracert 94.140.14.14

Rastreando a rota para dns.adguard.com [94.140.14.14]
com no máximo 30 saltos:

  1     1 ms    <1 ms    <1 ms  192.168.25.1
  2     2 ms     2 ms     3 ms  gvt-b-sr02.sdr.gvt.net.br [177.42.192.1]
  3     3 ms     1 ms     1 ms  201-1-224-4.dsl.telesp.net.br [201.1.224.4]
  4     4 ms     3 ms     4 ms  152-255-193-13.user.vivozap.com.br [152.255.193.13]
  5     3 ms     3 ms     3 ms  152-255-206-222.user.vivozap.com.br [152.255.206.222]
  6    28 ms    29 ms    30 ms  84.16.9.250
  7    30 ms    28 ms    30 ms  94.142.122.134
  8    36 ms    36 ms    34 ms  5.53.5.93
  9     *        *        *     Esgotado o tempo limite do pedido.
 10    36 ms    45 ms    37 ms  190.98.179.25
 11    34 ms    34 ms     *     vl212.sao-asc4-dist-1.cdn77.com [169.150.194.77]
 12    39 ms    39 ms    46 ms  dns.adguard.com [94.140.14.14]

Rastreamento concluído.

UPDATE

This is what i got from BrisaNET ISP:

tracert 94.140.14.14

Rastreando a rota para dns.adguard.com [94.140.14.14]
com no máximo 30 saltos:

  1    <1 ms    <1 ms    <1 ms  192.168.3.1
  2     5 ms     5 ms     5 ms  100.101.208.1
  3     *        *        *     Esgotado o tempo limite do pedido.
  4     6 ms     5 ms     6 ms  172.16.128.238
  5     8 ms     9 ms     7 ms  172.16.137.145
  6     7 ms     7 ms     6 ms  172.16.132.241
  7    35 ms    34 ms    35 ms  172.16.132.242
  8    32 ms    30 ms    31 ms  172.16.137.146
  9    32 ms    31 ms    31 ms  172.16.132.185
 10    32 ms    32 ms    32 ms  172.16.129.78
 11    32 ms    32 ms    32 ms  172.16.128.17
 12    32 ms    32 ms    32 ms  172.16.137.70
 13    32 ms    31 ms    31 ms  172.16.128.230
 14     *        *        *     Esgotado o tempo limite do pedido.
 15     *        *       35 ms  172.16.136.222
 16    33 ms    32 ms    32 ms  172.16.130.121
 17    32 ms    31 ms    32 ms  172.16.128.181
 18    31 ms    32 ms    29 ms  138.204.238.149
 19    58 ms    58 ms    58 ms  globenet.rio.br.as52320.net [200.16.69.45]
 20    60 ms    60 ms    60 ms  200.16.69.123
 21     *        *        *     Esgotado o tempo limite do pedido.
 22    55 ms    55 ms    55 ms  vl212.sao-asc4-dist-1.cdn77.com [169.150.194.77]
 23    55 ms    54 ms    55 ms  dns.adguard.com [94.140.14.14]

Rastreamento concluído.

[petergithubuser]

Have you already managed to establish any contact with Claro and Tim? Or did they never respond to you? I would like to know if there is any progress/advancement in the route problem with the two of them. Thank you.

@ameshkov @D13410N3

[ameshkov]

Unfortunately, no response.

[mhmtkcn]

i am the president & ceo of edgeuno - drop me an email mehmet at edgeuno dot com and i will help you improve your performance using https://edgeuno.cloud

[kleper]

Hey @ameshkov with edgeuno.cloud you can improve and achieve the performance you need on Brasil. :)

[SHJordan]

i am the president & ceo of edgeuno - drop me an email mehmet at edgeuno dot com and i will help you improve your performance using https://edgeuno.cloud

You meant https://edgeuno.com ? because that's not the one that operate here on Brazil.

[mhmtkcn]

both edgeuno.com and edgeuno.cloud owned and operated by same team

edgeuno.com corporate website
https://edgeuno.cloud cloud portal & marketplace @SHJordan

[ihurin]

Team, any update on this? Customer reports that queries from Brazil are still routed via New York and Miami.

#ZD 995791

[ztheory]

According to AdGuard's IP transit provider, they have PNIs with TIM and Claro in Sao Paulo:
https://www.datapacket.com/datacenters/sao-paulo

In this case, it would typically be appropriate to raise this issue with the IP transit provider, as either the AdGuard prefixes are not being advertised via the PNIs, or Claro/TIM are not accepting them or preferring them for some reason....

Regardless, since a PNI exists between those 2 networks, this should be supported by CDN77/DataPacket (etc), since they have a direct peering relationship with them, and it should not typically be AdGuard's responsibility to establish communication with Claro/TIM directly.

[petergithubuser]

I just tested too. Claro is still connecting to Adguard server from New York City in IPV4 and IPV6 [AS28573 (Claro NXT Telecomunicacoes Ltda)]

~ $ traceroute 94.140.14.14
traceroute to 94.140.14.14 (94.140.14.14), 30 hops max, 60 byte packets
1 192.168.0.1 (192.168.0.1) 28.323 ms 27.540 ms 26.843 ms
2 10.58.192.1 (10.58.192.1) 32.847 ms 32.039 ms 31.050 ms
3 c9110829.virtua.com.br (201.17.8.41) 37.157 ms 35.499 ms 35.152 ms
4 embratel-H0-2-0-1-agg01.rjont0.embratel.net.br (189.23.87.1) 34.740 ms 34.776 ms 34.550 ms
5 200.244.19.115 (200.244.19.115) 197.149 ms 196.446 ms 196.607 ms
6 200.230.252.120 (200.230.252.120) 211.392 ms 149.750 ms 139.134 ms
7 * * *
8 ae13.cr10-chi1.ip4.gtt.net (213.254.230.165) 164.367 ms 141.372 ms 153.309 ms
9 ip4.gtt.net (209.120.139.242) 157.197 ms 148.981 ms 161.067 ms
10 * * *
11 * * *
12 * * *
13 * * *
14 * * *
15 * * *
16 * * *
17 * * *
18 * * *
19 * * *
20 * * *
21 * * *
22 * * *
23 * * *
24 * * *
25 * * *
26 * * *
27 * * *
28 * * *
29 * * *
30 * * *
~ $ traceroute 94.140.15.15
traceroute to 94.140.15.15 (94.140.15.15), 30 hops max, 60 byte packets
1 192.168.0.1 (192.168.0.1) 34.374 ms 33.685 ms 33.162 ms
2 10.58.192.1 (10.58.192.1) 38.618 ms 38.258 ms 37.838 ms
3 c9110829.virtua.com.br (201.17.8.41) 37.419 ms 36.811 ms 36.130 ms
4 embratel-H0-2-1-0-4003-agg01.rjont0.embratel.net.br (200.214.5.1) 35.454 ms 35.075 ms 44.917 ms
5 200.244.19.115 (200.244.19.115) 203.141 ms 202.923 ms 201.759 ms
6 200.230.252.120 (200.230.252.120) 201.834 ms 173.159 ms 171.805 ms
7 ae11.cr1-nyc2.ip4.gtt.net (209.120.132.221) 171.098 ms 167.709 ms 137.050 ms
8 ae13.cr10-chi1.ip4.gtt.net (213.254.230.165) 157.694 ms 142.239 ms 141.789 ms
9 ip4.gtt.net (209.120.139.242) 163.549 ms 149.527 ms 148.728 ms
10 * * *
11 * * *
12 * * *
13 * * *
14 * * *
15 * * *
16 * * *
17 * * *
18 * * *
19 * * *
20 * * *
21 * * *
22 * * *
23 * * *
24 * * *
25 * * *
26 * * *
27 * * *
28 * * *
29 * * *
30 * * *
~ $ traceroute 2a10:50c0::ad1:ff
traceroute to 2a10:50c0::ad1:ff (2a10:50c0::ad1:ff), 30 hops max, 80 byte packets
1 2804:14d:5c95:43e4:10:18ff:fe84:c5ac (2804:14d:5c95:43e4:10:18ff:fe84:c5ac) 26.195 ms 25.154 ms 24.184 ms
2 2804:14d:5c95:4::1 (2804:14d:5c95:4::1) 30.968 ms 36.274 ms 35.370 ms
3 2804:14d:5c00:b6::1 (2804:14d:5c00:b6::1) 34.683 ms 34.175 ms 33.778 ms
4 * * *
5 * * *
6 intl04.nyk.embratel.net.br (2804:a8::200:230:249:211) 183.137 ms * 152.530 ms
7 ae11.cr1-nyc2.ip6.gtt.net (2001:668:0:3:ffff:2:0:f91) 139.618 ms 198.091 ms *
8 2001:668:0:2:ffff:0:8d88:6cbd (2001:668:0:2:ffff:0:8d88:6cbd) 195.590 ms 192.609 ms 190.942 ms
9 2001:668:0:2:ffff:0:8d88:6cbd (2001:668:0:2:ffff:0:8d88:6cbd) 188.352 ms 186.927 ms 140.591 ms
10 2001:668:0:3:ffff:2:0:1716 (2001:668:0:3:ffff:2:0:1716) 139.393 ms * *
11 dns.adguard-dns.com (2a10:50c0::ad1:ff) 145.276 ms 142.304 ms 146.897 ms
~ $ traceroute 2a10:50c0::ad2:ff
traceroute to 2a10:50c0::ad2:ff (2a10:50c0::ad2:ff), 30 hops max, 80 byte packets
1 2804:14d:5c95:43e4:10:18ff:fe84:c5ac (2804:14d:5c95:43e4:10:18ff:fe84:c5ac) 27.555 ms 26.348 ms 25.000 ms
2 2804:14d:5c95:4::1 (2804:14d:5c95:4::1) 33.593 ms 32.007 ms 30.600 ms
3 2804:14d:5c00:b6::1 (2804:14d:5c00:b6::1) 29.516 ms 28.289 ms 26.158 ms
4 * * *
5 * * *
6 intl04.nyk.embratel.net.br (2804:a8::200:230:249:211) 148.340 ms * *
7 * ae11.cr1-nyc2.ip6.gtt.net (2001:668:0:3:ffff:2:0:f91) 158.130 ms 157.175 ms
8 2001:668:0:2:ffff:0:8d88:6cbd (2001:668:0:2:ffff:0:8d88:6cbd) 199.634 ms 141.318 ms 141.267 ms
9 2001:668:0:3:ffff:2:0:1716 (2001:668:0:3:ffff:2:0:1716) 140.567 ms 191.000 ms 167.101 ms
10 * 2001:668:0:3:ffff:2:0:1716 (2001:668:0:3:ffff:2:0:1716) 160.756 ms *
11 dns.adguard-dns.com (2a10:50c0::ad2:ff) 153.603 ms 141.239 ms 151.401 ms
~ $

Tim is still connecting to Adguard server from Miami in IPV6 [AS26615 (TIM S/A)]

~ $ traceroute 94.140.14.14
traceroute to 94.140.14.14 (94.140.14.14), 30 hops max, 60 byte packets
1 * * *
2 * * *
3 * * *
4 * * *
5 * * *
6 * * *
7 * * *
8 213.144.160.100 (213.144.160.100) 80.618 ms * *
9 195.22.219.153 (195.22.219.153) 35.156 ms 195.22.219.155 (195.22.219.155) 32.424 ms 29.983 ms
10 195.22.219.205 (195.22.219.205) 28.437 ms 26.858 ms 195.22.219.201 (195.22.219.201) 23.917 ms
11 vl212.sao-asc4-dist-1.cdn77.com (169.150.194.77) 49.369 ms vl211.sao-asc4-dist-1.cdn77.com (169.150.194.75) 47.946 ms 41.564 ms
12 dns.adguard-dns.com (94.140.14.14) 40.089 ms 39.436 ms 54.597 ms
~ $ traceroute 94.140.15.15
traceroute to 94.140.15.15 (94.140.15.15), 30 hops max, 60 byte packets
1 * * *
2 * * *
3 * * *
4 * * *
5 * * *
6 * * *
7 * * *
8 213.144.160.100 (213.144.160.100) 51.857 ms 5.178.44.38 (5.178.44.38) 44.223 ms 213.144.160.100 (213.144.160.100) 40.544 ms
9 195.22.219.153 (195.22.219.153) 57.040 ms 55.575 ms 195.22.219.155 (195.22.219.155) 52.239 ms
10 195.22.219.205 (195.22.219.205) 41.827 ms 40.784 ms 39.490 ms
11 vl211.sao-asc4-dist-1.cdn77.com (169.150.194.75) 38.586 ms vl212.sao-asc4-dist-1.cdn77.com (169.150.194.77) 37.885 ms vl211.sao-asc4-dist-1.cdn77.com (169.150.194.75) 31.348 ms
12 dns.adguard-dns.com (94.140.15.15) 31.951 ms 44.310 ms 49.248 ms
~ $ traceroute 2a10:50c0::ad1:ff
traceroute to 2a10:50c0::ad1:ff (2a10:50c0::ad1:ff), 30 hops max, 80 byte packets
1 * * *
2 * * *
3 * * *
4 * * *
5 * * *
6 * 2001:41a8:5220:2::41 (2001:41a8:5220:2::41) 69.459 ms *
7 * * *
8 * 2001:41a8:4020:2::13a (2001:41a8:4020:2::13a) 175.846 ms *
9 2001:41a8:4020:2::13a (2001:41a8:4020:2::13a) 174.560 ms vl203.mia-cl2-dist-2.cdn77.com (2a02:6ea0:1:2::245) 180.216 ms 2001:41a8:4020:2::13a (2001:41a8:4020:2::13a) 173.837 ms
10 dns.adguard-dns.com (2a10:50c0::ad1:ff) 179.516 ms vl202.mia-cl2-dist-1.cdn77.com (2a02:6ea0:1:2::243) 173.090 ms dns.adguard-dns.com (2a10:50c0::ad1:ff) 178.807 ms
~ $ traceroute 2a10:50c0::ad2:ff
traceroute to 2a10:50c0::ad2:ff (2a10:50c0::ad2:ff), 30 hops max, 80 byte packets
1 * * *
2 * * *
3 * * *
4 * * *
5 * * *
6 * * *
7 * * *
8 * * 2001:41a8:4020:2::13a (2001:41a8:4020:2::13a) 139.029 ms
9 2001:41a8:4020:2::1ae (2001:41a8:4020:2::1ae) 137.834 ms 136.545 ms vl204.mia-cl2-dist-2.cdn77.com (2a02:6ea0:1:2::247) 140.806 ms
10 vl202.mia-cl2-dist-1.cdn77.com (2a02:6ea0:1:2::243) 139.555 ms dns.adguard-dns.com (2a10:50c0::ad2:ff) 138.107 ms 132.720 ms
~ $