Why and how you should run your own DNS resolver :: immibis

5 min read Original article ↗

Date: 2026-09-10 13:18
Tags: dns, unbound, networking

Recently I noticed I was still using Google's DNS server, 8.8.8.8. This is bad because it means Google knows when I visit any website.

Of course I could change it to Cloudflare 1.1.1.1 or Quad9 9.9.9.9, or my ISP, but that just shifts the problem elsewhere. Instead I decided to run my own.

I had a little previous experience with Unbound from running a combined DN42/Internet wifi network. I knew it worked well and was easy to set up, so I decided to use it again, but I was still surprised by how easy it was. I installed the package and opened /etc/unbound/unbound.conf in a text editor as root, but I had to change very little. I only changed the interface and ip-freebind, and access-control options to match my needs (such as serving DNS for VMs) and later I added a forward-zone section to allow me to resolve hosts on a certain private VPN that I often connect to. Everything else I left alone. Since my specific settings are sensitive information, I won't show any of them here, but this is basically all I had to change, and the average user will need less, probably nothing at all:

server:
    interface: 192.168.123.45
    interface: wlan0
    interface: vmnet0
    interface: 127.0.0.1
    
    # allows binding to an IP address even if the interface isn't up yet
    ip-freebind: true
    
    access-control: 127.0.0.0/8 allow
    access-control: 192.168.0.0/16 allow
    
forward-zone:
    name: "vpn.example"
    forward-addr: 10.0.0.53
    forward-tls-upstream: no

The only other thing I had to be aware of was to run unbound-anchor before starting Unbound. This somehow makes sure the root keys are up to date. I put it in the startup script before Unbound itself. Then I enabled Unbound to run on startup and made sure it was running. This is distro-specific and I use a weird distro, so my commands wouldn't be useful to you.

Lastly, I had to configure my machine to use actually use itself as its DNS server. If you're using NetworkManager you can set this through the GUI, but I'm not, but I'm using resolvconf, so I wrote

nameserver=127.0.0.1

in /etc/resolvconf.conf and then reconnected the network so it would update. And that's it! Now my computer is its own DNS resolver.

Results

So, now that I've been using this configuration for a few days, how is it going?

First, Google can't just see all my browsing automatically, which should be non-negotiable.

Second, I noticed that most Internet applications were a little bit faster and more responsive. Every time a program calls getaddrinfo it sends a DNS request to your configured server, and waits for the response. Even if that only takes 20 milliseconds, it still makes the program wait for 20 milliseconds. When the server is 127.0.0.1, and the answer is in the cache - which is most of the time - it comes back in microseconds instead. In principle the first request takes longer, since all the sub-requests have to make several round trips to my computer in a house somewhere and not to my ISP's computer in a well-connected data center, but I haven't noticed that, and I have noticed all the subsequent requests being faster. Could be a placebo, I don't know.

Speaking of caching, the answer is almost always cached. It turns out that programs make a lot of duplicate DNS requests. For instance every time you or a script uses curl, chances are good it's looking up exactly the same DNS address as the last curl command. Browsers do some caching of their own, so loading a web page doesn't keep requesting the same name, but almost nothing else does. Anything like IRC, FTP, Matrix, is going to keep looking up names. And even browsers don't cache for long, so they make a lot of requests too.

In theory it's also more reliable, though I haven't felt the difference. My connection has a fraction of a percent packet loss, and if a DNS request got lost, it would have to time out and retry, which takes about one second. Fewer DNS requests going over my connection means this should happen less often.

It's more customizable. I used to use IP addresses to address the hosts on that VPN I mentioned earlier, but it was easy to tell Unbound that DNS names ending in a certain pattern should be requested from the VPN's own DNS server.

There is a theoretical privacy loss from running your own resolver, because the DNS requests it makes are not encrypted. If you use someone else's DNS-over-HTTPS resolver, like Cloudflare's, the request is encrypted between you and Cloudflare, and only unencrypted after Cloudflare - it's like using a VPN. But I don't trust Cloudflare more than everyone else on the Internet who could intercept my packets, so I don't see why that would be an improvement. Being your own resolver also directly connects you with authoritative name servers, who can now see your IP address - but likewise, I don't trust them less than I'd trust Cloudflare or Google. Most of them are either owned by Big Tech companies, who get that data either way, or by the website you're accessing, who can already see your IP address anyway.

In conclusion, if you're thinking you want a bit more separation from Big Tech, you should definitely run your own DNS resolver.