I recently upgraded from Pi-Hole v5 to v6 after running Pi-Hole v5 for 3 months with no issues. Pi-Hole v6 install was an upgrade in place, no errors were encountered, and all functionality was normal after upgrade. Pi-Hole Diagnostics continues to show no errors.
However, about 2 weeks after the v6 upgrade, added a new Amazon Echo Show 8 device to my network. The Echo Show 8 picked up its DHCP IP from Pi-Hole and worked as expected so I had no reason to consider anything amiss.
The other day, I decided to check Pi-Hole to review the DNS activity of the Echo Show 8 just to see how talky it was. I then noticed that the IP the Pi-Hole had issued to the Echo Show 8 was not showing in the Active Leases table under Settings-DHCP. I can query that IP in the Query Log but it gives the hostname of a ChargePoint Car Charger that had that IP briefly as its DHCP address before the v6 upgrade. The DNS activity is clearly that of the Echo Show 8, however.
The ChargePoint Car Charger is showing up in the Active Leases table at is current DHCP IP and its activity can be found in Query Log by IP or hostname. I did have a Static DHCP Configuration for the Car Charger prior to the Pi-Hole v6 upgrade associating its MAC address with the hostname "Car-Charger". After the Pi-Hole upgrade, the Charger is being associated with the hostname "car-charger" and the Echo Show 8 with "Car-Charger".
I tried adding a new Static DHCP Configuration for the Echo Show 8 for its MAC address and a hostname of "Echo-Show-8", restarted Pi-Hole DNS, restarted Raspberry Pi 5 to correct issue but problem remains. I removed that new entry, tried full shutdown after 24-hour lease expiration with no change.
Running on Raspberry Pi 5, Raspbian OS v12, 8 Gb RAM, 128 Gb SD
Pi-Hole is Core v6.0.5, FTL v6.0.4, Web IF v6.0.2
Fing Agent is also running on Pi 5 and it is v12.9.1 and is working as expected
Debug Token:
https://tricorder.pi-hole.net/Ps1X2baL/
Both your Car-Charger's and your Echo-Show-8's MAC addresses have been configured for those respective names, but not for a fixed IP address.
That would allow a DHCP server to assign any IP address, i.e. while they would be consistently named, they may over time be assigned different IPs on each DHCP lease request.
I guess what happened here is that Pi-hole's DHCP server has assigned an IP address that once belonged to your car charger to your Echo device.
Let's see what how Pi-hole's DNS server would answer respective requests:
nslookup car-charger
nslookup echo-show-8
nslookup <ip.of.car.charger>
nslookup <ip.of.echo.8>
You are correct that the Echo-Show-8 picked up a DHCP IP that had previously been assigned to Car-Charger and that is part of the issue. What bothers me is under Pi-Hole v5, DHCP leases changed assigned hosts several times over the months but the Pi-Hole DHCP server never misrepresented which host had what IP before.
As to the nslookup responses, those are below:
nslookup car-charger
Server: 127.0.0.1
Address: 127.0.0.1#53
Name: car-charger
Address: 10.0.0.26
nslookup echo-show-8
Server: 127.0.0.1
Address: 127.0.0.1#53
** server can't find echo-show-8: NXDOMAIN
nslookup 10.0.0.26
26.0.0.10.in-addr.arpa name = car-charger.lan.
nslookup 10.0.0.127 ## The DHCP IP of the Echo-Show-8 ##
** server can't find 127.0.0.10.in-addr.arpa: NXDOMAIN
So the nslookup results are consistent with what I am seeing through the Pi-Hole GUI. The Car-Charger host picked up a new DHCP address from Pi-Hole and both the new IP and the hostname resolve correctly using nslookup. Pi-Hole issued the Echo-Show-8 a DHCP IP previously used by Car-Charger but neither that IP nor the Echo-Show-8 hostname resolve correctly in an nslookup command.
I do use cloudflared on the Raspberry Pi as the custom external DNS resolver for DNS over HTTPS (127.0.0.1#53) and all DNS requests process normally under Pi-Hole v5 and v6. Even though the Pi-Hole DHCP server is issuing the Echo-Show-8 its IP could cloudflared somehow be playing a role in the Pi-Hole DHCP server not recording the Echo-Show-8 properly in the Active Leases table? I don't see why Pi-Hole should look for an external resolution during that process but that's the only other actor in the hostname/DNS chain on the Pi that I know of.
Solved the issue, but I'm not sure if it was the combination of the following three actions or only one or two were needed.
I first modified the Static DHCP setting of the Echo-Show-8 to include its current DHCP IP address and then rebooted the Pi 5 to force a complete restart of the DNS server. Pi-Hole still did not show the Echo-Show-8 or its IP in the Active Leases table after reboot.
I then went into Expert mode under Settings - DNS for Pi-Hole and noticed Conditional Forwarding had an entry of "false,10.0.0.1/24,10.0.0.1" in that field. I don't remember ever making a Conditional Forwarding entry from Pi-Hole v5 through the upgrade to v6 so suspected this might be an artifact of the upgrade. Since I did not need a conditional forwarder, I deleted this entry entirely. From the syntax, though, it looks like the "false" should have been directing no conditional forwarding for any of my local addresses. I rebooted the Pi 5 but the Active Leases table still omitted listing the Echo-Show-8 or its IP.
Thinking I might need to force the Echo-Show-8 to request its DHCP IP again from the Pi-Hole to get its entry into the Active Leases table I went into that device and told it to forget my wi-fi network. I then reconnected after entering wi-fi info again and this time host Echo-Show-8 and its IP show up correctly in the Active Leases table.
I had not been using specific IPs in my Static DHCP entries as I was only interested in providing recognizable hostnames by MAC when the default vendor identifier was somewhat cryptic.
Under v5 this never presented a problem. I'll leave things alone for a couple of days, then I'll test if removing the IP from the Echo-Show-8 / MAC entry causes an issue again in v6.
Together with your Echo not showing up with an active lease, that would confirm that your Echo didn't acquire a DHCP lease through Pi-hole.
And indeed, your debug log shows that there are two active DHCP servers on your network.
*** [ DIAGNOSING ]: Discovering active DHCP servers (takes 6 seconds)
Scanning all your interfaces for DHCP servers and IPv6 routers
* Received 300 bytes from 10.0.0.82 @ eth0
Offered IP address: 10.0.0.111
DHCP options:
Message type: DHCPOFFER (2)
lease-time: 86400 ( 1d )
router: 10.0.0.1
dns-server: 10.0.0.251
dns-server: 10.0.0.1
--- end of options ---
* Received 303 bytes from 10.0.0.251 @ eth0
Offered IP address: 10.0.0.123
DHCP options:
Message type: DHCPOFFER (2)
lease-time: 86400 ( 1d )
dns-server: 10.0.0.251
domain-name: "lan"
ntp-server: 10.0.0.251
router: 10.0.0.1
--- end of options ---
Every time your echo-show-8 had acquired its DHCP lease through 10.0.0.82, it would not have appeared in Pi-hole's Currently active DHCP leases.
It wild also seem that 10.0.0.82 manages the same DHCP pool range as Pi-hole, or it least their ranges overlap, i.e. the same IP address may have been assigned by both DHCP servers (even at the same time, and if a client would fail to probe for duplicate IPs, you'd have created quite a confusing issue).
That's what changed it:
By chance, your Echo device accepted Pi-hole's DHCPOFFER rather than the other one's.
I've no idea why you have to run two DHCP servers, but If you require that second DHCP server to run for reasons, then you should at least change its DHCP pool range to not overlap with Pi-hole's, and you'd probably want to limit it to offer leases only to specific clients.