Log should show hostnames instead of IP addresses.
Actual Behaviour:
Log only shows IP addresses despite having conditional formatting enabled, the two "Never forward..." options disabled and the correct router IP and local donation name set.
I am running an almost entirely Ubiquiti UniFi home network. A UniFi Security Gateway is providing DHCP, and I don't want to change that. It's giving the IP address of the Pi-hole to all clients as the sole DNS server. The LAN is set up with only the Pi-hole as the DNS server.
If I change the WAN DNS server to the IP address of the Pi-hole, it then begins resolving the names - but then it's all the USG, no individual clients. If I change it back (to 1.1.1.1/1.0.0.1), the IP addresses in the log are all correct, just not resolved. What am I doing wrong? Do I really need to add them all manually in /etc/hosts as per the FAQ? Any help is appreciated. New to Pi-hole and definitely not a networking professional.
I just noticed that a couple wired clients seem to have names resolved, but all wireless clients don't. All clients have IP addresses reserved/assigned by DHCP, so it's not simply a matter of static vs. dynamic IP addresses. And not all wired clients are resolved; my desktop computer is, but my Synology is not. I don't know if this helps in troubleshooting, but....
If the DNS address for the router is set to 1.1.1.1/1.0.0.1, none of the DNS requests should go to the Pi-Hole and nothing should show in the Pi-Hole log. Perhaps I'm not understanding what you are doing with your settings. Where are you making these "WAN DNS" changes?
What are you using for the upstream DNS servers in Pi-Hole?
Conditional forwarding doesn't work in all network configurations. My Apple routers don't support this, for example, so I just see client IP's at the Pi-Hole. So the /etc/hosts file is the best approach to map these IP's to client names.
Sorry, I probably overcomplicated the explanation. The Pi-hole is configured to use the Cloudflare DNS (1.1.1.1, etc.). It's connected to a switch that is connected to a router whose external (that is, the WAN port connected to the DSL modem) DNS is set to use those same servers. Configured in this way, most local hostnames aren't resolved.
The situation I described where I changed the DNS on the router itself to point at the Pi-hole is when I first noticed a local hostname FINALLY resolving, but of course then it only showed the router itself in the logs (or at least in the 100 most recent queries) -- which makes sense, since it's the last stop before traffic leaves the LAN. I would still expect to see other clients in the log, since everything else points to the Pi-hole for DNS, but those entries probably got shoved out of the top 100, and I'll admit I didn't study the log in detail since this wasn't what I considered a valid/desirable situation (the Pi-hole was, I believe, doing double-duty there -- resolving the DNS for the client, then resolving it again for the router).
At any rate, if this simply doesn't work with some networks, that's probably the case here. I just find it odd that some are resolving and others aren't. Whatever the case, I'll probably just go the /etc/hosts router after all. I don't like the idea of having to maintain that info in two separate places, but it's no less attractive than not having the IP addresses resolved to hostnames.
As a suggestion for improvement, it would be nice if the description under Conditional Formatting in the DNS settings explicitly said that it might not work with all networks instead of "One solution for this...," which to me indicated that it should just work, full stop.
Thanks for that link. At least for the time being, I've just updated the hosts file on the Pi and it's working as expected. It's not like there's a lot of turnover on my home network that will require a lot of maintenance of that file; I was just hoping to keep it a bit simpler. Thanks again!
After actually reading through that other thread, I'm not surprised the other person's setup wasn't working. Seems logical -- the clients were using the router as their DNS server, and outbound (WAN) traffic was using whatever servers were set for the router's WAN interface. The Pi-hole DNS would, at best, only have been used for LAN resolution.
When I had my router's DNS set to the Pi-hole, from a pure filtering perspective it worked fine -- everything went through Pi-hole. In my case, the problem was the logging: everything appeared to come from the router, not individual clients (though as mentioned, I would guess a deeper dive into the logs would have revealed two queries for each request, or at least those not blocked immediately: one to the Pi-hole, which would have passed unblocked requests along to the router, which in turn would pass it back to the Pi-hole for resolution before returning the necessary data to the clients.
Anyway, after giving this further consideration, what I believe was happening with my original setup was simply not Pi-hole's fault nor anything it could control. Those few clients whose hostnames were resolved were almost certainly passing along their own hostname to the DHCP server. The majority of clients on my network (e.g. Google Home, smartphones, etc.) likely weren't doing that, and so there was no hostname info to return -- just the IP address. By hard-coding that info in the Pi's hosts file, problem solved. (I'm guessing that I could probably have accomplished the same thing by updating the router's hosts file, but it's a lot easier to fix the Pi than the router if I screw something up.)
Anyway, my stuff's all working now, and I'm simply passing this info along in case it helps someone in future. Thanks again!
