I have a strange issue with hostname resolution. I'm running the latest beta version of Pi-hole and I have a Unifi Dream Machine as my router also acting as my DHCP.
It seems Pi-hole is resolving hostnames in a way that I don't understand. On my old router and Pi-hole 4.4 I used the etc/hosts file to get hostnames to show right. With my UDM I was able to get conditional forwarding working. I have 2 networks on my router that I have pointing to the Pi-hole. On the UDM I have given these domain names of home and iot. I added these to the Custom DNS/Local Host Names list in Pi-hole 5.o and everything seemed to be working fine. I have a few devices that have actual hostnames that don't help me much so I added these to my etc/hosts file with better hostnames.
Now things get weird. I decided to rename my domains on my router to home.local and iot.local. I also changed the Custom DNS/Local Host Names to reflect this. I did this and restarted DNS on my Pi-hole but it wasn't recognizing the new domain names. I even restarted the Pi-hole but no dice. I then decide to comment out one of the entries in etc/hosts to see what happens and nothing changed on the Pi-hole. It still used the friendly hostname I gave it in the etc/hosts file. It seems Pi-hole is pulling that name from somewhere that I don't know about. I even removed the entries from Custom DNS/Local Host Names and it's still getting hostnames from somewhere.
Pi-hole is considering hostnames from a few additional sources you might not yet be aware of.
You may check documentation for dnsmasq for details, which is the DNS/DHCP server embedded in pihole-FTL. Pi-hole adds a few defaults to this,
Let's quickly browse through the most likely locations..
You can check your pihole-FTL configuration for additional hosts files considered by:
grep -nR "addn-hosts" /etc/dnsmasq.d/
I'd expect that to bring up local.list at least, and custom.list wouldn't be unusual as well.
Similarly, in case you might have manually provided host records for local resolution, you should be able to track them down by:
grep -nR "host-record" /etc/dnsmasq.d/
If you have used /etc/ethers to define MAC address to hostname associations, those may also have been considered.
And if you were running Pi-hole as DHCP server (which your debug log says you currently don't), pihole-FTL would also consider hostnames as provided during DHCP lease negotiation.
Edit:
Finally, you may see additional local hostname resolution if you'd be using your router (or DHCP or separate local DNS server, respectively) as Pi-hole's only upstream DNS server (again, your debug log shows that not to be the case).
The results of those commands didn't turn up anything unexpected and didn't show me that those hostnames are resolving in those places. I have now cleared my etc/hosts file completely and restarted DNS the Pi-hole itself and it's still pulling those names.
My UDM lets me rename my devices and give it an "alias" so it's more recognizable in the event logs and such. Would it be pulling those names? Does anyone have any experience with Unifi stuff that might know? It's weird because that record should show up with an iot.local domain to match what's configured in DHCP on my UDM.
Yeah I thought those aliases were just used for internal Unifi use.
Anyway, Pi-hole is somehow resolving hostnames and I have no idea how. I've removed any conditioanal forwarder or custom DNS settings. I've cleared my etc/hosts file. There is no extra conf. file in /etc/dnsmasq.d/ that has any hostname settings. I've checked custom.list and local.list and they aren't in there.
You could try setting DEBGUG_ALL=true in /etc/pihole/pihole-FTL.conf restart pihole and check /var/log/pihole-FTL.log. I'm sure pihole logs how it resolves hostnames...
That's actually not a hostname per se, but a local domain or search suffix.
pihole-FTL would use the search suffix as acquired by its DHCP lease and by what's defined on the system it runs on. Commonly, a search suffix would be locally supplied via entries in /etc/resolv.conf or the likes.
That still leaves to explain where Pi-hole gets that firetv-livingroom hostname from.
@yubiuser suggested using a sledge-hammer to crack a nut. You should already get what you need just by looking at /var/log/pihole.log
Examples:
Apr 29 20:54:33 dnsmasq[9504]: query[A] ubuntu-server from 127.0.0.1
Apr 29 20:54:33 dnsmasq[9504]: /etc/hosts ubuntu-server is 127.0.1.1
Apr 29 20:55:04 dnsmasq[9504]: query[A] pi.hole from 127.0.0.1
Apr 29 20:55:04 dnsmasq[9504]: /etc/pihole/local.list pi.hole is 192.168.2.10
You see the source of truth in front of the address in the second line. When it says config, it has been hard-wired in some config file (likely in /etc/dnsmasq.d).
The client at IP 192.168.10.129 is looking for the IP of this domain.
You are forwarding this query for a local domain name to the upstream DNS servers. They don't know the answer (since the domain is local to your network) and return NXDOMAIN.
On the web GUI, settings > DNS > Advanced DNS, are either of these check boxes selected?
Check them both. This will keep local requests local.
You are going to have to locally map firetv-livingroom.home.local for the Pi-hole to be able to resolve it. The client will keep requesting it until it gets an answer.
