I've got a pi-hole v5.18.3 FTL v5.25.2 on Ubuntu 22.04 and using pi-hole as the DHCP server.
I see a host in the query log called ubuntu-server.lan - but I don't recognise that name and it's not in the list of current leases. I also see an IP of 192.168.0.222 in the list of leases, which is shown as "unknown."
If I look up the IP like this:
pihole-FTL sqlite3 /etc/pihole/pihole-FTL.db "SELECT * FROM client_by_id WHERE ip='192.168.0.222';"
Thanks, I've been able to ID the client but was just wondering what is giving the hostname to that IP (and if it's the pi-hole, why doesn't it show that hostname in the leases, when hostnames for other leases are shown).
Typically the hostname is configured on the client itself.
Eg on a client of mine:
$ cat /etc/hostname
hakpc
$ hostname
hakpc
When the client connects to network, most of them advertise this hostname to the DHCP server during the lease negotiation.
As can be seen in the logs with that zgrep.
Most routers create local DNS records (A and PTR records) for this advertised hostname.
The A record can be looked up with below (10.0.0.2 is my Pi-hole which also functions as DHCP server):
DHCP clients may present a hostname during DHCP lease negotiation, which pihole-FTL/dnsmasq would then use to create respective DNS records.
Different client OSs may default to different name patterns, and depending on the client OS, there would be different ways to change or supply a name for a device (deHakkelaar showing but one common way for Linux based server distros above).
If a DHCP lease shown in Pi-hole's UI does not have a name, that would suggest that the corresponding client did not present a name.
OK, but what I'm not clear on is why the Pi-hole knows the name of the client in the Query Log, but not in its DHCP list. So the client presented a name to the Pi-hole for the Log, but not the DHCP negotation?
While most clients are listed correctly in both the Query Log and the DHCP lease list, some (about 10% maybe?) are listed as "unknown" in the DHCP.
Please upload a debug log and post just the token URL that is generated after the log is uploaded by running the following command from the Pi-hole host terminal:
Indeed, although in this case the clients that are given as "unknown" are things like Chromebooks and mobile phones.
Essentially, I'd understand if the clients in question were not presenting their hostnames at all (so that Pi-hole listed them as "unknown" in both the Query Log and the DHCP list), but that's not the case. They are named in one but not the other.
Note that the DHCP lease information is independent from Pi-hole's DNS functionality.
The only relation here is that Pi-hole's DHCP manages creation of DNS records according to DHCP lease information for active clients (on a side note, DHCP servers are not required to do so in general, and consequentially, there are some out there that won't).
Your debug log shows that there may have been another DHCP server active at some time in the past, but currently, your Pi-hole seems to be the only DHCP server on the link its host machine its connected to.
By default, Pi-hole would do reverse lookups for any observed client IP every sharp hour, so local names could have been supplied by another DNS server in your network.
But your debug log shows you are using public upstreams, and your Pi-hole's Conditional Forwarding is disabled, ruling out that local names could have been sourced from another local DNS server (unless you'd be using some hidden magic like firewall redirects for port 53 traffic to alternate local DNS servers).
This would suggest that Pi-hole is simply employing its default fallback strategy for showing hostnames rather than client IPs in its UI, by trying to use prior knowledge from its database (which your earlier SELECTs confirms to exist).
It'd be interesting to know whether and why some of your DHCP clients would fail to present a hostname. Are these random clients, or would they share common traits, like all being VMs of a specific variety?
Hard to say - it seems to be a mix of Android mobiles (athough not all Android devices on the network) and Linux-based OSes like Chromebooks. One of them is my WiFi AP, which is a Unifi box.
I suppose as long as I can track them down in some way it's not really a problem (not that its exactly an important issue in the first place - I was just curious about Pi-hole's behaviour).