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.

[fabioeidi20]

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.

Excellent news! Will test with my ISP in Sao Paulo

[ameshkov]

@jakecharlie at the moment about 75% of Brazil traffic is routed properly. For others we'll need to adjust routes manually.

[SHJordan]

When i get home i'll test in my ISP as well (Brisanet AS28126) to tell if it working as intended.

[fabioeidi20]

I see you guys referring to these codes AS28126, AS26615, AS26599, AS28573, etc...

how do you find the code for a given ISP?

[SHJordan]

I see you guys referring to these codes AS28126, AS26615, AS26599, AS28573, etc...

how do you find the code for a given ISP?

https://bgp.he.net/ just use the search bar.

[marcelloinfoweb]

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.

Which DNS are you using?

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

Which DNS are you using?

He's referring to AGDNS.

[D13410N3]

@jakecharlie Hello! Thanks for your information - I've contacted listed ISP, waiting for their answer.

Can you please also send traceroute-results from these ISPs to noc@adguard.com?

[SHJordan]

I believe using HTTPS is the way to go right? since QUIC rn is chugging on regular pages with only adguard dns list + oisd full. (delays of 400ms and NX DOMAINS sometimes). Using the Adguard for Windows app with DHCP settings. Should i disable any dns settings from chrome, edge and firefox?

[D13410N3]

@jakecharlie you can send tracetoutes from them too - we'll try to deal with it too

[ameshkov]

They're not very responsive:(

[ztheory]

Greetings from Quad9,

One thing I noticed is that AdGuard's IPv4 prefixes may not be announced at IX.br Sao Paulo by their upstream, AS60068: https://lg.ix.br/search?q=94.140.15.0%2F24

However, their IPv6 prefix is: https://lg.ix.br/search?q=2a10%3A50c0%3A%3A%2F48

AdGuard might want to check BGP announcements/communities and with their upstream provider to make sure all their prefixes are being announced via the route servers, assuming that's desired by AdGuard.

I suspect that if the prefixes are announced via IX.br Sao Paulo, many networks in Brazil will start routing there, including TIM and Claro.

If for some reason AdGuard doesn't want to announce their prefixes at IX.br Sao Paulo, I believe announcing the prefixes to Cogent might get Claro traffic, since that's the transit currently used.

[D13410N3]

@ztheory Thanks for your information! I've contacted out upstream - they say that our prefixes are exported at IXBR correctly

I've checked your link to IX.br looking glass - looks like they use cached information on website (right corner - Routes cache was built 23 days ago)

[ztheory]

@D13410N3 Ahh good catch. I can confirm that our servers in Brazil route your Anycast IPv4 prefixes via your upstream at ix.br as well. Indeed Claro might need to tell you why they're not routing your prefixes via ix.br.

I reported the stale cache issue to ix.br.

It's possible that Claro is preferring the RPKI-verified AS path, though they route to our prefixes in Brazil on a non-RPKI-verified path, but that's via PNI, so not sure if they treat IX vs. PNI traffic differently in that regard.

[D13410N3]

@ztheory Thanks.

Anyway, we still need to get some info from Claro, but unfortunately they don't answer my e-mails. Maybe you have some information about contacts of their noc team?

[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