Add "PROXY protocol" Support -> quick win: DoH, DOT, DNSCrypt, Loadbalancing, dns rulesets with dnsdist

Feature Requests
27

Scott Helme has a good guide on setting up a DoH server sit in front of your Pi-hole:

I do something similar with traefik but for DoT rather than DoH

2 Likes
32

I would not recommend someone to do this. As the author said himself, he only did it because he had a (properly protected) nginx already around. Installing one for the purpose of DoH is a sledgehammer. You are much better served with a lightweight Wireguard that is not only faster and more reliable (a stateless connection, i.e. more speed and less data traffic) but also much easier to set up.

See the Pi-hole Wireguard guide which does this job out of the box. In fact, tunneling the entire traffic is not the default configuration but can be enabled at any time also from remote and for individual clients only.

34

I have a use-case for this feature.

I have multiple VLANs (main/kids/guest/etc) and use the group feature to apply different lists to VLAN/devices, which works very well. Recently I was thinking about how I can extend pi-hole beyond my home network which means DoT and DoH. I have a mix of mobile devices so I need to implement both to make sure all of them are covered. I was using NextDNS for mobile devices but it is not as flexible as pi-hole and I don't want to maintain 2 DNS solutions.

I setup dnsdist which is very powerful and flexible. It allows me to apply VLAN rules based on SNI/Host header, and only add EDNS client subnet when the requests are made outside of the home network. So I can setup my kids' devices to use the same blocking rules no matter where they are. However for any device that uses DoT/DoH I cannot see their IP addresses as they shows up as pihole (dnsdist runs on the same machine as pihole).

I thought about using the EDNS client subnet to expose this information as discussed in this thread, but

  • CDNs will not give me optimal IP addresses when I am overseas. Obviously this case is rare.
  • dnsmasq will forward existing client subnet data to upstream if --strip-subnet is not used. This is ideal when making requests from outside of the network, but not desired when at home. As far as I can see there is no way to tell dnsmasq to conditionally forward EDNS client subnets. If I tell it to strip subnet then I won't have optimal CDN responses.

As described above, when we are using EDNS client subnet for providing client IP/MAC address, we cannot use the same information for CDN optimisation and vise versa.

So I believe the best way is to keep EDNS client subnet as they are intended to be used, and introduce PROXY protocol for client identification purposes.

It is not a big deal that I can't identify mobile devices those use DoT/DoH so I am happy with what I have. But this would be a very good quality-of-life improvement.