NextDNS First Impressions
I recently discovered NextDNS, a secure DNS resolver that blocks ads, trackers, malware domains, etc…, via Mozilla’s Trusted Recursive Resolver Program. NextDNS is on a short list of DNS over HTTPS (DoH) providers that meet Mozilla’s policy, privacy, and technical requirements for their program. Mozilla has an briefer announcement about it you may want to read. I’m a big fan of privacy preserving alternatives to the aged DNS system that ISPs tend to monetize and abuse. I was previously using Cloudflare’s 126.96.36.199 service, which to be honest is a pretty great 3rd party DNS service, and dead easy to remember. It certainly speeds up browsing, and a lot of people don’t know this, but it has some built in capabilities to block malware and/or adult content). While 188.8.131.52 keeps their service very streamlined, and simple, NextDNS is almost like having a near zero effort pi-hole in the cloud. Pi-hole is a great solution too if you’re considering DNS security and blocking, and want to try to keep it all under your control, but who has time for that?
Setting up NextDNS is easy. It supports regular old DNS, DNS over TLS/QUIC (DoT), and DNS over HTTPS (DoH). You can use a generic profile, by setting your DNS servers to use their public servers or by configuring a DoT/DoH endpoint. The magic really happens when you create a custom profile on their web site, which you can configure to your liking. If you create an account, you get logging and reporting. After you create an account, a detailed setup guide is provided and you can configure policy to IP linkages, or use their DoT/DoH endpoints that look like xxxxxx.dns.nextdns.io and https://dns.nextdns.io/xxxxxx respectively, where xxxxxx is the unique identifier which applies your configuration profile. This is all to say, it’s very easy to create and manage a custom anti-advertisement, anti-tracking, anti-malware, pro-privacy DNS filtering policy for your devices, wherever they may roam, and on your home network.
NextDNS also has a workable, but not suggested way of using their basic IPv4 DNS servers, and linking your assumed dynamic IP of your home router to the custom filtering profile you made. You’re going to want to setup something like dynamic DNS to keep the linkage fresh, or a script to update the linkage manually in the case your public IP changes. They have instructions on this. IPv6 obviously doesn’t have this problem, so if you have support, that should just work. I’d suggest any other way of setting up NextDNS and only using this as a fallback to catch otherwise unconfigurable IoT devices and DNS leaks from regular old DNS clients. Remember, you’re not getting the encryption of DoT or DoH between your client and the server if you don’t have a client that supports encryption.
So you went throug the setup, and it took like five minutes. Good job, your custom policy is enforced, and let me tell you, NextDNS can do some work. It has a plethora of security, privacy, and parental controls, as well as basic custom domain allow and deny lists. A ton of open source domain blocks lists are leveraged and are easily selectable, as well as some of their secret sauce. I say secret sauce, but they’re very transparent, and the deny lists they made are on their GitHub, along with source code for their clients.
NextDNS performs well out of the box, and DNS replies have been snappy in my experience. As a caveat, the company is Seattle based, and so am I. Overall, my browsing speed has been boosted dramatically. Blocking advertisement and tracking content at the DNS level is way faster than cutting it out in your browser after you’ve already downloaded it à la UBlock Origin, or the Brave browser. The log retention and privacy settings are solid too.
That’s the good, but let’s talk about the bad. Inevitably something is going to stop working because you’re blocking it, and you’re going to have to go look at some logs and decide if you want to add the blocked domain to your allow list or not. The filtering and sorting capabilities of the logs page is lacking, and makes this job difficult. I found a third party browser extension in the NextDNS forums that addresses a lot of the UI deficiencies. I gave the extension’s source code a once over, and nothing jumped out as grossly privacy eroding or insecure so I gave it a shot. I recommend NX Enhanced to make the most of your NextDNS experience, and I hope the NextDNS folks just hire the person that wrote it and let them fix the UI.
I also found the first party clients to be somewhat lacking. The clients are their to support older versions of Windows, Android, and such, that don’t support “Private DNS” natively, and to simplify setup. I think first party support is one of the most compelling reasons to upgrade to Windows 11, although maybe wait on that until the bugs have shaken out. One of my complaints in particular about the clients, is their wasn’t a way to customize the optional client identifier that gets sent up to NextDNS from the client.
If you can specify a DoT or DoH endpoint manually, which I feel their first party clients should be able to do, NextDNS supports identifying a particular client by specifying a device identifier in the request. It looks like mydevice-xxxxxx.dns.nextdns.io, or https://dns.nextdns.io/xxxxxx/mydevice, in which you specify mydevice.
This is super handy when you’re digging through logs, but the first party clients transmitted my phone’s default name, which included make and model, as well as my my computer’s make and model to the cloud. Changing the name of my mobile device didn’t alter the behavior, although it did work for my desktop, but my desktop client still transmitted the computer name. On one level they’re getting my DNS traffic, so I’m putting a lot of trust in them already, but this all seems like unnecessary information leakage to me for a privacy oriented service. My devices should be able to use pseudonyms. Additionally the Windows client did not uninstall cleanly, and it left a VPN TUN interface and driver which had to be removed manually.
This led me to look at third party clients. On Windows, which yes I use for regular office productivity, NextDNS alternatively suggested using YogaDNS. YogaDNS is a very fine client from an advanced configuration and usability standpoint, but it’s made by a Russian company called Initex, which may be a concern to some people. I decided to use something FOSS and what I knew, which is DNSCrypt, particularly dnscrypt-proxy. If you’ve been an OpenBSD head you probably know it. If you’re new, welcome to the pain.
With dnscrypt-proxy, I highly suggest using the GUI and Simple DNSCrypt package if you’re on a Windows desktop to initially configure and manage it. It’s a great tool by itself and it works out of the box. It takes a different approach than the first party NextDNS client and uses a local DNS proxy server which you configure your local DNS resolver to point to, rather than a VPN interface and interception. This is a little concerning from a DNS leakage standpoint, as clients may contain their own DNS resolvers, and completely ignore the system resolver. Google Chrome is notorious for this. However, if you’re super worried about leakage you should probably be running Qubes with Whonix, and blocking outbound DNS queries that don’t use your preferred DNS servers. Additionally, Simple DNSCrypt has built in support for a lot of intriguing secure DNS technologies, and it’s a wonderful starting point to go deeper on this subject.
You can use Simple DNSCrypt as is, and select a generic NextDNS profile among many others that are built in, but you’re not going to be able to specify your own NextDNS profile and a unique device identifier without considerable work. To do that, you’ll want to edit ‘%ProgramFiles%\bitbeans\Simple DNSCrypt x64\dnscrypt-proxy\dnscrypt-proxy.toml’, assuming a 64 bit installation, and add a static configuration setting.
For the setting you’ll need to generate a DNS stamp to specify the server and any configuration specifics for it. It’s like a QR code for dnscrypt-proxy. To generate the DNS stamp, it’s easiest to use this online calculator. You’ll need hash(es) to ensure you’re communicating with the right server, and not subject to a standard TLS MiTM attack, and those hashes may be pulled from the DoH endpoint’s certificate as per the docs.
I’m not going to lie to you, this process is a pain. I feel like they really don’t want people configuring this service. They suggest using a go snippet to compute the hash of a .der file as one way of computing the hash. I built their binary if you’re interested and trust me. The path to look for the cert was changed to the current directory of the binary with the name cert.der hard coded. You can also take it on my authority that as of this writing the hash you need for dns.nextdns.io, assuming I wasn’t under attack, is the following.
Their is one more good reason for using Simple DNSCrypt. Since it does run a DNS proxy, which can listen on more than localhost with a simple config change, you can use this proxy and your local DHCP server to relay regular old DNS from say IoT devices on your LAN through the DoT or DoH server you just set up in order to encrypt your IoT device queries in transit. Neat! Running the command line version on a local server, or router that supports FOSS software is a cleaner solution, but you probably wouldn’t be messing with this if you were already that dedicated to securing your home network setup. I’ll leave this up to you as an exercise.
On the Android side, if you don’t have first party support, or you find it to be leaking for some reason, like I did, a local VPN and interception solution like the official NextDNS client, or RethinkDNS might be of interest to you. I ran across the Rethink app in the NextDNS forums and it’s solid. The app combines Little Snitch like local app based firewalling with a highly configurable privacy oriented DNS client. Oh, and TOR integration too if you want that.
The apps code itself is based off the the outline-go-tun2socks VPN client, which was originally published by Jigsaw, a Google incubator that uses tech to try to address geopolitical issues according to their site. It’s also part of the Mozilla Builders MVP Program, which the developers received a grant for. You can check out the RethinkDNS repository for more information.
RethinkDNS’s serverless DNS server that makes up the backbone of Rethink’s own NextDNS like service looks very cool too, but a little immature. The RethinkDNS server is still in beta and free at the moment. I’m thinking host your own serverless RethinkDNS. At some point I’m going to give the full RethinkDNS solution a try, probably when it’s out of beta, and not just use their client with NextDNS. That will be another post no doubt.
I also found that it was nice to individually configure my browsers with their own named DoH endpoints. Once I had my browsers, my OS level resolvers, and the fall-back NextDNS DNS servers configured in my local network’s DHCP settings, I was able to easily distinguish the difference between browser originated DNS requests, system originated requests, leaked DNS requests, and IoT based requests in the NextDNS log console. This proved very interesting, as no doubt anybody who has ran a pi-hole, or just their own DNS server before has seen.
Their was nothing inherently ugly about NextDNS. Their were some rough edges in the web site and the first party clients need just a little work. It would also be nice to have the profile configuration in an app, and not just a mobile site. Some of the third party software I got real nerdy with in this article was definitely ugly, but I’m not docking NextDNS for third party software.
My final verdict is that the overall experience of NextDNS is pretty awesome, and usable by more than just tech geeks, which is huge in my opinion. Usability is an often forgotten aspect of security. Any security control that is hard to implement, use, maintain, or impacts availability will never be adopted to begin with or it will be disabled or bypassed. In support of this maxim, I vote to update the AIC triad to UAIC, pronounced “you ache”. You can’t tell me it’s not better than CIA!
However, NextDNS did help me find something hideous. My ISP owned, leased router, has some really invasive remote device management capabilities, which is probably a generous word for what appears to be a back door that spies on devices in my internal network, and exfiltrates at least some sensitive data from the router. All of this in the name of troubleshooting, and possibly DMCA enforcement. The investigation is ongoing, but I was tipped off by some curious DNS queries originating from my router, which I had configured with the NextDNS DNS servers. I sussed it out after I had positively identified every other source of DNS queries on my home network via the NextDNS logs and followed up with some OSINT and poking around. This will warrant deeper investigation and a follow-up post. My lulz senses are tingling in anticipation.