The Importance of a DNS Blocker/DNS Encryption Service Cannot Be Understated

Inevitably, as a professional nerd, the questions I get asked the most are some forms of “how can I better protect my privacy online” and “what VPN service do you recommend”. The answers may surprise you. Read on if you’re curious.

By far the most important investment you can make to protect your privacy is a good nuisance blocking app. I view this as important as having antivirus software, if not more. Not only will your internet experience be beautified by having ads and popups removed, pages will load much faster as well. More importantly though, trackers and 3rd party cookies will be blocked from following you around the web.

Equally as important, find a nuisance blocking package that also encrypts your DNS requests. The goal is to hide your activity from your ISP, and while almost every aspect of the web is now encrypted, sadly DNS is not, nor will it be anytime soon due to the way it’s designed, as well as how critical DNS is to the operation of the web. Web pages are encrypted, but the requests your browser makes to load the pages are not.

Your ISP has full access to every single DNS request your device makes, which is a lot more than most people think. My network averages > 100,000 DNS lookups. PER DAY. Even just loading a page like Facebook generates dozens of DNS lookups as different parts of the page are stitched together from various sources. All your ISP has to do is connect the dots, and they’ll know if, say, you’re looking at a lot of car sites. It wouldn’t be difficult for them to surmise you’re shopping for a new car, and thus they’ll sell that knowledge to advertisers who, surprise surprise, will start serving up car ads to your browser/apps.

A good nuisance blocker will block ads, but a good DNS encryption package stops the advertisers from knowing anything about your browsing history in the first place. It’s a pro-active solution. And if you think Incognito mode is protecting your privacy, I have a bridge to sell you. Incognito mode is one of the biggest scams Google ever had us believe.

As for VPNs, they are largely worthless. I personally view most of them as a scam b/c the use cases for actually needing a VPN are extremely narrow and not applicable to the vast majority of people:

• Bypassing geoblocks on streaming services, which isn’t a problem for Americans unless you travel abroad often, and
• If you work a job where someone knowing your IP could bring harm to you, which again is not an issue for the vast majority of Americans

There are times I will route my DNS requests over a VPN connection for extra safety, but that’s not a common occurrence. Just remember, the operator of the VPN will have full access to your DNS history, and it’s for this reason alone I view most VPN services with skepticism. All you’re doing is shifting the trust from your ISP to the VPN operator, and just because they may claim to be “log free” doesn’t mean they actually are. I can count on one hand the number of VPN vendors I trust, with NordVPN being at the top of that list. I run Unifi networking equipment for my homelab, so I do always have an open client tunnel connected to Nord, but it’s an extremely rare occasion that I actually route traffic through the tunnel.

When you take a deeper dive into the use cases that VPN vendors try to sell, almost all of them can be solved with a nuisance blocker, plus you’ll get more benefits from a good nuisance blocker than a VPN connection can claim. The key thing to remember is that the core problem that needs to be solved are one and the same: Hiding your internet traffic from your ISP. Thing is, TSL has 95% of that problem already solved. What you need to hide are your DNS requests, which is where a good DNS blocker comes into play. If you can block problems at the source, e.g. the DNS lookup itself, the problem is virtually solved for blocking ads and other nuisances. The issue then becomes “how do I hide my DNS traffic from my ISP” and unfortunately that problem isn’t the easiest to solve, at least not without some investment into infrastructure.

To encrypt DNS requests, the sender–you–and the receiver–the DNS host–need to understand how to encrypt, and then decrypt the DNS requests in order to create an end-to-end encryptions scheme. It’s not enough just to blast out encrypted DNS requests. Unless your DNS server knows how to handle encrypted DNS requests, you’re out of luck. And if you’re still using your ISP’s DNS servers, the very first thing you should do is change your DNS to different servers. The three services I would recommend are:

• CloudFlare 1.1.1.1
• Google Quad 8
• And my personal favorite, and thus the service I recommend above all others, AdGuard DNS, which will be the focus of the remainder of this post.

There are a couple of different types of nuisance blocking solutions:

• Browser plugins, which only cover your web browsing
• System applications, which act as a proxy for all of the web traffic generated by your device

If you only have a couple of devices, browser plugins are adequate, but what happens when you need to protect an entire network? You then need a more comprehensive solutions, which is precisely why AdGuard is hands down the best solution available. I was a longtime NextDNS user for a couple of years, but grew discouraged by their lack of new features and abysmal user support. That’s when I came across AdGuard, which is a comprehensive DNS blocking solution that covers all use cases needed for network coverage.

AdGuard tackles several use cases with a comprehensive set of software solutions:

• A browser plugin for those needing just a simple nuisance/ad blocker for a couple of devices. The plugin is fantastic, especially with its flexibility to let the user specify parts of web pages that should be blocked. The plugin remembers your selection(s) for all future visits to that site. The problem is, you have to keep each device updated and in sync.
• They also offer a system level application, installable at the OS level, which acts as a sort of local proxy that all device traffic gets funneled through, thus protecting not only browser traffic, but also any web traffic generated by your device’s apps, or the OS itself. It’s pretty wild how much spying apps and OSes are guilty of.
• For power users/homelab folks, they also offer a completely free network proxy solution, called AdGuard Home. It’s also open source/FOSS, with source code available on Github (it’s written in Go, and is updated often). Think, Pi-Hole, but better in every sense. I was a pi-hole user for a few months after I grew discontent with NextDNS, but the quality of the software is quite low, especially when compared to AdGuard Home. It gets the job done, but it does NOT do DNS encryption, at least not by itself.

There are two solutions to the DNS encryption issue. The vast majority of people should choose DNS over HTTPS, mainly b/c it requires no extra ports to be open on your firewall since it uses the industry standard port 443 for TLS/SSL. The solutions are:

• Configure each device to use some sort of encrypted DNS solution, of which there are currently three different methods, each with their own pluses and minuses: a) DNS over HTTPS b) DNS over TCP and c) DNS over Quic. Or…
• Centralize DNS requests so you only have to configure one policy to be applied to every device on your network. In my case, I have two servers (see above) running Red Hat Enterprise Linux that act is DNS proxies that both a) serve as DNS blockers and b) serve as DNS encryption senders.

You can then configure those proxies to point to the encrypted internet DNS servers of your choosing, of which there are many. You can use Cloudflare, Google, Quad 9, etc, but with those solutions you are limited to whatever tooling they offer for customization. However, it should be noted that their baseline servers, e.g. 1.1.1.1 or 8.8.8.8 serve as encryption endpoints as well as nuisance blockers, so they’ll encrypt your DNS traffic in addition to blocking a lot of ads and trackers out of the box. However, you don’t get customization option.

That’s where AdGuard DNS comes into play. For a nominal charge, you get a couple of cloud DNS servers to act as endpoints for your local proxies, either device apps, or the AdGuard Home solution I mentioned above. You also get complete control over the blocklists, and you can write your own rules. And if you need to have your custom rules applied from a central location, you can upload your blocklist to a service like Github, and then add that list as a custom lis in AdGuard. Now you’ll have a single source of truth that you only have to update once, and if you configure AdGuard to use your custom list, any time you need to make changes, it’ll be applied to every device on your network, including mobile devices since you can configure mobile apps to point to your custom DNS AdGuard servers.

My architecture is as follows, from client to cloud DNS server:

• For mobile devices and consumer OSes, you install the AdGuard client app and then point the app to cloud DNS servers, either the generic ones provided by AdGuard, or your custom DNS servers created by you in the AdGuard cloud. You can create simple bypass lists so that local traffic goes through your local DNS servers, e.g. 192.168.0.0/16 as an exclusion so that your local domain traffic still goes through your domain controllers/other DNS solution.
• For all other devices, e.g. servers, IoT devices, etc, you can keep your current DNS solution by installing local AdGuard Home proxies. I prefer Red Hat for professional reasons, but you can install AdGuard Home on any Linux flavor either as a container, or via Snap which vastly simplifies the installation process. After you install the package, configure it as a service, and then point your DNS forwarders to the new AdGuard Home instances.

For most users, just the apps + AdGuard DNS will cover 99% of your needs, but for power users/homelab folks, setting up the DNS proxies locally is crucial to encrypting your DNS requests. If you use AdGuard DNS, you have complete control over your DNS packets from start to end. AdGuard DNS allows you to use any AdBlock compatible list, and they even offer a free AdBlock format generator, also as open source/FOSS in Github. I have a custom rule list I host in Github that I feed to the AdGuard Compiler, and thus I know that if I add a new rule to the list in Github, all of my devices will get the update within a few minutes, either directly, or indirectly through the AdGuard Home proxies.

I did have to write some code to have my AdGuard DNS cloud servers updated as well, but that’s only b/c I have 6 virtual DNS servers in the AdGuard cloud, and this saves me the step up having to update each server manually. Most users will only have one cloud DNS server, so this point is moot. Just know that AdGuard has a well-defined RESTful API that you can tap into, which is precisely what I do to ensure I only have to make edits in one location–in my case, Github–and every client, be it on the LAN or mobile, will get the update within minutes.

Ultimately, the single source of truth is the cloud DNS servers as every DNS packet ultimately gets routed through those instances, either via the device apps directly, or via the local proxies indirectly. And when a device is not on the LAN, the device AdGuard apps take over and automatically send DNS requests through your cloud AdGuard instances directly. No matter what workflow your device has to go through to make a DNS request, it will get funneled through your blocklists, no matter what. On top of that, your DNS requests will also be encrypted, which is just as important as the DNS blocking feature, if not more.

To summarize, there are four different AdGuard options to choose from, depending on what you need. Your goal should be to a) have all DNS packets filtered through your blocklists no matter where they are located, and b) ensure all DNS packets are encrypted. Only then will you be safe from the prying eyes of your ISP, and your internet experience will be vastly improved by eliminating all ads and trackers:

1. For a device or two browsers, just install the AdGuard plugin and point it to the default AdGuard DNS server, or if you prefer, Cloudflare/Google/Quad9/etc.
2. For coverage beyond the browser, consider installing the AdGuard app at the device level so you have complete coverage for the device.
3. For LAN/Domain level coverage, install at least one instance of AdGuard Home and set that as the next hop for your current DNS solution. In my case, I have forwarders configured on my domain controllers to use my AdGuard Home cluster as the next hop. You can still leave the device apps running, just ensure you have routing configured correctly so that LAN requests go through your proxies.
4. For cloud level coverage, invest in AdGuard DNS. You can substitute this step for step 3, however you won’t have DNS encryption then since your DNS forwarders would be to a non-encrypted DNS endpoint, e.g. just a regular dotted quad address forwarder means your DNS packets aren’t encrypted.

Now let’s talk about all the features for power users. If you own your own domain, you can configure AdGuard DNS to use your domain name in place of their naming scheme. You can monitor DNS requests in real time, both at the local proxy level, as well as at the cloud server level. There are also detailed reports about domains that are blocked/allowed as well as why. There are multiple ways to create your own custom rules, but the best option for scalability is to host your custom blocklist in the cloud (Github, or any service that has public endpoints available) and add it to the apps and local AdGuard Home proxies, as well as the cloud instances. You only have to add it once, and then when you update it, you are guaranteed that all clients will be covered by it.

If you don’t mind shelling out a little extra dough, you can also purchase dedicated IP addresses for your cloud DNS endpoints. You’ll get 2 IPv4 and unlimited IPv6 addresses to use as forwarders, or my favorite option, locking the servers down entirely to only accept DNS over HTTPS (DoH) to a specific obfuscated/munged URL. You can also lock traffic down to only be accepted if generated from a specific IP address, in this case, your home IP. Then, even if someone guesses your cloud resolver’s IP, they will be blocked from accessing your cloud DNS endpoints.

If you need to scale up even more, for about $100USD/year, you can get multiple cloud instances for DNS endpoints. This comes in handy for multiple reasons outside of just offering redundancy:

• The AdGuard client apps, in addition to AdGuard Home, allow you to specify multiple DNS servers to query in parallel, or in a round robin fashion to ensure your request is going to the server with the least amount of latency. I personally use the parallel option as this speeds DNS resolving exponentially.
• You can also specify a fallback server, and this is where most DNS leaks occur: Your fallbacks need to be encrypted as well. I have one dedicated cloud DNS resolver instance configured for just this very scenario.
• Or, you can partition your DNS user horizontally by applying tags to their DNS requests, which opens up all kinds of routing scenarios, e.g. forwarding users on the East Coast to server instances located closer to that location.
• I mentioned the RESTful API above, but I cannot stress enough how important this API is if you need to ensure all your servers stay in sync. Unfortunately, you can’t add custom block lists to cloud DNS resolvers via URL, you have to create the list manually and upload it either via the GUI or API.
• If you use the AdGuard Compiler to configure your custom blocklist, you can write some simple code that compiles and uploads the custom lists to all of your cloud instances. The API is very easy to use, and I have a couple of APIs authored that I’ll be putting on Github soon. There’s a parameter on the Servers[] object that accepts a JSON formatted blocklist, so you can still keep your single source of truth in Github, then just use a web request to serialize it out to the parameter.

I have six cloud DNS instances, configured as follows:

• Two cloud servers that do nothing but serve requests from my internet gateway via requests from the onsite AdGuard Home cluster. Each member of the onsite cluster resolves to the opposite pair of resolvers in the cloud, thus equal request volume. I set my onsite resolvers to query in parallel for extra performance.
• A backup/failover resolver for the above.
• Two more cloud servers that service requests from my Unifi gateway. I only have these configured because testing showed that my Unifi gateway was leaking DNS information, and unfortunately there is no way to ensure those packets are encrypted, so I decided to isolate those requests. Ideally, I would configure routing rules to route those requests over my NordVPN connection, but doing so breaks AdGuard DNS functionality. So for now, I just live with the leaks. The good news is that the only packets originating from my gateway are all network related, and aren’t originated from user devices. (Unifi does support encrypted DNS, but only via DNSCrypt which is cumbersome and doesn’t work with AdGuard)
• One dedicated cloud server for device app requests, meaning, originating from devices that aren’t on the LAN. I have the device apps configured to route requests through my domain controllers when they are on the LAN (and thus, ultimately getting funneled through my local AdGuard Home cluster) and through the cloud DNS servers when they are off LAN, or for on-LAN requests that are outside the 192.168.0.0./16 CIDR. You can configure any subnet rules, similar to split tunnels in VPNs.

This is how my server configuration looks via the AdGuard DNS admin website. As you can see, I have a very busy network. It’s amazing how many DNS requests are made via the course of a normal workday, but I digress. What I have configured is probably overkill, but I try to a) eliminate DNS leaks where I can and when I can’t, b) I try to isolate IPv4 requests otherwise.

As for built-in blocklists that I use, I’m a big fan of Hagezi’s blocklists, so I use those in addition to my own custom allow/block lists. It’s probably worth mentioning that AdGuard also offers their own VPN service, which I have no doubt is completely benign, but they don’t offer Wireguard client, instead only offering the ancient IPSec/IkeV2 protocols. If they offered a Wireguard option, I would ditch NordVPN in a heartbeat.

I hope I’ve been able to convey how much more effective a DNS blocker is than a VPN. Granted, VPN services are now starting to offer their own DNS blocking solutions, they are way late to the game and their offerings are simplistic in nature–not for the power user/homelab enthusiasts. At the internet’s core are DNS requests, and if you don’t take steps to hide your traffic, you are littering the internet with breadcrumbs, literally. At the very least your ISP will know what you’re up to, and they have no issues selling your data to the highest bidder. You can also block ads and trackers at the DNS level, so DNS blockers serve a lot of purposes.

After over two decades of testing various ad blockers/dns blockers/vpn solutions, and with extensive testing, I’ve found that AdGaurd’s suite of products solves every use case I need, aside from not offering Wireguard on their VPN solutions so I can route my unencrypted IPv4 DNS packets through it. AdGuard support is very responsive, their user forums are full of knowledgeable folks, and they are adding new features on a regular basis. For about $20USD/year, you can have a comprehensive software offering that covers almost all of the use cases needed to block nuisances at the DNS level as well as encrypting your DNS packets to hide them from prying ISP eyes. For me, it’s a no-brainer. I cannot stress enough how essential a DNS blocker is for networks of any size.