We fixed the problem with slow connection to Google domains in AdGuard DNS
Over the last one or two weeks we've been receiving a large amount of complaints about the AdGuard DNS's speed. And we couldn't have figured out the culprit — we measure speed in multiple locations all over the world, and according to our measurements it was fine in all of them.
But we finally found the root of the problem. Turns out, it wasn't about AdGuard DNS per se. It was doing its job just like it was designed to. But when it comes to IP addresses that it was returning, it's not all that good. For some domains (mainly Google-owned ones) AdGuard DNS was returning IP addresses belonging to Google China. As expected, these addresses would work rather slowly for most users.
What happened? How did it happen? We will give answers to this questions in a minute, but first we apologize for taking much more time to solve this problem than it could have taken.
How does DNS work?
First of all, we'll need to figure out how DNS works in general. The thing is, DNS is not a centralized system. For each domain there's a DNS server that's responsible for it, a so-called authoritative nameserver. Recursive DNS resolvers (like AdGuard DNS) get responses from such authoritatve nameservers.
And what happens when AdGuard DNS receives your DNS request?
Step №1: Checking the cache. It's likely that we already know what IP address corresponds to your request if that address is stored in AdGuard DNS's internal cache. This is true for the majority of requests, and in such case AdGuard DNS simply returns an IP address right away.
Step №2: resolving DNS. If there's no response stored in the cache, we have to reach for the authoritative nameserver. For the sake of example, let's imagine that you asked AdGuard DNS for an IP address of
First, we need to find out what server is responsiple for the
org domain zone. To do that, we address so-called root DNS servers, There are only 14 of those in the world, and you can see the entire list of them here. Their only task is to know which server is responsible for each 1st level domain zone (
One of such root servers lets us know that there are 6 nameservers resonsible for the
org domain zone. They are called "TLD nameservers" and they know which authoritative nameservers are responsible for each of the domains in the
Then, one of these servers must tell us who is responsible for exactly
example.org. So we learn about two more servers and, finally, we get the answer to the initial question — what is the IP address of
Want to see how this whole system works for yourself? You can easily do that, for example, on this website.
So what was the problem?
There are four authoritative nameservers that are responsible for all of Google domains. They are configured in such way so that any client gets the IP address of the closest Google server. AdGuard DNS has almost 50 servers over the world (and soon will have more), so why Google was returning Chinese servers' addresses to some of them?
You see, AdGuard DNS servers have several IP addresses — IPv6 as well as IPv4. And it seems Google failed to detect the IP address location properly when IPv6 was in use. They were serving records for China instead of the records for AdGuard DNS servers location.
So in the end, this turned out to be not much of a mystery. Be careful if you're using your own recursive DNS server — with IPv6 you can't make predictions.
To avoid this in the future we configured all our DNS servers to prefer IPv4. So you will not encounter slow connection speed when visiting Google domains anymore.
Can this be solved in a different way?
Is it possible to use EDNS Client Subnet but keep your IP in secret? Yes, and we're already working on it. Keep an eye on our Blog, follow us in social media, and you won't miss it when we eventually and inevitably post the update.