[webinterface]Test if pi-hole is used as resolver


I urge to build-in a check if the browser used to visit http://pi.hole is also resolving through Pi-hole, for non-local domains.

This because more and more browers are going rouge and do their own upstream resolving.

You can argue that then http://pi.hole can’t be visited if this is the case.

I think that developers of browsers are capable of learning and do not sent upstream domains, of which they know are local.

Firefox loads Ads - other browsers don't

Tell me more please :slight_smile:

Also : Can’t we block that traffic at our router ?!


If your router supports that but you first had to know that it is happening.


How would you like to see such a test happen? I don’t think DNS resolution is possible with pure Javascript, i.e., without relying on special external libraries for it. You might prove me wrong in which case I’ll have a look at it.


On entering the webinterface a you can call an external address by example a newly created link http://pi-hole.net/dot.gif which send a ‘single’ dot.gif file back.

A short time after the request the script in the webinterface looks if that query is present in the log/query of the Pi-hole server and not more that then or five second ago.


I was think again about this and I am thinking it is better to use a subdomain with a short TTL so that it is not cached.

Example http://check.pi-hole.net with a TTL of 2 seconds.

This won’t have to transfer anything and there could be just a be 403 error on it. If you want to minimize the traffic to the minimal then user action would be needed to run the test.


Im forcing all dns trafic on port 53 to pi-hole, can do that easy on EdgeRouter :grin:

Found a nice guide here https://youtu.be/EFWbYQPe3XI


I know and I also catches 5353 and 5355 and sent those to my DNS server. Not all information sent on those ports are DNS request but calls home for Google, etc.

But most of the users of Pi-hole don’t have the knowledge or possibilty to fo this.


I wouldn’t have the possibility either if I wouldn’t push everything through two routers at home, so I perfectly see a relevance here. Still, I’m not totally convinced. How would you use the subdomain for detecting that everything is shiny? I’m not specifically targeting low/no data transfer (as this is local anyway), I’m just looking for a solution that does not cause trouble in case Pi-hole is not the current resolver.

Checking if resource XYZ is reachable under http://pi.hole/admin/XYZ may fail as some users define other TLDs for their Pi-holes and remove the original pi.hole reference completely. Otherwise, it could be as checking if(location.host !== "pi.hole"){ notify_user(); }.

If you come up with any feasible way of testing it, this would be appreciated.

Maybe something like this could be shown:


You have to take in account that there could be a split-horizon to have local domains not being sent upstream (so using DNS setting from the system) and TLD are send to and external DNS server.

I am interested in warning for plain (external), DNS traffic not going through Pi-hole, when a user enters, or does a check in the Pi-hole webinterface.

And possibilty to fo this should have been possibilty to do this


And send to and external DNS server should have been send to an external DNS server :wink:

As far as I’m aware, DNS checks cannot be performed from within Javascript. So such tests much somehow involve (partially) failing requests depending on the particular situations.


My current test shows

followed by

when you access the page over something else than pi.hole/admin. The dismissal will be stored locally in the client’s browser so this confirmation will be shown on each client at least once.

Maybe not the most elegant way of doing it, but it is a start.


I don’t follow. A request to a external DNS server is intercepted and offered to Pi-hole.
Pi-hole can sent that upstream.
If that request is on a encrypted stream I am not aware of that.

The request is made as default link in the Pi-hole Webinterface page.
After a few seconds the scipt looks in the query results if that URL is requested in the past 5 to 10 seconds.

If not found then the browser is going strange. :wink:


This is a rather complicated chain of actions (trying to resolve something, looking this domain up in the query log). If you can reach the Query Log over pi.hole, chances are very high that you’re using your Pi-hole as resolver…


All those thing were mentioned in my opening posting.


This is possible, see my most recent post here for the way how you imagine it to happen. My idea deviated from this: Warn the user if he visits the dashboard over something else than pi.hole as - when they visit over the Raspberry’s IP address - they will still see the dashboard even if the Pi-hole itself is not used at all for DNS resolution. As there are situations where this is okay, users can choose to permanently hide the warning.


I am not affraid for internal traffic or resolving. Those warnings are welcome but do not indicate usage of external DNS traffic not going through Pi-hole. I don’t think there is a TLD .hole. but if then there would be a lot of funny domains possible.


It’s just that Javascript itself cannot really so any sophisticated DNS actions so every check has to be a multi-process thing. Maybe like what Chrome does (firing off random domains) but I’m not yet convinced that trying to resolve some domain and then check if this domain happens to come up in the query log is a good thing. It may be okay for a manual test, but a manual test itself may not be used all that much on the other hand so it’s unclear if it’s even worth all the effort that would go into an implementation.


In a few itterations of Chrome you can bet on it that the browser only will work default with it’s own Google DNS. You have seen in this forum the addiction to Alpabet services, even on something that simple as resolving DNS resolving.

Most people don’t know what they are getting in their homes of which they don’t know that it is a Trojan Horse.

Pi-hole is for me a effective way to decide myself what I share with the outside world.
I have many ways to have my privacy in my own hands but most users only have limited knowledgement and put trust in packages as Pi-hole.

We can’t hold all the time their hands, but we can warn if something is suspicious.