Unsure if Pihole+Unbound are blocking ads on iPhone

Help
82

Those worries are unjustified.
Your debug log shows that you've enabled Pi-hole's Conditional Fowarding, which may close a partial DNS loop for unknown/undefined local hostnames, but only if your router would use Pi-hole as an upstream resolver.

A DNS loop would result in no DNS resolution at all, as DNS requests would bounce between Pi-hole and its upstream forever or until time-out, if Pi-hole's rate-limiting wouldn't kick in first.

Your debug log shows no signs of rate-limiting, and in conjunction with your stats results, there is no indication that has happened during the last 24 hours.
Furthermore, if it had, it would have affected local hostname resolution exclusively.

None of this would contribute to your rermaining observation:

Your Pi-hole's Query Log shows that Pi-hole sees DNS requests and does not block them.

The most likely explanation would have been that you've either disabled Pi-hole's blocking at some time or that you've exempted certain clients from filtering via Pi-hole's group management.
However, neither your stats nor your debug log would indicate that this has been the case.

Certain aspects of your debug log would suggest that your Pi-hole is running on DietPi OS.

Did you install Pi-hole via DietPi's installer?

Unrelated, but I notice a few quirks in your debug log that would interfere with mDNS resolution (click for more)

Your screenshots show that you use local as the forwarding local domain.

You should be aware that .local is reserved for use by the mDNS protocol and should NOT be used with DNS.

In your case, local also differs from the domain name used by your router, which your screenshots show as localdomain.

As your router would only know about hostname.localdomain (if at all), this would mean that requests for domains like hostname.local could close a loop if your router would use Pi-hole as upstream.

You have defined quite a few clients in the form hostname.local in your debug log that would have prevented that from happening for those names .
Still, those names should be removed, as .local is reserved for mDNS.

In addition, your debug log suggests that some homeassistant process binds port 5353, which is also reserved for mDNS usage.
What's the reasoning behind that?

83

Neither of these have happened. I don't have any groups created outside of the default group and its remained unchanged.

I am running my Pi-hole on DietPi OS (Buster). I haven't upgraded it to Bullseye yet. And...I believe I did use the DietPi installer to install Pi-hole years ago. I don't honestly remember. It's possible I didn't.

Last night, @deHakkelaar was gracious enough to actually help me change this. I don't want to clutter the thread with anymore of my nonsense, but just a few posts up, we go through this process. Now, the domain name of the router (LAN) is: lan.home.arpa. The domain for the other two VLAN segments are iot.home.arpa and adc.home.arpa respectively. The Pi-hole's Conditional Forwarding settings are:

2023-08-06_10-11-33
2023-08-06_10-11-33964×463 34.1 KB

I have also since removed the .local from all clients that were defined in the hosts file.

For this, I experimented with Homeassistant several years ago. I don't use it. I thought I got rid of it. How can I ensure it's completely gone and isn't binding to port 5353 anymore? I've tried looking at uninstall instructions for it but it's not located in the place the documentation says it is and I can't find any traces of it. None of the services seem to be running/exist:

root@DietPi:/home# sudo systemctl stop hassio-supervisor.service
Failed to stop hassio-supervisor.service: Unit hassio-supervisor.service not loaded.
root@DietPi:/home# sudo systemctl stop hassio-apparmor.service
Failed to stop hassio-apparmor.service: Unit hassio-apparmor.service not loaded.
root@DietPi:/home# sudo systemctl disable hassio-supervisor.service
Failed to disable unit: Unit file hassio-supervisor.service does not exist.
84

Whats the name of that process?

sudo ss -nltup sport = 5353

85

@mods/devs , can any of you see in the debug logs if black/whitelist entries or any regex'es are bugging the blocking?
I dont have any black/whitelist/regex entries in use so I dont know what to look for in the dbase.

86 
root@DietPi:/etc# sudo ss -nltup sport = 5353
Netid   State    Recv-Q   Send-Q     Local Address:Port     Peer Address:Port   
udp     UNCONN   0        0                0.0.0.0:5353          0.0.0.0:*       users:(("homebridge",pid=21578,fd=30))
udp     UNCONN   0        0                0.0.0.0:5353          0.0.0.0:*       users:(("hb-service",pid=639,fd=20))

I do use Homebridge but I do not use Homeassistant after testing it out a few years ago.

87

Pfff two different processes listening on the same 0.0.0.0:5353 UDP socket ... bound to go wrong.
Check Homebridge support whats going on!
To me this looks a bit awkward.
EDIT: It is possible though if one is only listening and not replying.

88

I don't know why Homebridge is running on 5353. Its default port is 8080:

hb-service install --port 8080

Is there a way to change/ensure Pi-hole and Homebridge are not conflicting without breaking/needing to reinstall either? That's a task I definitely don't want to do.

89

Am not sure.
I have hardly any experience with mDNS.

pi@ph5b:~ $ grep 5353 /etc/services
mdns            5353/udp                        # Multicast DNS
90 
root@DietPi:/etc# grep 5353 /etc/services
mdns            5353/tcp                        # Multicast DNS
mdns            5353/udp
91

There's still definitely an issue, even after the changes last night to the domains. I'm trying to screen mirror my iPad to my TV, and it's struggling to connect. Sometimes it connects for a couple minutes and then disconnects. Other times, it just times out.

EDIT: This used to work without fail. The only thing that changed was a reinstall of unbound.

pihole -t shows:

Aug  6 13:11:57: query[A] dummy from 192.168.3.16
Aug  6 13:11:57: forwarded dummy to 192.168.1.1
Aug  6 13:11:57: query[AAAA] dummy from 192.168.3.16
Aug  6 13:11:57: forwarded dummy to 192.168.1.1
Aug  6 13:11:57: reply dummy is NXDOMAIN
Aug  6 13:11:57: reply dummy is NXDOMAIN

192.168.3.16 is the TV. Why is it forwarding dummy and why is it returning NXDOMAIN?

This is part of the issue I've been trying to convey/solve in this thread. Things like this are happening and nothing with the setup seems to explain why. The iPad should have zero issue screen mirroring to the TV.

92

The logs can tell you more:

pihole -t

Do realise that DNS is only a very small part of the whole process!
Once a DNS name with its IP is cached by the client, it stays cached there for a considerable period.
300 seconds for below domain:

pi@ph5b:~ $ dig +noall +answer pi-hole.net
pi-hole.net.            300     IN      A       3.18.136.52
93

See my edit in my previous reply. I posted results from pihole -t. But I don't understand what dummy and NXDOMAIN mean. This is the only device doing this.

94

Its the TV thats querying that dummy name.
Pi-hole just tries to forward it to see if gets resolved to an IP.

95

NXDOMAIN = Non Existent Domain.

Thats the reply from 192.168.1.1

96

Hmm...so why would the Pihole be returning a non existent domain for this one device? We seemingly fixed the domain/forwarding issue last night.

97

Pi-hole is not returning NXDOMAIN.
Its your router 192.168.1.1 replying with NXDOMAIN and Pi-hole relaying the answer to your client.

98

Ahhh, got it.

Okay, so...why would the router be doing this? I know you likely can't answer this. The only settings that I've changed in the router were those domain name changes and that was the only change in years.

99

Do you have a DHCP client with that dummy name?
Or maybe manually configured DNS records for that name?
Else I wouldnt know why your TV would query for that name.

100

I have absolutely nothing named dummy on my network. All of my clients have statically assigned IPs, so the DHCP isn't handing out any IPs to any device with that name.

101

Do you mean static DHCP reservations?