Recursive dns or DoH / DoT?

Trying to decipher if one is better for privacy then the other. It also seems like people are pretty mixed as to whether DoH or DoT actually provide much of a benefit at all.

I know you can technically run something like unbound with dnscrypt but doesnt that defeat the point of having a recursive dns?

maybe I am misunderstanding but if you are running a recursive server, wouldn’t you not want to use DoH or DoT?

Not trying to argue, I am just new to this so I want to clarify my understanding.

I had thought that with a recursive server, the big benefit was you are then directly contacting the responsive servers. If you use DoH / DoT you are then adding a middle man to the process taking away the big benefit of having a recursive server, no?

Then just to get back to the other part of my post…

My understanding was that since Cloudflare or whomever your provider would be using DoH / DoT still has to send information to the responsive servers in plaintext, the privacy gains from it are minimal.

I think i am starting to understand why its both now. Please correct me if I am wrong. I appreciate you taking the time to do some hand holding lol

DoH / DoT provide privacy from your ISP

and the recursive server can provide privacy from your DNS as the pihole unbound document puts it

no server can fully log the exact paths you’re going, as e.g. the Google DNS servers will only be asked if you want to visit a Google website, but not if you visit the website of your favorite newspaper, etc.

My follow up questions would be

is a setup using both such as unbound and dnscrypt (using this as an example as I see it a lot) provide both benefits?

My understanding is that You can either encrypt DNS or run a recursive resolver. The DNS root servers don’t do encryption.

Which leads me to my 2nd question…

Am I supposed to understand this as its an option to send responsive servers encrypted info or that, in theory, information sent to a responsive server could be done in other ways?

DoH or DoT provide privacy in transit. That means they are useful for providing some privacy from men in the middle this includes but is not limited to just your ISP. It would apply to any entity sitting between the DNS client and DNS server (or Server to Server in some contexts), apart from your ISP that could include an untrusted wifi network, or anyone else between the client device and the upstream resolver. If you understand HTTPS in the context of HTTP web traffic, you can think of DoH/DoT as providing somewhat similar protection and having somewhat similar limitations for DNS traffic as HTTPS does for HTTP traffic.

2 Likes

Thanks for that, this made things a bit more understandable.

Im still a bit confused as to whether one could run a recursive DNS server and still take advantage of DoH/DoT as I am a bit unclear as to whether DNS root servers accept encryption. If you can’t take advantage of both of then I am back to square one - which method is better for privacy?

With the caveat that I am not 100% clear on what your goal is here, I think you are overcomplicating things in your head unnecessarily by focusing on a self hosted (recursive) DNS server.

DoH/DoT provides protection (encryption in transit) for DNS between A ↔ B regardless of what A and B actually are, so long as both A and B support the protocol and are setup for it. It is just encryption in transit.

My understanding was that since Cloudflare or whomever your provider would be using DoH / DoT still has to send information to the responsive servers in plaintext, the privacy gains from it are minimal.

I think this is a misunderstanding. Your query would be encrypted between you and your upstream DNS (Cloudflare in your example) the query between Cloudflare and the authoritative DNS servers either would or would not be encrypted, I don’t know, but I don’t think it really matters, as that is no longer your query, it is just a generic query from Clourflare’s server to some other server. So that part of the journey not being encrypted just means that some MitM could see that Cloudflare asked some other DNS server for the IP for example.tld, but should have no (easy) way of connecting that query to you. Do note that in this situation you would be putting trust in Cloudflare (putting trust in someone is always necessary with DNS as far as I understand).

In my opinion, you are most likely better off using pi-hole (if that’s what you want to use) in a standard configuration with something like Quad9 via DoH as your upstream DNS. It is possible that I just don’t understand the advantage of self-hosting a recursive server, but it seems like the added mental and technical complexity is not worth whatever gain running your own recursive dns may or may not provide.

I think you may be better off taking 2 or 3 steps back, and beginning by defining the specific problems you are trying to solve that led you to consider self hosting a recursive DNS. If you (and we) understand your goals and reasons, it will be easier to think through the pros/cons of different approaches.

  • DoH / DoT between your device or your network and your upstream DNS resolver solves the problem of preventing most MitM from seeing what websites you visit. DoH additionally partially solves the problem of encrypted DNS traffic being recognized as DNS traffic, and potentially being blocked (I think). It does not solve the problem of needing to trust the upstream provider (there is an upcoming solution called ODoH that would partially solve the problem of trust).
  • Can you answer the question of what specifical benefits you would gain, or hope to grain, from self-hosting a recursive DNS server (ignoring DoH/DoT for now)
2 Likes

Yeah - I just can’t tell if there is an added benefit. Atleast from the pihole forums it seems like they reccommend just using cloudflared and skipping doing a recursive server at that point.

more like testing. I setup cloudlfared and ran that for a bit as well, although my implementation was off a bit as it was causing name resolution to take way to long.

lol me in a nutshell right here

yeah, seems to be a choice between trusting your ISP or trusting your upstream service provider.

hahah I think I fall in the same boat, hence the thread. I do like the idea that no server can fully log the exact paths you’re going but for my threat model I doubt it matters much either way. The other benefit, it seems, is there are less parties involved since you would be skipping out on the middle man and sending data directly to the DNS root servers.

My hope was to use a recursive server to provide another layer of privacy through either having my traffic be less traceable by send the data directly to the DNS root servers, while also have the extra benefit of increased speed through caching.

In general the problem I was hoping to solve is that I have a lot of devices on my network, some much less privacy respecting then others and my hope was to try and add another layer of privacy to combat some of that.

I am just not sure how to best accomplish that whether its
-DoH/DoT (either through something like a pihole (assuming this provides a benefit to the whole network, or just by enabling it through a browser).
-Recursive DNS + DoH (such as unbound + DNS Crypt)
-Recursive DNS using DNSSEC

The benefits I thought I could gain is an extra layer of privacy either by making my traffic less traceable through a recursive DNS or encrypting my traffic to hide it from my ISP or both if that could be accomplished.

I appreciate @Cyrus and @xe3 for taking all this time. I realize that my reasoning behind all of this is mercurial at best so it makes it hard to give answer. :smiley:

With that in mind I have setup my pihole with unbound + DNSSEC as the recursive DNS and cloudlfare as the DoT provider.

Based on the cloudlfare documentation it sounds like DoH is slightly better for privacy since requests are hidden in HTTPS traffic but my threat model is at a place where I was comfortable going with the more convenient option, in terms of setup.

For anyone else looking to do this:

unbound guide

after setting up unbound add the following to /etc/unbound/unbound.conf.d/pi-hole.conf

tls-cert-bundle: /etc/ssl/certs/ca-certificates.crt

    forward-zone:
     name: "."
     forward-tls-upstream: yes
     # Cloudflare
     forward-addr: 1.1.1.1@853
     forward-addr: 1.0.0.1@853

You can then check to see if it worked using 1.1.1.1/help