Pi-hole v6 not resolving client hostnames from pfSense after upgrade

Help Community Help
1

The issue I am facing:
After upgrading to Pi-hole v6.1, hostnames for client devices are no longer resolving correctly in the web UI or via tools like dig or nslookup. Only IP addresses are shown, and reverse lookups result in NXDOMAIN unless the device is explicitly hardcoded via a local DNS record. Prior to the upgrade, everything resolved normally, with hostnames correctly pulled from pfSense (which handles all static DHCP assignments).

Despite hardcoding all DHCP mappings in pfSense, Pi-hole seems unable to retrieve or display these hostnames properly anymore. The new client overview page correctly detects MAC vendors, indicating some level of network awareness — but hostnames remain absent or broken.

Details about my system:

Pi-hole v6.1 (FTL v6.1)
Running in a standalone Linux container
DNS backend: Unbound on pfSense
pfSense configured with all static DHCP mappings (no dynamic leases)
All clients point to Pi-hole for DNS (with pfSense as the upstream via reverse forwarding)
Network is fully functional and ad-blocking is still working correctly
Previously functioning hostname resolution broke immediately after upgrading from Pi-hole v5.x

What I have changed since installing Pi-hole:
Upgraded from Pi-hole v5 to v6.1 via pihole -up
No changes to pfSense
Attempted full repair using pihole -r
Verified Unbound configuration is correct and includes dhcpleases_entries.conf
Tried restarting Pi-hole, FTL, and Unbound multiple times
Hostname resolution still fails unless entries are manually added to "Local DNS Records"

image
image1045×506 26.9 KB

2

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:

pihole -d

or if you run your Pi-hole as a Docker container:

docker exec -it <pihole-container-name-or-id> pihole -d

where you substitute <pihole-container-name-or-id> as required.

3

Debug Token is
https://tricorder.pi-hole.net/URfUJcD8/

4

Your debug log shows your Pi-hole is aware of 4 local DNS records.

     hosts = [
       "192.168.1.10 openvpn.your.domain",
       "192.168.1.1 pfsense.your.domain",
       "192.168.1.132 tweaked.your.domain",
       "192.168.1.6 victoria.your.domain"
     ] ### CHANGED, default = []

All other local names are sourced from 192.168.1.1 (pfsense) via Conditional Forwarding

     revServers = [
       "true,192.168.1.0/24,192.168.1.1,your.domain"
     ] ### CHANGED, default = []

Let's see how your pfsense answers DNS requests.
Please share the result of:

nslookup esxi.your.domain 192.168.1.1

Substitute your.domain with your actual domain as required.
You may also for other names than esxi that you expect your pfsense to know.

Similar can be done for reverse lookups

nslookup 192.168.1.3 192.168.1.1

Try different IPs that you expect your pfsense to know by substituting 192.168.1.3 as required.

5

the 4 it knows are the manual ones I put into pihole when I do the nslookup's I get

pfSense."mydomain.com" can't find esxi."mydomain.com": Non-existent domain

and

pfSense."mydomain.com" can't find 192.168.1.3: Non-existent domain

Just to clarify and help eliminate any ambiguity no changes were made to pfSense the problem only began after running a routine pihole -up to upgrade to v6. My DHCP mappings in pfSense are all static and hard-coded; I do not use leases. Unbound is properly configured and includes /var/unbound/dhcpleases_entries.conf, but that file is currently blank or not being generated, despite dozens of static mappings being present. Manually added DNS entries in Pi-hole resolve just fine, which confirms that DNS itself is functional. Conditional forwarding to pfSense (192.168.1.1) is configured and unchanged, yet when using nslookup directly against pfSense, such as nslookup esxi.mydomain.com 192.168.1.1, the result is NXDOMAIN, even though the host is defined in pfSense. This exact same setup worked perfectly before the Pi-hole v6 upgrade. Based on all of this, it seems like something changed either within Pi-hole v6 itself or in the way it interfaces with upstream resolvers like pfSense.

6

Your nslookup results would demonstrate that your pfsense does not know how to resolve neither 192.168.1.3 nor esxi.mydomain.com, provided that you did substitute mydomain.com for your actual domain.

To rule out that only those specific values are affected, you could try to run nslookups for other names and IPs that you'd expect your pfsense to know about.

If they'd all come back with NXDOMAIN, then you'd have to investigate why your pfsense won't populate its DNS records as you expect it to.

7

I did substitute in my actual domain when testing, and I confirmed that the entries I used (like esxi.mydomain.com and 192.168.1.3) are indeed defined in pfSense under static DHCP mappings.

I also ran additional nslookup tests against other IPs and hostnames that I know are statically mapped in pfSense, and unfortunately, they all return NXDOMAIN as well. This confirms that it’s not just isolated to one or two entries pfSense itself is no longer responding with DNS entries for any of the static mappings.

Given that nothing has changed on the pfSense side and the only variable was the Pi-hole v6 upgrade, this seems to point to either a new requirement in how Pi-hole interfaces with upstream DNS resolvers or possibly an unintended regression. I’m happy to dig deeper just let me know what would help most.

I also want to add that my second Pi-hole that I did not update yet is still working just fine and grabbing the info even after I flushed the tables and the logs

8

This isn't a Pi-hole issue:
Those nslookups were sent directly to your pfsense at 192.168.1.1, which has answered them with NXDOMAIN, demonstrating that your pfsense's internal DNS server does not hold the requested DNS records.
This is the same reply that Pi-hole's Conditional Forwarding would receive.

If that file is blank, then unbound would have no chance of knowing local hostnames as presented by DHCP clients during lease negotiation.

DHCP servers are not required to register hostnames with a colocated DNS server.

I take it that unbound is your pfsense's internal DNS server?

If so, what process is responsible for populating dhcpleases_entries.conf from your DHCP server's lease information?

9

Yes, Unbound is pfSense’s internal DNS server in this setup. The /var/unbound/dhcpleases_entries.conf file is normally auto-populated based on static DHCP mappings defined under Services > DHCP Server in the pfSense GUI. These entries are not leases every device listed has a hard-coded MAC-to-IP mapping set manually.

Prior to the Pi-hole v6 upgrade, this file was being properly generated, allowing Unbound (and Pi-hole via conditional forwarding) to resolve local hostnames just fine. Nothing on the pfSense side has changed: same static mappings, same Unbound config, same include directive in unbound.conf. But now the dhcpleases_entries.conf file is blank or missing after a reboot or Unbound restart.

If pfSense is indeed responsible for populating that file, then something appears to be preventing it from doing so. That’s what led me to suspect a change in how Pi-hole queries or interprets upstream results, but perhaps it’s instead related to a change in how pfSense interacts with Unbound or how Unbound processes those static mappings now.

Happy to investigate further from the pfSense side too if anyone has pointers on what process is meant to populate that file or how to verify whether it’s failing silently.

Also as I stated before my second Pi-Hole server that is not updated yet is working just fine and getting the names.

10

Hey just a quick follow-up, I think I may have found something that could be part of the issue. I’ve been digging deeper and noticed that on pfSense I’m using Kea as the DHCP backend (which is the default now), and apparently Kea doesn’t populate the /var/unbound/dhcpleases_entries.conf file at all.

From what I understand, Pi-hole when using conditional forwarding relies on the upstream resolver (pfSense in this case) to know local hostnames, and Unbound needs that file to answer those correctly. But since it’s either blank or not getting generated at all, I’m guessing that’s why I keep getting NXDOMAIN even though the mappings are all there in pfSense.

So maybe the update to Pi-hole v6 didn’t break anything directly, it might’ve just made the lack of that file more noticeable, especially after flushing the cache and adding new devices.

Let me know if this sounds like it tracks or if I’m missing something.

11

Yes, as explained before, this isn't a Pi-hole issue.

As unbound is your pfsense's DNS server, and its /var/unbound/dhcpleases_entries.conf is empty, you'd have to investigate which process on your pfsense would be responsible for populating that file, and fix that.

12

After going through everything in pfSense, I checked all the files like /var/unbound/dhcpleases_entries.conf, /etc/dhcpd.conf, and the config.xml to make sure the static mappings were correct. I also made sure my DHCP settings were set up right, and I tested both Kea and ISC DHCP servers, but I still couldn’t get Pi-hole to resolve the client names.

So, I decided to do a fresh install of pfSense and restore from a backup. I reinstalled the Unbound and Kea DHCP services to make sure everything was in good shape. After the fresh install and rebooting everything, Pi-hole started resolving the client names properly. Even with Kea still in use, it started picking up the static mappings and leases.

It seems there was something in the pfSense config that wasn’t right, and the reinstall fixed it. Everything is working great now, and Pi-hole is resolving names as expected.

13

This topic was automatically closed 21 days after the last reply. New replies are no longer allowed.