Setting up DoT with Unbound: Dnsmasq or odhcpd for DHCP?

I'm setting up DoT with Unbound on version 23.05.3 on my GL-MT6000 router. The documentation page says to "disable Dnsmasq DNS role or remove it completely optionally replacing its DHCP role with odhcpd". What are the pros and cons between these two options?

Also, when using UCI to set up the latter of these options, the aformentioned documentation page links to this section of this page entitled Replacing dnsmasq with odhcpd and Unbound with a list of commands to enter. After entering the commands under "Remove dnsmasq and use odhcpd for both DHCP and DHCPv6", should I also enter the commands under "Use Unbound for DNS" before entering the commands listed on DoT with Unbound, or should I skip the "Use Unbound for DNS" commands and immediately proceed with the DoT with Unbound commands after entering the "Remove dnsmasq and use odhcpd for both DHCP and DHCPv6" commands?

Welcome to OpenWrt.

Not to derail you, but you might talk a bit about why you're doing this. If it's to get a production privacy config with low maintenance + "set and forget", then you'll get different answers than "because I want to play around with and learn about unbound and DoT". (The former has some easier, maybe-better solutions like the DoH proxy or even stubby for DoT under dnsmasq...)

1 Like

Thank you for your response. Forgive me in advance as I'm not super literate when it comes to networking. I plan to set up DoT using Cloudflare mainly for security and malware-blocking purposes. Though I'm not sure if this is true, I've read that antivirus and security software are better at detecting malicious traffic coming through DoT than they are at DoH, which is why I'm choosing to set up DoT. I've also read that Unbound has better privacy and security since it's a recursive resolver rather than a forward-only resolver like Dnsmasq, which is why I want to set up DoT with Unbound rather than with stubby under Dnsmasq.

Ok, a quick (haha) overview of DNS operation:

Some program, say nslookup, asks "what's forum.openwrt.org?"

1 - A basic recursive DNS query looks like this:

The local resolver, say unbound, breaks up the query into its component parts ".", "org", "openwrt", "forum" and starts the recursion (actually it's iteration and not recursion, but whatever, that's historical).

  • Resolver looks up a root server, I think in OpenWrt it's in /etc/unbound/root.hints.
  • Resolver sends to root server: where is "."?
  • Server responds with IP, say 1.2.3.4
  • Resolver sends to 1.2.3.4: where is "org"?
  • 1.2.3.4 responds with "2.3.4.5"
  • Resolver sends to 2.3.4.5: where is "openwrt"
  • and so on for all components of the name, ultimately getting a list of addresses for the query.

This is all done in clear text, the root servers do not support TLS or any encryption.

2 - Now reconfigure unbound to use a DNS service, let's use dns.google. (8.8.8.8).

  • Resolver already knows server from config, 8.8.8.8
  • Resolver sends 8.8.8.8: where is "forum.openwrt.org."?
  • 8.8.8.8 looks in its cache
    • if found, directly returns IP
    • if not found in cache, then does above recursive algorithm, adds to cache and returns IP

No privacy yet! We're still just talking clear text queries.

3 - Let's add encryption, turn on DoT in unbound config

  • Resolver sends to 8.8.8.8: give me an encryption key
  • 8.8.8.8 responds: use "910823blahblahblah"
  • Resolver encrypts actual DNS query and sends it off as before
  • 8.8.8.8 does same as in 2, but response is also encrypted

Note that we're private now, but are we sure we're really talking google? Not yet, so...

4 - Let's add security, turn on DNSSEC in unbound config

  • Resolver sends to 8.8.8.8: prove to me that you are who you say you are...
  • 8.8.8.8 responds: here are my credentials
  • Resolver verifies creds
  • Resolver then just does same as in 3, above...

Ok now! Let's think about the implications here. :thinking:

Using 1:

  • No encryption = no privacy, everyone can see every transaction.
  • Lots of traffic and hence slow.

Using 2:

  • Still no privacy.
  • Nice and fast, as there's only a single transaction, and more often than not the service provider has what you're looking for its cache (at least for popular sites).

Using 3:

  • Finally, we have privacy! DoT or DoH obscure the queries equally well. DoH makes it harder to detect that a DNS query is going on, too, as it's mixed up with lots of other HTTPS traffic.
  • Slower due to the TLS handshakes, but that's the price you pay for privacy.

Using 3+4 (note these are independent, you can have DNSSEC on without DoT/DoH):

  • Full privacy of 3, hopefully eliminates man-in-the-middle vulnerability.
  • Possibly slower still due to credential transaction

So, there's really nothing special that you get from unbound, that dnsmasq + either stubby (DoT) or https-dns-proxy (DoH). It's sort of a dealer's choice thing, which do you prefer.

If you want to use either of DoT or DoH, then you can't use recursive root servers, so you need to talk to a service. For me, the important choice is which service.

Google is almost guaranteed to spy on you, that seems to be their sole purpose these day.

Cloudflare has those nice malicious site blocking features, but makes no promises about what they do with data they collect from your queries, so again I'm suspicious.

Quad9 https://quad9.net/ is my service of choice (I use their DoT servers), because they are somewhat unique in their claims about privacy and they offer the same sort of malicious site blocking that cloudflare does. The real kicker for me was when they moved the company from the US to Switzerland, because the Swiss privacy laws are stricter and more onerous (!!!), gotta admire that sort of commitment.

4 Likes

Thank you, this is a really helpful breakdown of DNS operation. I'm a bit confused though, because from my understanding, unbound is designed to be mainly a recursive DNS resolver. Why, then, does it have the function of being a forwarding DNS resolver? Doesn't that defeat the stated purpose of unbound? Also, why does the OpenWrt documentation have a whole page dedicated to setting up unbound as a forwarding DoT resolver if the same can be acheived with stubby and dnsmasq? In addition, the page for setting up DoT with stubby and dnsmasq says it relies on those services for "resource efficiency and performance", while the page for setting up DoT with unbound says it relies on it for "performance and fault tolerance". What makes unbound more fault tolerant than stubby and dnsmasq?

Hoo boy, some of your questions are above my pay grade! :joy:

unbound was written to be run on big authoritative servers and provide all the bells and whistles needed by a big provider (so forwarding in some use cases, recursive in others). I would not be surprised if it were the backend for many of the providers we've mentioned above, google, cloudflare, quad9 and so on. It is definitely part of the fabric of the internet at large.

dnsmasq on the other hand, is a lightweight subset of DNS, plus a bunch of DHCP services, which makes it more suitable for use on small embedded devices and local servers that don't need to do things like zone transfers (how addresses get spread around) or other high-level DNS management.

As to why there's a big writeup for unbound? Probably someone felt like using it and graciously documented their findings. Recursive vs forwarding? Again, if you learn something, might as well document it in the wiki for others while you're in the mood.

Robustness/reliability? They all work fine, I've configured and used bind, unbound, dnsmasq, stubby and nsd (maybe others I can't recall) and never had an issue with code quality or performance issues with any of them.

My personal recommendation for actual production use today would be:

  • use default dnsmasq,
  • add https-dns-proxy for DoH,
  • set it up with quad9,
  • configure DNS hijacking and run with it.

(Full disclosure: On my gateway router, I actually use dnsmasq + stubby DoT and have my own version of the hijacking system, but that's due to legacy and I'm too lazy to update/change it, cuz it ain't busted.)

3 Likes

Thank you again for the detailed and thorough responses. I ended up using stubby and dnsmasq to set up DoT with Cloudflare. I've used Quad9 before, but I find that Cloudflare has lower latency in my experience. One final question: what does DNS hijacking do, and are the instructions the same for setting it up with DoT as it is with DoH?

DNS hijacking is the means by which you assure all your local devices use the DNS server you've chosen. And, yes, should be the same regardless of what backend DNS setup you've got, it's mainly just traffic redirection and blocking.

Without DNS hijacking, various things (mostly browsers, TVs and other IoT-ish devices) will try to do their own thing and bypass your specified server, often using a DoH host name or maybe an IP, that's hard-coded into the application.

Hijacking usually consists of four pieces:

  1. A firewall rule redirecting traffic that's going out the WAN interface on port 53 to your local server (in your case the router, but some people set up, say a Pi with PiHole or whatever).

  2. A rule that blocks all traffic going out to port 853 (DoT), forcing users back to straight DNS on port 53 (which gets caught by 1).

  3. A rule that blocks known-DoH-server IP addresses going out on port 443 (the trick is don't block regular HTTPS, only DoH). This requires an "IP set" that gets updated fairly frequently (I do it daily), as the services usually roll through addresses quite often (for fun, do nslookup doh.dns.apple.com, wait a couple minutes, do it again, and you'll see what I mean).

  4. Some dnsmasq (or equivalent) configuration that blocks known-DoH servers by name, which again needs some service tools to update frequently (again, my updates for this are daily). See the adblock tools or banip for ways to do this.

Both 3 and 4 are a bit fragile, something somewhere will get through, but usually it's worth probably six 9s of coverage...

1 Like

This topic was automatically closed 10 days after the last reply. New replies are no longer allowed.