pi-hole config gotcha

Vengance_01

Supreme [H]ardness
Joined
Dec 23, 2001
Messages
7,213
I am just sharing this with others. If you want pi-hole to block adds, do not have a secondary DNS configured for clients. Even if you have your pi-hole DNS server setup as the primary DNS server, setting a secondary server to 8.8.8.8 allowed queries to use this vs the primary. Also Highly recommend following craft Computing's tutorial to setup PI-Hole as a recurise DNS server so you don't need to use servers that can track your movements on the web

 
How good of a Pi is needed as a minimum, or ideal?
Also, heard it won't work for youtube or twitch

It's just DNS (and DHCP if also set up to provide addresses) so very little is required. If Pi-Hole is all that you plan to run, then any of the wired ethernet models is fine, really. Though I'd recommend at least a 3B+, ideally a 4B 2GB or better so you have room to grow and possibly add other services later.

I've never had an issue with YouTube and Pi-Hole interoperability. No idea for Twitch.
 
Oh, also: If you set up a local recursive resolver (Unbound, etc.), your ISP will be able to sniff every DNS query you make. There's currently no way to encrypt requests from the local resolver to arbitrary Internet authoritative resolvers. There is a proposal for Authoritative DNS-over-TLS (ADoT), but AFAIK it's not been implemented anywhere.

Alternative is to set up Unbound or Stubby as a stub resolver, configure it for DoT or DoH, and point at one or more of the available DNS providers (Google, Cloudflare, Quad9, etc.).
 
Oh, also: If you set up a local recursive resolver (Unbound, etc.), your ISP will be able to sniff every DNS query you make. There's currently no way to encrypt requests from the local resolver to arbitrary Internet authoritative resolvers. There is a proposal for Authoritative DNS-over-TLS (ADoT), but AFAIK it's not been implemented anywhere.

Alternative is to set up Unbound or Stubby as a stub resolver, configure it for DoT or DoH, and point at one or more of the available DNS providers (Google, Cloudflare, Quad9, etc.). Whats worse.
Any links on this config so I can read up. I am curious.
 
Last edited:
Talking about on your device, not the pi-hole, right? Setting a second on the pi-hole should be fine...
 
Any links on this config so I can read up. I am curious.

Not off-hand, but a quick search on Pi-Hole + Stubby or Unbound brings up a lot of links. A search on Pi-Hole + DoT (DNS over TLS) or DoH (DNS over HTTPS) should also bring up a fair bit of info.

The concept is basically the same as in the video:
  • Install Unbound or Stubby (both should be in the standard repos).
  • Configure to listen on a different port (e.g., 5353).
  • Configure to forward to the desired public resolvers.
  • Point Pi-Hole at it as its resolver.
I chose Stubby, as it's very simple, small/lightweight, and does exactly what is needed for DoT (no DoH support, however). Only thing I dislike about it is the logging is non-existent, which sucks if you're trying to troubleshoot (instead you have to restart the service in the foreground with verbose flags and redirect to a file).


Talking about on your device, not the pi-hole, right? Setting a second on the pi-hole should be fine...

Correct, assuming you're setting Pi-Hole to go directly to public resolvers (e.g., Google, Quad9). If you're setting up a local recursive resolver (as in the video), or a local stub resolver to encrypt DNS before going to a public resolver (i.e., as above), then Pi-Hole must be set to point to only it.

In all cases, the hosts on your LAN should be using only the Pi-Hole as their DNS resolver.
 
Yeah. Make sure to configure your Android clients manually because automatic DHCP WiFi connection on Android devices is almost always going to assign router IP for primary DNS and 8.8.8.8 for secondary DNS. That is why you should also create a custom set of IPTables for your Pi-Hole DNS server and drop inbound + outbound packets for ISP DNS addresses and Google DNS addresses + set other rules specific to your network. I would start with these - https://networklessons.com/uncategorized/iptables-example-configuration , but use newer syntax with "conntrack --ctstate" instead of "state --state" .
 
Yeah. Make sure to configure your Android clients manually because automatic DHCP WiFi connection on Android devices is almost always going to assign router IP for primary DNS and 8.8.8.8 for secondary DNS.

The only reason I can imagine Android overriding the DHCP-provided DNS is if you've manually configured the private DNS option (which is system-wide). Even then, it wouldn't hit the gateway for DNS resolution.

I've owned many Androids ever since the G1 running every release and have never had the OS otherwise override the DHCP-provided DNS resolvers.

If the problem is that the router's DHCP server is fixed to use itself and 8.8.8.8 as the DNS resolvers (which would affect every LAN host, not just Android), then the solution is to disable it and use Pi-Hole's own DHCP server.


That is why you should also create a custom set of IPTables for your Pi-Hole DNS server and drop inbound + outbound packets for ISP DNS addresses and Google DNS addresses + set other rules specific to your network. I would start with these - https://networklessons.com/uncategorized/iptables-example-configuration , but use newer syntax with "conntrack --ctstate" instead of "state --state" .

I assume you mean for these to be configured on the border router/firewall, and not the Pi-Hole server itself. Because configuring such rules on the Pi-Hole will do jack. It also assumes the router will even accept such a configuration (i.e., not any consumer-level units).
 
it does the job, I used it for last 6 months with Raspberri Pi4, 32-bit OS.
 
Yeah. Make sure to configure your Android clients manually because automatic DHCP WiFi connection on Android devices is almost always going to assign router IP for primary DNS and 8.8.8.8 for secondary DNS. That is why you should also create a custom set of IPTables for your Pi-Hole DNS server and drop inbound + outbound packets for ISP DNS addresses and Google DNS addresses + set other rules specific to your network. I would start with these - https://networklessons.com/uncategorized/iptables-example-configuration , but use newer syntax with "conntrack --ctstate" instead of "state --state" .
This was exactly what I saw despite having an assign DNS server on the Unifi DHCP Scope...
 
The only reason I can imagine Android overriding the DHCP-provided DNS is if you've manually configured the private DNS option (which is system-wide). Even then, it wouldn't hit the gateway for DNS resolution.

I've owned many Androids ever since the G1 running every release and have never had the OS otherwise override the DHCP-provided DNS resolvers.

If the problem is that the router's DHCP server is fixed to use itself and 8.8.8.8 as the DNS resolvers (which would affect every LAN host, not just Android), then the solution is to disable it and use Pi-Hole's own DHCP server.




I assume you mean for these to be configured on the border router/firewall, and not the Pi-Hole server itself. Because configuring such rules on the Pi-Hole will do jack. It also assumes the router will even accept such a configuration (i.e., not any consumer-level units).

You might be right. I use DHCP Static Reservations, which isn't the same as DHCP Server and with such a router configuration, automatic DHCP configuration on Android devices tends to assign gateway to be the primary DNS and 8.8.8.8 to be secondary DNS. That is why I always configure Android devices manually to be in control of both primary and secondary addresses. There is another good way to prevent connections to device-set secondary DNS addresses that you can't control for those who use Pi-Hole or use AdGuard Home, which, in my opinion, is superior to Pi-Hole. Regardless of whether you prefer Pi-Hole or AdGuard Home, you can enforce a DNS-over-HTTPS-only mode by blocking outbound UDP port 53 for WAN. Normally, you have to use outbound UDP port 53 to create an initial plaintext connection to a DNS server, even for a DNS-over-HTTPS connection. Its called bootstrapping, but some DNS servers, such as AdGuard DNS servers, do not require such bootstrapping and your initial connection to their DNS servers is encrypted over TCP port 443. The main secret to connecting to DNS-over-HTTPS servers without bootstrapping is to either use SDNS stamp addresses (https://dnscrypt.info/stamps/) or knowing the right address. For AdGuard DNS-over-HTTPS servers, use https://94.140.14.14/dns-query or https://94.140.15.15/dns-query to prevent boostrapping, NOT https://dns.adguard.com/dns-query. For bootstrap-free connections to DNS-over-HTTPS DNS servers, outbound UDP port 53 for WAN can be blocked to drop unencrypted connections to DNS servers, such as Google's 8.8.8.8 DNS servers. Using official AdGuard DNS-over-HTTPS address (https://dns.adguard.com/dns-query) requires bootstrapping over UDP port 53... I have no idea why that is so.
 
I am just sharing this with others. If you want pi-hole to block adds, do not have a secondary DNS configured for clients. Even if you have your pi-hole DNS server setup as the primary DNS server, setting a secondary server to 8.8.8.8 allowed queries to use this vs the primary. Also Highly recommend following craft Computing's tutorial to setup PI-Hole as a recurise DNS server so you don't need to use servers that can track your movements on the web




That's an interesting bit of info regarding the recursive DNS. I never even heard of that before, or if I had I've forgotten about it.
 
One thing I don't understand is: Why can't adding the list of bad URLs to my router's blacklist do the same thing?
 
One thing I don't understand is: Why can't adding the list of bad URLs to my router's blacklist do the same thing?

Well, a router/firewall can really only block a site by IP address (layer-3). In order to deal with a list of blocked sites it would have to do a reverse-lookup on every single packet for a match. That would be a huge suck on the router's resources (assuming it had the RAM/storage to hold the list in the first place), as router/firewall ACLs are not really meant to deal with many thousands of individual addresses. Even if all that were OK, it still may not work depending on how the DNS PTR records are configured (e.g., the IP address lookup could resolve to the hosting provider, not the blocked site).

Doing the blocking by DNS is much more efficient. The protocol is designed to deal with names. It's a simple modification to a process that has to occur anyways (i.e., name resolution). It adds no overhead to packet routing.
 
I use two rpi's for redundant piholes, so my network DNS are only the two piholes.

Why do I want to point the piholes to unbound instead of Quad9? Is it just in case I don't want Quad9 to know my queries but, rather, I'm ok with DNS root services knowing them?
 
I use two rpi's for redundant piholes, so my network DNS are only the two piholes.

Why do I want to point the piholes to unbound instead of Quad9? Is it just in case I don't want Quad9 to know my queries but, rather, I'm ok with DNS root services knowing them?

Basically, yeah.

No matter how you set up your DNS, there's the potential that at least some activity will be tracked. The likelihood that the root servers are doing so seems pretty small, but as mentioned above the unencrypted nature of recursive lookups means the ISP could sniff or even intercept everything were they so inclined.
 
This is great. I set one up earlier this month but couldn't block youtube ads. Thanks for the github suggestions I'm finally blocking ads.
 
Love my Pi-hole. I have my phone auto connect back to my house VPN so that it filters while I'm away.

Here's a good write up about how to Pi-hole with Unbound and Wireguard setup. https://github.com/notasausage/pi-hole-unbound-wireguard/blob/master/README.md

Also be mindful of the adlists you use. Not all follow the correct format so they do more harm than good.
Here is a hightly regarded one though: https://www.github.developerdan.com/hosts/

https://firebog.net/ is another great set of lists. Again though after awhile you get diminishing returns.

I find that for me and my needs that thestock adlists and then adding DeveloperDans "Ads & Tracking" and "Hate & Junk" lists block everything I desire to be blocked.
 
I use an alternative to Pi-Hole ; AdGuard Home.

Installed it to a Windows Server Core VM in my environment and it's remarkable at what is blocked .. half of my blocked requests are "Roku" related.. that was very insightful information lol
 
I use an alternative to Pi-Hole ; AdGuard Home.

Installed it to a Windows Server Core VM in my environment and it's remarkable at what is blocked .. half of my blocked requests are "Roku" related.. that was very insightful information lol
Yeah Roku TV's are really bad with talking back to the mothership.

Didn't know Adguard had an open source DNS level blocker. Good on them for that one. Their "comparison" to Pi-hole though is pretty laughable. "No HTTPS on web interface." Ummmm If you turn your DNS filtering software open to the world you're a idiot so you don't need HTTPS. I'd like to know where the cert for that HTTPS is coming from though. Self-signed would throw errors in browsers. Blocking of Malware and other stuff and adult filtering content? Yeah...that's all easy on Pi-hole with very little work. I just hate stupid baseless PR like that.

And their DoH and DNS over TLS argument? You actually get more privacy and piece of mind using Unbound with Pi-hole versus DoH. Tech like DoH doesn't stop your ISP from seeing your traffic. If you visit Pornhub your ISP still knows you're at Pornhub. It just didn't get to see the DNS query. Unbound gives me a local resolver that I have full control over which is better than trusting a third party DNS provider like Cloudflare. Upstream providers see all your DNS traffic, and you have no control over what they do or will do with that data.
 
How good of a Pi is needed as a minimum, or ideal?
Also, heard it won't work for youtube or twitch
This is true. And with many other sites.

I ran a pi hole for years. When YouTube and twitch changed things up, I realized I used the pi hole for basically only a few things like them. it became more of a hassle to keep up with the pi, and I had properly configured browsers on all pc’s, and the people using mobile devices on my network didn’t care about the ads.
In the end I stopped using pi hole and I’ve been fine. It’s actually not as simple as 10 minutes. Sure I had the software installed and setup in 10 mins. Configuring things how you want them, AND still not breaking functionality of some websites, was not easy. In the end it was too much work for me. Always chasing down something. And things change, how ads operate change. Pi hole not blocking YouTube or twitch anymore were a major reason people stopped using it.
 
Yeah Roku TV's are really bad with talking back to the mothership.

Didn't know Adguard had an open source DNS level blocker. Good on them for that one. Their "comparison" to Pi-hole though is pretty laughable. "No HTTPS on web interface." Ummmm If you turn your DNS filtering software open to the world you're a idiot so you don't need HTTPS. I'd like to know where the cert for that HTTPS is coming from though. Self-signed would throw errors in browsers. Blocking of Malware and other stuff and adult filtering content? Yeah...that's all easy on Pi-hole with very little work. I just hate stupid baseless PR like that.

And their DoH and DNS over TLS argument? You actually get more privacy and piece of mind using Unbound with Pi-hole versus DoH. Tech like DoH doesn't stop your ISP from seeing your traffic. If you visit Pornhub your ISP still knows you're at Pornhub. It just didn't get to see the DNS query. Unbound gives me a local resolver that I have full control over which is better than trusting a third party DNS provider like Cloudflare. Upstream providers see all your DNS traffic, and you have no control over what they do or will do with that data.

HTTPS for web interface via a self-signed SSL certificate protects login credentials. My ISP uses a self-signed certificate for modem login and DD-WRT does the same for their firmware. Your ISP sees a lot more when you use Unbound than what your ISP sees when you use a public DoH/DoQ/DNSCrypt resolver by AdGuard or Cloudflare. I can't say for sure whether one should trust ISP over a public DNS resolver like AdGuard DNS. I think it depends on specific policies, ISP and DNS server locations.

DoH/DoQ/DNSCrypt is not an end-to-end encryption, but it does hide more information from your ISP and from those trying to perform MITM attacks. When combined with Encrypted SNI, DoH becomes even more secure, but it is true that Encrypted SNI is not popular, requires browser support, and is slowly being replaced with more secure Encrypted Client Hello protocol.

I think DoH/DoQ/DNSCrypt or any other DNS encryption is mostly useful for initiating a connection to a VPN provider. VPN providers use their own DNS servers, but the initial VPN domain resolution is 100% plain-text without DoH/DoQ/DNSCrypt. You can also use a local DNS server as a secondary VPN kill-switch that blocks all domain resolution, except domains your VPN uses for initial connection to establish a secure tunnel.
 
I use an alternative to Pi-Hole ; AdGuard Home.

Installed it to a Windows Server Core VM in my environment and it's remarkable at what is blocked .. half of my blocked requests are "Roku" related.. that was very insightful information lol
Just FYI, you can run Pi-hole on a Linux VM.
 
Back
Top