Glad that the debug looks OK, I saw some errors with FTL etc.
Now to work on getting the GUI registering the queries correctly.
There was an update earlier for Core 6.0.4, so do a sudo pihole -up to grab it and ensure the latest logic going on behind the scenes.
I see 6.0.4 just got pushed. I will update to that.
Any ideas why the logs are not displaying any other systems on the LAN hitting the pihole.log?
I have confirmed all DNS servers attributes are pointing to the pihole
[✓] Update complete!
Core version is v6.0.4 (Latest: v6.0.4)
Web version is v6.0.1 (Latest: v6.0.1)
FTL version is v6.0.2 (Latest: v6.0.2)
let see if this helps anything
How do you mean - can you see them in the Query Log if you reload the page or enable the Live view?
So for example.
I just did the core update, and the logs displayed in the GUI successfully
From SSH if I nslookup anything, the logs are displayed in the GUI successfully.
However when I attempt to hit websites from client webbrowsers, or from mobile device, there are no logs showing in the GUI or pihole.log
all devices that were reporting in logs, stopped at 18:11 (EST)
should i restart the dns resolver, flush the network table, flush the logs perhaps?
It's strange.
If Pi-hole is used then you can see that the logs are appearing. That implies that those client web browsers are not using Pi-hole for DNS, even if the OS is. Try that nslookup test on each client to confirm it's blocking flurry.com and that you can see the query in Pi-hole.
Then try navigating to flurry.com in the browser. You should the browser's "unable to connect" error and see the query in Pi-hole's log as blocked. If you see the site load, then the browser is not using Pi-hole. Probably a plugin or setting using another server or DoH in the Firefox example I gave above is ignoring the OS's DNS and bypassing Pi-hole.
You may find that your mobile has additional DNS servers in use. The OPPO and OnePlus are known to do this, see this post for info. If non-Pihole DNS are configured then the computer or device will always be able to bypass Pi-hole.
Server: pihole1.localdomain
Address: 10.200.0.6
Name: flurry.com
Addresses: ::
0.0.0.0
When attempting to access the page via a browser, it states it is being blocked by a pihole adlist
the pihole GUI however shows no result change, no log
That implies an extension in the browser is blocking it and so it never gets sent to Pi-hole. Something like AdBlock Plus, or UBlock Origin (my knowledge of what's available these days is out of date). They use similar block lists to Pi-hole.
If Pi-hole was blocking it, you'd see it in Pi-hole's log and the browser wouldn't know anything about Pi-hole, it would simply get 0.0.0.0 back and be unable to connect and report an error.
I have a vanilla build OS here that I use for testing, no extensions etc. on them...
they were all reporting up till 18:11 today, that's when they stopped....actually I have an idea...
UPDATE:
Fixed that concern... sigh... sorry this thread forked into so many concerns, really thankful for your assistance. This community is awesome!
So, now I see logs reporting to Pihole successfully on all devices and all VLANs
All results are showing this in the GUI
**Forwarded, reply from 127.0.0.1#5335**
correct me if I am wrong.... going back to your post 2h ago, this command:
sudo pihole-FTL --config dns.upstreams '["127.0.0.1#5335"]'
was the 'fix' to confirm unbound was not working, or showing 5335 within the logs? I want to make sure I understand it correctly to wrap my head around it. Was I mostly on-track deploying unbound?
Can you advise what the cause was and how you fixed it and confirmed it fixed? It will help others searching in the future.
Regarding the earlier command... your Unbound install was good. Following the online guide it ends up on port 5335, which yours is. So then it's just a case of making Pi-hole use it as its only upstream server.
Your trying out that dig command that jfb posted showed that Pi-hole wasn't able to reach its configured upstream server, but that querying Unbound directly on port 5335 worked fine.
There happened to be an elusive bug for the last few days, where upgrading from V5 to V6 didn't carry across V5's configured upstream servers, so in the resulting V6 they were blank and Pi-hole couldn't resolve anything. Note, that this bug was found and fixed today in Core v6.0.4.
One of the bandaid fixes for that bug was to run that command I gave but with servers for Quad9, a common external provider. That stuffs those DNS servers into Pi-hole as the upstream and gets people with this problem partly up and running again.
At this point I didn't know what your Pi-hole's upstream servers were or whether you had upgraded from V5, although I see you did mention it was a fresh install, I didn't notice that at the time. So if you had a previous upstream configured that was now missing or broken – such as cloudflared on port 5035 – or if you had encountered this bug... either way, what you really needed in there was your working Unbound server on port 5335.
So I took that bandaid command and adjusted it to configure Pi-hole with your Unbound server. After running it, your first dig command now worked, because Pi-hole now had a valid upstream server, your newly installed Unbound.
So all is now good. jfb asked a good question – why did you install Bullseye and not the latest Bookworm? If that was an oversight, you might consider doing another Teleporter backup and redoing with a fresh install of the latest Bookworm, installing Pi-hole, installing and configuring Unbound and restoring your Teleporter backup. That will give you a lot more breathing space before needing to upgrade again.
Appreciate this detailed follow-up
Can you advise what the cause was and how you fixed it and confirmed it fixed? It will help others searching in the future.
>>during maintenance today of the gateway, there was a security feature that was enabled during the upgrade. Regarding the timestamps when Pihole stopped reporting logs, lined up about the approx. time the firmware pushed. I went looking into the gateway security settings and disabled the setting
Regarding the earlier command... your Unbound install was good. Following the online guide it ends up on port 5335, which yours is. So then it's just a case of making Pi-hole use it as its only upstream server.
>>OK that helps me understand and makes sense
Your trying out that dig command that jfb posted showed that Pi-hole wasn't able to reach its configured upstream server, but that querying Unbound directly on port 5335 worked fine.
>>OK so @x.x.x.x vs @x.x.x.x -p 5335
understood
....Note, that this bug was found and fixed today in Core v6.0.4 .
>>That's awesome the team found and patched that so quick!
One of the bandaid fixes for that bug was to run that command I gave but with servers for Quad9, a common external provider.
>> hm ok, that's good to carry with me for any future troubleshooting
I see you did mention it was a fresh install, I didn't notice that at the time. So if you had a previous upstream configured that was now missing or broken – such as cloudflared on port 5035 – or if you had encountered this bug... either way, what you really needed in there was your working Unbound server on port 5335.
>> I did perform a fresh install of Pihole today as tutorials and guides recommended and advising performing a 'dirty' or 'inline' upgrade was not advised coming from version 10 (to backup and make a fresh SD) When going through the initial install wizard I selected 'Cloudflare (DNSSEC)' as the DNS provider out of the gate. I then remembered from my v5 build that unbound was probably not deployed on v6 today and went down a rabbit hole attempting to deploy and test it, which led me here on 'best practices' to verify my current knowledgebase on the topic
So I took that bandaid command and adjusted it to configure Pi-hole with your Unbound server. After running it, your first dig command now worked, because Pi-hole now had a valid upstream server, your newly installed Unbound.
>> Thank you so much for hashing it out together, you had excellent feedback and were very patient during the discussion. Sometimes I fall out of the loop as my previous deployment was solid for many years and wanted to be sure I completed the current v6 deployment in the same manner
why did you install Bullseye and not the latest Bookworm? If that was an oversight
>> I actually just checked that now as I may have gotten the codenames confused previously and have confirmed the current OS is bookworm
PRETTY_NAME="Debian GNU/Linux 12 (bookworm)"
NAME="Debian GNU/Linux"
VERSION_ID="12"
VERSION="12 (bookworm)"
VERSION_CODENAME=bookworm
ID=debian
Going back to the original post regarding 150max query errors that occurred on v5, and I saw again working with you on v6. I did deploy this again today, as respect to what the mod stated in that post, I have had a hard time finding the proper fix to address this concern... I will have to keep digging on that.
If you have any suggestions on this I am all ears 
Thank you again for your time on this, it connected the dots, and I hope this thread can assist others. We all come from various skillsets and help one another in these communities, it is really great to see everyone that helps one another.
Very appreciative!
That's a good approach, to tie those events together and explore.
The forum has a bookmark feature, and you can add notes which is very handy. Click the ... under a post and then the bookmark icon and More options... It turns blue when set and you can see them all from the bookmarks icon in your icon in the top right.
Good, you're on the most recent major version so good for a few years.
Perhaps the observation above is relevant, perhaps the OS and other installed apps are inadvertently hammering Pi-hole because the OS is using itself as the DNS. You could try fixing that as described and then keeping an eye on it to see if it's fixed it.
Thankyou for the kind words.
This topic was automatically closed 21 days after the last reply. New replies are no longer allowed.