DNS Request Analyser from PiHole Dashboard

OK, so I have run into an issue from time to time where I will visit a site, and because it’s accessing an external site that PiHole Blocks to deliver content, pages and content won’t appear, now sometimes it’s not apparent that something has been blocked unless you dig into the inspector for the page, which can lead to a lot of drama and back and forth work trying to troubleshoot.

What I’d like to suggest is a (what I hope could be) simple interface in the PiHole Admin GUI, you’d enter a URL, and the PiHole would do a fetch in the background of the page (I know there are a couple command line Linux tools that can grab a page this way) and analyze the DNS requests being made from the unit during that page fetch.
Once the page completes loading, the console spits back a report not dissimilar to the query log, showing all DNS requests made while loading the page, and what was accepted and rejected, allowing the end user to White/Black list the domains directly from that page.

This differs from just querying the blocklist, as it checks sites that the end user may not be aware their domain is loading.

The pros I see in this is:

  • it creates a sealed system for testing problematic pages,
  • a detailed log could be generated and used for troubleshooting unusual behavior
  • it eliminates any user end issues, allowing troubleshooting of an issue to eliminate the PiHole as a problem source
  • it reduces time and troubleshooting from end users and administrators

Doesn’t this feature already exist? Any DNS requests will show in the query log, along with blocked status.

This will show all requested domains.

The issue is in a network that pulls a lot of requests, (especially machines with multiple internet facing applications) the requests get lost in the flood of information.

The trigger for this was me trying to access a site, the query logs showed no issues, but in reality, the Pihole was blocking that request, but as my source machine was making a very large number of requests at the time, it was impossible to tell which ones were related to the page I was trying to access, I had to one by one test unblocking and reblocking every domain that was blocked to work out which one was the culprit.

As I noted, its mainly to eliminate PiHole as the source of the issue in the first place, and allow troubleshooting to be focused on the users machine.

The idea of making a sealed testing environment tool like this allows for simpler workflow and less effort and work on the administrators end, it removes the ‘clutter’ of other apps, sites and machines, and allows the admin to focus on the queries specifically related to that URL, something the query log just cannot do right now. (for other websites and apps at least)

Can this also be done by disabling Pi-Hole temporarily? Disable Pi-Hole, content still does not load, then Pi-Hole is not causing the problem (and vice versa).

Have you tried the methods in this FAQ?

I already solved my specific issue, (the PiHole was the culprit) but again, it is not always practical or realistic to cut over the DNS, especially when you have a suite of applications and services running on that machine using the PiHole DNS that you don’t want running through standard public DNS.

I’m simply suggesting a tool that could provide a lot of end user value, and likely would not need a lot of specialty work to create, it is definitely something I would regularly use.

Again, I’m fully aware of how to use the software, I understand how to troubleshoot things, I do it regularly, but I see trawling through a crowded query log, that often breaks and refuses to load to find a culprit as an absolute pain, and something that can be avoided.

Note that the Adam:ONE tool mentioned does some of those things already, I’m simply suggesting moving an equivalent tool into the PiHole Interface and making it Browser and Platform independent, and integrated into PiHole. Actually a lot of that article suggests third party tools that do exactly what I’m suggesting.

A core part of this is I don’t want to have to use third party tools, or specific browsers, a lot of my networks users use mobile devices which can’t have these installed anyway, which makes troubleshooting significantly harder.

Again the pros I mentioned, its all about sealed systems and eliminating all other variables.

When I faced similar problems singling out offending clients in the past, I found /var/log/pihole.log to be quite useful, especially when grep’ed from the command line. But the raw content is also available via Pi-hole’s UI under Tools|Tail pilhole.log.

For me, that was enough to tackle my problem (granted, I also wished for some kind of filtering out requests and answers by specific clients, but the log itself seems to lack that traceability for the answer part).

Would pihole.log be closer to the tool you are missing? Could it perhaps be expanded in ways to meet your needs?

I seem to be hitting the same wall here: I am not seeking a solution to a problem, I am suggesting a new feature, as the ones in place don’t meet that need.

It makes sense, but no, as it doesn’t match what I’m suggesting here, all these suggestions are focused in the wrong direction to what I’m suggesting, they’re reactive focusing on locating and solving the problem after it occurs. The tool I’m suggesting is a proactive solution, allowing admins to test these issues in real time, without leaving the PiHole Interface for any reason, either before it occurs or when reported to them without specifics.

This is also about making a tool that doesn’t require a lot of technical knowledge to use, so that any ancilliary users who are not linux/command line adept can do this without any real training. Any solution needs to not rely on the end users touching the command line, or working in an external application.

Essentially how I see this working:

  1. User puts URL into a field in PiHole Interface and initiates testing. (I’d have this as its own page)
  2. on the PiHole end, a logfile is created of the test, capturing all output (this can be a temporary file, deleted after 24-48hrs or something similar)
  3. The URL is passed to a tool that accesses and parses the web request on the PiHole end.
  4. Either an independent log of the request is made, capturing all DNS requests, or the PiHole Log is parsed to display only the entries from this specific request.
  5. The PiHole Web Interface displays these DNS requests in an interface like the PiHole Query Log interface, and an option to download a copy of the logfile is included. The user can then Black/White list entries as needed.

That’s all I’m suggesting, I see having this tool as really beneficial, If I were adept at coding/scripting, I’d have already written this tool, but as I’m not, I’m suggesting it as an addition to the PiHole Web Interface.