pihole runs in a docker container on a synology with its own virtual network/ip address.
Here is the docker-compose who create the container (my router is 192.168.8.10):
Sorry for the delay - your answer slipped past me.
alias-clients are not required to show hostnames instead of IPs.
That experimental feature will aggregate dashboard statistics for several IP addresses as aggregated by a network interface's hardware address under a single hostname. Your observation is expected: It's effect is limited to the dashboard.
However, associating client IPs to hostnames is done automatically by several other means like regular reverse lookups for client IPs or inspecting directly observable, same-link network information.
If you were not seeing hostnames in Pi-hole's dashboard, then there must be a separate reason for that.
If your router is your DHCP server, using your router as Pi-hole's only upstream or enabling Pi-hole's Conditional Forwarding would be required for reverse lookups for local IPs to succeed. Of course, this would imply that your router would not only know the names for its DHCP clients, but that it would also provide those names as replies for DNS queries.
Note that not all routers would do so.
You may verify whether your router at 192.168.8.10 does by running a reverse lookup past it, e.g.
nslookup 192.168.8.6 192.168.8.10
Another fundamental prerequisite for seeing individual clients (IP or hostname) in Pi-hole's dashboard is that clients have to talk to your Pi-hole directly.
Your debug log shows your router's DHCP server to distribute your Pi-hole as local DNS server to DHCP clients - but also 1.1.1.1:
*** [ DIAGNOSING ]: Discovering active DHCP servers (takes 10 seconds)
Scanning all your interfaces for DHCP servers
* Received 300 bytes from eth0:192.168.8.10
Offered IP address: 192.168.8.166
DHCP options:
Message type: DHCPOFFER (2)
router: 192.168.8.10
dns-server: 192.168.8.5
dns-server: 1.1.1.1
--- end of options ---
That would allow clients to use 1.1.1.1 for DNS at their own discretion, bypassing Pi-hole completely. Pi-hole has to be the only DNS resolver for your clients.
Thank you for your detailed explanation and advices.
I understand what aliasclient is for then.
I was hoping of using it as a way to identify names clients in pihole from their mac address instead of ip address. (client MACs to hostnames instead of client IPs to hostnames)
Most of the devices in my LAN get dynamic IP from my router.
I will try to make the router know the names of its dhcp clients, as you suggest and make reverse lookup.
192.168.8.6 is the virtual ip of unbound container.
All clients use pihole ip address as DNS. You're right, I don't need cloudflare 1.1.1.1
I configured specific leases on the router dhcp config for all clients. This allows me to customize the host file in the pihole container. Thanks for all.
Apart from that, a problem is that stock android smartphones put automatically 8.8.8.8 as secondary DNS (or third) in network wifi config; and I didnot find any way to prevent this.
Same problem here, but the question was answered here (January 2021). That answer says it's pointless to add this to the web interface, because v5.x will soon be superseded.
Since development of v5.x apparently continues (lots of improvements lately) I wonder if @rdwebdesign can be encouraged to look at this missing part of the web interface, when using alias clients?
Are they OnePlus devices?
To clear up a misunderstanding, its not Google Android doing that ... I believe.
I have four different brand Android devices that dont show the behaviour you described above.
I have up till now only seen OnePlus devices doing that.
To fix, advertise the Pi-hole IP two or even three times as a DNS IP via your DHCP service.
For Pi-hole's own DHCP service thats as easy as:
A friend of mine has an OPPO phone which is running their version of Android called colorOS. He's on colorOS v11.1, based on Android 11. His phone does the same thing. We were trying to configure it with his router and Pi-hole and no matter what we did the phone always adds an additional DNS entry for 8.8.8.8. There's no warning that it chooses to do this nor seemingly any way to disable the behaviour.
Interestingly OPPO and OnePlus are very close so this probably explains the same behaviour on both brands.
The one that made that up must have been sniffing the wrong glue.
Every sane admin can tell you that any redundant DNS server(s) should be identical in the way they reply / the records they hold.
Google 8.8.8.8 doesnt know about your local DNS records.
Very strange that another brand adopted the same stupid implementation.
Or I am mistaken and they have a very very good reason to do so
Disadvantage of masquerading the DNS queries before being dropped at Pi-hole is that they will all appear as coming from the router/firewall.
So those devices that misbehave wont show up on the Pi-hole dashboard but the router/firewall IP instead.
Best to have both advertise the Pi-hole IP via DHCP multiple times ... and DNS redirecting with the firewall.
That way those pesky OnePlus devices show up on the dashboard and any other misbehaving devices/apps will get the redirect.
FYI, some routers/firmware have that DNS redirecting already as a setting.
You could try entering 0.0.0.0 for that second DNS address field.
Or enter an unused private IP from your LAN subnet thats outside your DHCP scope.
For the clients it doesnt matter that much if this second DNS IP is dead.
You can validate on the Pi-hole host with below (I have two Pi-hole nodes):
pi@ph5b:~ $ pihole-FTL dhcp-discover
Scanning all your interfaces for DHCP servers
[..]
dns-server: 10.0.0.2
dns-server: 10.0.0.4
What dns-server's are displayed when you run below one?
You could disable the router DHCP service and let Pi-hole take over that part:
That way you could try to advertise the Pi-hole IP three times and see if that "Realme" device adds a fourth 8.8.8.8 DNS IP which seems highly unlikely ... but still:
