I have set all hostnames in the DHCP, a week ago, would like to see them used in the query log and statistics.
Actual Behaviour:
I have set all hostnames in the DHCP, a week ago, and they are all also used now as pi hole is set as the DHCP server. Though, they are not used in the query log. I flushed the network table and restarted the DNS resolver. Though, the query log and network table still show the original host names.
The host names used are also not the ones visible in my router (it still shows all the connected devices, even with DHCP off)
Though I also have to add that since today the querylog no longer shows hostnames, it only shows IP-addresses. So maybe flushing the network table and restaring the DNS resolver yesterday did something that only affects the next day. As after it I still saw the old host names for new entries in the query log.
I added some devices (not the device above) as a test to the hosts file, and for these devices now the hostname works. So it seems the DHCP hostname is ignorerd for some reason.
I noticed the time was off by ~17 minutes, could that be part of the problem (as it seems the flush did not work)?
I have now corrected the time.
Updating the Gravity I have set is pretty heavy. This might have caused the time from changing. I now set a cronjob to update the time after updating the Gravity.
This did not work, but I also was not able to follow the entire process.
Added the 245 to the DNS list
I was not able to see the delete button (found out later that it was hidden by scrolling) so I flushed the network table. The network table was empty and slowly filled up.
the devices from the hosts file, show the given host name. The rest does not have a host name (including the 245)
Manually removed the 245 device.
Re-appeared in the list, still without a host name
I also tried it with a different device, though it did not work.
Removed the 245 from the DNS table, now. Left the other device there to verify if a couple of hours could do the trick.
I've seen a similar situation where Pi-hole has the wrong hostname for an IP because it previously saw the hostname with that IP, even though the hostname has now changed. Flushing the network table and restarting the DNS resolver didn't fix it. I posted an example in a different thread.
In my case I think it was a PTR request against the IP of the wrongly named host which updated the name in Pi-hole and made it display correctly from that point onwards.
Your situation looks slightly different because it relates to your static entry for Dennis-laptop seemingly not being picked up. Nevertheless it would be interesting if you could do a PTR request against the IP and see if that changes anything. Perhaps some similar naming update mechanism is at play. You can use the dig or nslookup command to do this, from any client which is using Pi-hole for its DNS.
(Edit : assuming that your static entry is still present, if not then please try adding it back again)
dig -x 192.168.2.245
nslookup 192.168.2.245
Does that return Dennis-laptop or LAPTOP-V1HR47PC? And if it returns the correct name, is it now showing as the correct name in the Query Log too?
That request went to fe80::1 (your router's link-local IPv6, in all likelihood), indicating that your router is advertising its own IPv6 address as local DNS resolver.
That is a separate issue altogether, and a more severe one, as it would allow your IPv6-capable clients to by-pass Pi-hole completely.
While that should be addressed, it wouldn't affect your current difficulties with resolution of DHCP client hostnames.
Your SQL output demonstrates that flushing or deleting an entry from the network table removes entries from network_addresses: When the entry reappears, it has a different record id (was 8, is now 36),
Entries in client_by_id, however, would remain untouched.
I'll ask development to take a deeper look.
Very unlikely, as Pi-hole itself holds the definitions for DHCP client name directly.
That should not be necessary - usually, your OS reliably keeps track of that (click for more)
One notable exception would be Raspberry Pi OS coming online after a prolongued powerdown.
RPis lack a battery-backuped RTC, so they read in a last known time from a file during boot, and then resume regularly syncing time with a time server once boot is complete.
If that time would be off by too far, the time-sync service would refuse to update the clock, so you'd have to update it manually.
17 minutes would not be enough to trigger that refusal, though.
That may suggest that your RPi may not have been able to sync with a time-server for a rather long time, as the RPi's system clock could be expected to lose or gain only a few seconds per day.
Is your RPi Zero aware of and allowed to sync with a time server?
Flushing FTL's internal memory isn't possible right now, so what we see here is very likely just that FTL knows the old name from the database (after starting) and caches this name until it gets an update. However, since,
it never gets an update and preserves the old name in memory. You flush the database and on the next query dumping (every minute), FTL re-adds the old name into the database.
i.e. the real issue we need to address is: Why can FTL not determine the new name (to replace the old)?
The name resolution workflow inside Pi-hole is as follows (remaining steps are skipped once we get a reply somewhere):
We send a PTR to FTL
We send a PTR to the system-configured resolver (e.g. docker container names)
If NAMES_FROM_NETDB is true, we try
3.1. to get an exact match IP <-> hostname
SELECT name FROM network_addresses WHERE name IS NOT NULL AND ip = ?;
3.2. to get a host name associated with the same device (but another IP address)
SELECT name FROM network_addresses
WHERE name IS NOT NULL AND "
network_id = (SELECT network_id FROM network_addresses
WHERE ip = ?)
ORDER BY lastSeen DESC LIMIT 1
And only if this all fails, we have no host name. I don't see how client_by_id could be involved here and just verified this flow in the v5.23 code. I also furthermore confirmed that we never read from client_by_id - we only ever store stuff in there.
Unfortunately, the debug tokens already expired by now, they could have given some further clues here looking at if pihole.log would have contained log lines of the names - but most likely the debug log wouldn't have had them anyway as it is always only a rather short excerpt.
What er can do to go on from here would be:
Please add
DEBUG_RESOLVER=true
to the file /etc/pihole/pihole-FTL.conf (create if it does not exist) and run
pihole restartdns
This should include rather extensive information about every (internal) name resolution process in var/log/pihole/FTL.log which should be pretty self-explanatory and should show us where it is going wrong. Then, Pi-hole also has a setting REFRESH_HOSTNAMES and a few more friends which could influence this behavior, but I suspect everything is default settings where everything should "just work".
That specific dig reply should be disregarded - it was not answered by Pi-hole, but by fe80::1 (most likely the router, judging by that interface identifier).
A previous direct lookup through Pi-hole returned successfully:
This is also the expected result, as Pi-hole is acting as their DHCP server, and the MAC for 192.168.2.245 listed the hostname as returned by dig above, in both debug logs.
A sequence of steps as suggested by nprampage (involving creating and deleting Local DNS records) was able to resolve the issue for some users with similar persistent observations of old hostnames.
Is the mixture of .ip and .lan private TLDs relevant here? The fact that the latter name appears as default makes me think that the .ip suffix needs to be .tld to align with wherever this is being set, in order to be usable.
