Nice! Glad to hear you got it sorted 🙂

I was playing with my setup the not too long ago and while reading the documentation, I realized that I never ran the "pihole reloadlists" command. Since doing that, my roku has been unable to show ads.

Pihole will do nothing to most streaming service ads, This article is super misleading.

Writes blog about blocking ads with pi hole

Blog has modal complaining about active pi hole instance blocking ads

No duplicate IP concerns. They both work with the same static list and when they need to assign dynamically - because requester isn't in the static list - they assign from a non-overlapping range. Works well.

I think it is the upstream dns but strangely only the v6 pihole is reporting it, not my v5 one.

Wait, both are DHCP providers? Admittedly, I haven't looked too deep at pihole clusters - but do they synchronize their leases? If not, there's a chance you might have duplicate IPs which can cause some interesting network behaviors.

If your logs say both are having issues at the same time, I'd go with the second troubleshooting option - accept DHCP, but statically set DNS to the same servers your Piholes use.

If there's an issue, it's with the upstream DNS (reachability or their rate limiting)

I wouldn't put a ton of faith in the modem's self reported status. Do you have a 24/7 wired machine you can ping 1.1.1.1 and 8.8.8.8 with?

Looking at the dashboard for each pihole I can see that both show failures happening at the same time... the queries skyrocket during the outage as devices retry their dns lookups. If it was only one pihole experiencing a problem, they wouldn't both show the outage I don't believe.

Regarding pihole order, both are DHCP providers to the network and I have each make itself the first dns provider and the other second, so order varies across my network. Whichever pihole satisfies the DHCP request is the primary for the device it satisfies and the other secondary. The outage is for every device and both piholes though, as both show their query requests go through the roof at the same time.

That's an interesting thought. I've had a bad cable cause network problems for me years ago that took a long time to figure out. The 2 piholes are in different rooms in the house. Not sure if they end up connecting to the router through the same switch or not... but I don't think there's any one cable that could go out that would affect both and also NOT take out the internet completely. I shouldn't be able to ping by ip address with a bad cable knocking out both piholes. Still, I'll have to look at my setup more closely.

DNS isn't instantaneous - and it's hierarchical. If your systems are configured with pihole #1 (let's say x.x.x.21) as primary and pihole #2 (x.x.x.22) for secondary and 21 fails, there will be a time when DNS requests time out. IIRC, for Linux it's something like 4 seconds.

I know this because I saw a really weird thing at a work lab where requests were taking 8 seconds to complete for all the internal sites, but internet sites worked immediately. Turns out two of three PDNS systems in our cluster weren't configured properly for local lookup and systems would timeout on primary (+4 sec), timeout on secondary (+4 sec), then resolve with the tertiary server.

I'm not saying that's what's happening here, but if this is a recent occurrence you could start with your primary/pihole and check system logs, updates etc. Or you could take a system that has this behavior and either swap the pihole order, and/or remove the pihole from the DNS all together to see if it's even your gear causing the issue.

I've had something similar happen recently and the cause was a bad Ethernet cable from my router to my pihole. Maybe try replacing the cables and see if that helps.

Yeh, you get a router you actually manage and don’t use your ISPs shit.

If you do not have access to DHCP configuration on the ONT then your only option is to insert your own router in between the ONT and the rest of your network.

• Are you provided any administrative functions for the ONT?

In most cases, these devices offer a "bridge mode" that let's you put a router behind it, so it works more like a modem (disabling its built in Wi-Fi, DHCP, etc). That's likely what you want. It's possible you will need to contact the ISP to put it in bridge mode if they are particularly restrictive about device control.

Thanks! It's working now. I just had to open port 53 on the host (not just the docker container).

are you sure your Pi-hole’s DNS is exposed at port 53 and accepts traffic?

I think this is where I went wrong. dig shows that the connection times out. This may also explain why forcing clients to use that for DNS would cause them to lose internet access. Although I thought that port would be open because it's listed in the yaml file for docker-compose. Is there another step I need to open that from the host machine?

Your other devices need to reference your new Pihole as their DNS provider

If you just set it, the lease in your client devices likely hasn’t expired yet

edit: re-read your post before coffee

First, are you sure your Pi-hole's DNS is exposed at port 53 and accepts traffic? Try using dig from another device to see whether it works or not

dig +short @192.168.0.175 allowed-domain.tld
dig +short @192.168.0.175 blocked-domain.tld

If Pi-hole works, you should get 0.0.0.0 as an answer for any blocked domains.

my phone and other devices on my network could still visit the site

Have you tried disconnecting and reconnecting to the network in order to make sure these devices get new DHCP leases? Once it's done, which DNS servers do they say they use? Also make sure your phone and computer's browser aren't using DNS-over-HTTPS or DNS-over-TLS (I know Firefox use Cloudflare's DNS-over-HTTPS by default in some setups)

If by that you mean the DNS settings tab, I've selected CloudFlare for both IPv4 and IPv6. I also tried mixing it with Googles DNS, but to no luck.

What upstream DNS server(s) are your pihole configured to use? It is possible that the responses your pihole is giving are to farther away IPs than what 1.1.1.1 returns. If you have not already, try setting 1.1.1.1 as the upstream DNS server on the pihole.

Nice! You should also be able to use the pihole logs to check which domains it's hitting if you need to loosen it later.

Alright, I went nuclear and blocked almost all DNS lookups by my roku. Almost any requests for a roku domain are now blocked. If something gets broken I'll undo it, but so far, so good.

Yeah, I've never had success with the secret menu configuration. Most of it is cryptic to me. I appreciate the support and I'm definitely going to keep trying. (I think I found some domains to block that seem promising but I'm not celebrating yet.)

I can tell it’s hitting my Pi for the DNS lookup.

This is a good sign!

I don't have a Roku so can't help at that level, but this site mentions some domains to block and also a secret menu that lets you remove ads: https://appuals.com/block-ads-roku-tv/

Welp... Looks like whatever I saw last night was just temporary. It's back to showing ads. I tried adding a few other random lists to no avail. I can tell it's hitting my Pi for the DNS lookup. I'm going to try and go through the logs and manually block ad-related domain lookups.

All good! I'm glad it was that. Initially I thought they might be doing tricky stuff with hard coding their DNS server but apparently not, just needed the right block list 🙂