No surprises here either - no hidden extra files, only those created by Pi-hole itself.
From your most recent debug log, the only option relevant for the translation of IPs into names for Pi-hole's Query Log is still the one recommended by Roo earlier:
However, bespoke REFRESH_HOSTNAMES setting wouldn't do anything for you beyond the default IPv4, as yours seems to be an IPv4 only network, and ALL would just include IPv6 addresses also.
The only remaining difference to a standard Pi-hole would be your substitution of lighttpd by Apache. I am not aware of Apache having any bearing on translation of IPs to names, but then again, lighttpd is Pi-hole's supported webserver.
You could try adding DEBUG_RESOLVER=true to /etc/pihole/pihole-FTL.conf and restart FTL by pihole restartdns. This should add more information regarding hostname resolution to /var/log/pihole-FTL.log
[2021-08-11 09:40:15.768 822640/T822646] Trying to resolve 192.168.100.65
[2021-08-11 09:40:15.768 822640/T822646] Setting nameservers to:
[2021-08-11 09:40:15.768 822640/T822646] 0: 127.0.0.1:53 (IPv4)
[2021-08-11 09:40:15.800 822640/T822646] Setting nameservers back to default:
[2021-08-11 09:40:15.800 822640/T822646] 0: 8.8.8.8:53 (IPv4)
[2021-08-11 09:40:15.831 822640/T822646] ---> "" (N/A)
[2021-08-11 09:40:15.831 822640/T822646] ---> not found
[2021-08-11 09:40:15.831 822640/T822646] Client 192.168.100.65 -> "" is new
[2021-08-11 09:40:33.468 822640M] ---> not found
[2021-08-11 09:40:33.468 822640M] getDatabaseHostname(): "SELECT interface FROM network JOIN network_addresses ON network_addresses.network_id = network.id WHERE network_addresses.ip = ? AND interface != 'N/A' AND interface IS NOT NULL;" with ? = "192.168.100.65"
[2021-08-11 09:41:14.423 822640M] ---> not found
[2021-08-11 09:41:14.424 822640M] getDatabaseHostname(): "SELECT interface FROM network JOIN network_addresses ON network_addresses.network_id = network.id WHERE network_addresses.ip = ? AND interface != 'N/A' AND interface IS NOT NULL;" with ? = "192.168.100.65"
[2021-08-12 09:27:14.635 906277M] **** new UDP query[PTR] query "143.100.168.192.in-addr.arpa" from eno1:192.168.100.65 (ID 15, FTL 14, /root/project/src/dnsmasq/forward.c:1592)
[2021-08-12 09:27:14.635 906277M] 143.100.168.192.in-addr.arpa is not known
[2021-08-12 09:27:14.636 906277M] ---> not found
[2021-08-12 09:27:14.637 906277M] getDatabaseHostname(): "SELECT interface FROM network JOIN network_addresses ON network_addresses.network_id = network.id WHERE network_addresses.ip = ? AND interface != 'N/A' AND interface IS NOT NULL;" with ? = "192.168.100.65"
[2021-08-12 09:27:14.643 906277M] **** got cache answer for Embers-iPad.dv.local / 192.168.100.143 / (ID 15, /root/project/src/dnsmasq/rfc1035.c:1555)
So it looks like those lines only exist directly after 'pihole restartdns'
[2021-08-13 08:13:20.288 973345/T973351] Client 192.168.100.43 -> "" is new
[2021-08-13 08:13:20.288 973345/T973351] Trying to resolve 192.168.100.53
[2021-08-13 08:13:20.288 973345/T973351] Setting nameservers to:
[2021-08-13 08:13:20.288 973345/T973351] 0: 127.0.0.1:53 (IPv4)
[2021-08-13 08:13:20.320 973345/T973351] Setting nameservers back to default:
[2021-08-13 08:13:20.320 973345/T973351] 0: 8.8.8.8:53 (IPv4)
[2021-08-13 08:13:20.352 973345/T973351] ---> "" (N/A)
[2021-08-13 08:13:20.353 973345/T973351] ---> not found
[2021-08-13 08:13:20.353 973345/T973351] Client 192.168.100.53 -> "" is new
[2021-08-13 08:13:20.353 973345/T973351] Trying to resolve 192.168.100.42
[2021-08-13 08:13:20.353 973345/T973351] Setting nameservers to:
[2021-08-13 08:13:20.353 973345/T973351] 0: 127.0.0.1:53 (IPv4)
[2021-08-13 08:13:20.385 973345/T973351] Setting nameservers back to default:
[2021-08-13 08:13:20.385 973345/T973351] 0: 8.8.8.8:53 (IPv4)
[2021-08-13 08:13:20.419 973345/T973351] ---> "" (N/A)
[2021-08-13 08:13:20.419 973345/T973351] ---> not found
[2021-08-13 08:13:20.419 973345/T973351] Client 192.168.100.42 -> "" is new
[2021-08-13 08:13:20.420 973345/T973351] 11 / 11 client host names resolved
It has 11 entries which is how many DHCP reservations i have.
Then when i do the nslookup for the IP
[2021-08-13 08:13:25.943 973345M] Set reply to DOMAIN (5)
[2021-08-13 08:13:25.944 973345M] **** new UDP query[PTR] query "65.100.168.192.in-addr.arpa" from eno1:192.168.100.65 (ID 5, FTL 19733, /root/project/src/dnsmasq/forward.c:1592)
[2021-08-13 08:13:25.944 973345M] 65.100.168.192.in-addr.arpa is not known
[2021-08-13 08:13:25.944 973345M] **** got cache answer for DESKTOP-CUV0IR9.dv.local / 192.168.100.65 / <unknown> (ID 5, /root/project/src/dnsmasq/rfc1035.c:1555)
[2021-08-13 08:13:25.944 973345M] Skipping detection of external blocking IP for ID 5 as query is PTR
DNS resolution is working fine, always has, its just purely the webpage not showing the name over the client IP.
However, i just tried to use group management > clients to add a direct name for my PC and i got the following error
So i assume this is the core of my issue, on startup it checks the dhcp clients against itself, and the query doesn't actually make it to FTL by the looks, it then records in its database the names to be used by the webclient.
I just ran this test, nslookup 192.168.100.53 from the server itself.
Hmm, strange. FTL should try to re-resolve hostnames on every full hour. Does this happen for you as well and - even more interestingly - does it fail to get the answer here again?
It almost seems as if there would be another DNS server snatching those requests to the loopback address before Pi-hole sees them.
Your ss output suggests you are running systemd's stub resolver alongside Pi-hole on a different port (5355).
What's the intention of having that running in addition to Pi-hole?
And even though it is reported as listening on a different port:
Could you try to verify if it would be involved by trying to stop and disable systemd-resolve?
So, it looks like even though pihole takes over the localhost resolver on port 53 on startup, it either takes long enough that the other resolver still responds, or it processes the dhcp devices before it takes over ownership of that port.
But it is all working now, thank you for the ongoing help instead of giving up.
This can safely be ruled out as we see in your logs that it "gives up" after only 30 msec.
What you found is really puzzling. I don't see how a query to 127.0.0.1:53 can end up somewhere else. I (and many more) run unbound on the same machine on 127.0.0.1:5353 and we never had any report about something similar.
I reinstalled fedora from scratch in december, installed pihole standard, the only deviation is that i dont use light httpd, but the files that are placed in the web directory i have a config for in httpd.conf.
There is one additional change that gets made with apache, and that is the sudoers file has an entry for lighthttpd user to control pihole, i change that to apache.
