Pihole with DoT, DoH, or DNSCrypt

I have pihole running in a docker container and want to implement DNS encryption to bypass the DNS filtering that my stupid ISP is implementing in our country when using DNS Resolver (unbound). I know how the three encryption mechanisms work but I don't know which one of them is best in this day and age. I know DoT is ever-so-slightly faster than DoH in terms of latency. Not sure about DNSCrypt though.

Any ideas?

This is also an interesting conversation saying that DoH and DoT are pretty much useless and that the normal unbound is still the best choice.

I can probably use unbound behind a VPN to solve my ISP issue. Furthermore, I have a VPN tunnel to another site where I have a pihole w/ unbound that doesn't have any issues. I can point my local pihole to that remote pihole to solve my issue however I would lose DNS querying capability when power goes down on that remote site (which is pretty frequent). How do you implement DNS failover?

1 Like

If you are already using unbound, you can quickly configure it to be a forwarding resolver, rather than a recursive resolver. Adding these lines to your unbound configuration file will forward all queries via port 853 (DoT) to Quad 9. You can change your upstream server to meet your needs.

Related to the discussion about the privacy aspects of encrypted DNS vs. unbound, in your case it appears that to avoid your ISP intercepting or redirecting DNS queries you will need to encrypt them.

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

    forward-zone:
     name: "."
     forward-tls-upstream: yes
     # Quad9
     forward-addr: 9.9.9.9@853#dns.quad9.net
     forward-addr: 149.112.112.112@853#dns.quad9.net

I still don't have unbound in my local site. I probably will need to try this image out if I want the unbound route. Would going "unbound via VPN" vs. "unbound as a forwarding resolver with DoT" be faster? Or it's really a YMMV type of thing?

How do I set dnsmasq in pihole to do DNS forwarding failover instead of querying the forwarding DNS servers in a round-robin fashion?

Does unbound do caching if you follow the pihole website guide in using it?

In terms of performance, which one would have the best?

  1. Local pihole (dnsmasq, no unbound) -> wireguard tunnel -> remote pihole (dnsmasq pointed to unbound installed on localhost) -> remote WAN
  2. Local pihole (dnsmasq, no unbound) -> wireguard tunnel -> remote unbound installed on the same remote box -> remote WAN
  3. Local pihole (dnsmasq pointed to unbound installed on localhost) -> wireguard tunnel -> remote WAN

Yes.

If you can eliminate the wireguard tunnel and run the software locally, that will likely be faster than any of the options you listed.

I cannot eliminate wireguard because of the ISP intercept issue, if you remember. As soon as I use unbound recursion, DNS queries keep timing out. This is why I'm looking into either using unbound behind a VPN, DoT, or DNSCrypt. What is your recommendation?

This is what you need to change. Hide the DNS traffic in an encryption tunnel and the ISP cannot mess with it.

No need for a VPN. Encrypted DNS between your network and an upstream DNS server is all that you need.

Right. By encryption tunnel, you mean DoT, correct? In my mind, tunnel = VPN.

You can encrypt DNS using either DoT or DoH. The unbound example I provided uses DoT.

Right, but then you lose the advantage of DNS recursion since DoT and DoH are DNS forwarding. Isn't DNS recursion behind a VPN be a wiser choice?

That's for you to decide. Try both ways and see which best meets your needs.

A recursive resolver though a VPN may be really slow depending on how fast your VPN is. You'd also have to ensure the VPN provider is not spying on your and that your ISP does not detect and block the VPN itself. Just a few thoughts to consider.

So yeah, this is not a VPN provider we're talking about. It's a site to site VPN between my two sites. So basically, it's to route outbound traffic from my local unbound over to the tunnel and coming out the remote WAN. The average latency between the two sites is 5 to 10ms since both sites are from the same ISP.

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