Static DNS entries are not getting resolved

[vladk2k]

Expected Behaviour:

Local hosts listed in /etc/hosts file, /etc/dnsmasq.d/XX.conf file, or added through pihole -a hostrecord ... should resolve when queried by systems that use pihole as its DNS server

Actual Behaviour:

Only local hosts configured through DHCP (and pi.hole) are resolved, all others are served with 'no such name' / 'no such domain'

Debug Token:

https://tricorder.pi-hole.net/5weyfp6ywn

Details

I have Pi-hole running on my network as DHCP and DNS server. Its hostname is raspberrypi, at address 192.168.10.14 and internet connectivity is achieved with a router at address 192.168.10.1.
Local hostname resolution works fine for queries related to DHCP-served hosts (e.g. my computer receives 192.168.10.2 from Pi-hole and when I request DNS resolution for its hostname from another computer, Pi-hole replies with that address), also pi.hole is resolved correctly.
However, I want to have name resolution for my box and also for my router (so that I can navigate to http://router instead of http://192.168.10.1). I tried several approaches:

• Adding entries into hosts file
• Creating a separate file for dnsmasq: /etc/dnsmasq.d/10-static-entries.conf
• Adding hostrecord with pihole -a hostrecord router,192.168.10.1

The DNS requests work flawlessly on the Raspberry pi shell. However, all other machines on the network are served with "Non-existent domain" when I try to resolve:

> router
Server:  raspberrypi
Address:  192.168.10.14

*** raspberrypi can't find router: Non-existent domain

Output in /var/log/pihole.log

Jan 12 10:07:35 dnsmasq[968]: query[A] router.local from 192.168.10.3
Jan 12 10:07:35 dnsmasq[968]: cached router.local is NXDOMAIN
Jan 12 10:07:35 dnsmasq[968]: query[AAAA] router.local from 192.168.10.3
Jan 12 10:07:35 dnsmasq[968]: cached router.local is NODATA-IPv6

There's also the quite irritating effect that while Windows figures out 192.168.10.14 is raspberrypi (I'm guessing because I also run SAMBA so it gets the name from WINS), actually querying for 'raspberrypi' has the same result:

> raspberrypi
Server:  raspberrypi
Address:  192.168.10.14

*** raspberrypi can't find raspberrypi: Non-existent domain

All requests work from command line on raspberry pi:

> router
Server:         127.0.0.1
Address:        127.0.0.1#53

Name:   router
Address: 192.168.10.1

Jan 12 10:10:31 dnsmasq[968]: query[A] router.local from 127.0.0.1
Jan 12 10:10:31 dnsmasq[968]: cached router.local is NXDOMAIN
Jan 12 10:10:31 dnsmasq[968]: query[A] router from 127.0.0.1
Jan 12 10:10:31 dnsmasq[968]: config router is 192.168.10.1
Jan 12 10:10:31 dnsmasq[968]: query[AAAA] router from 127.0.0.1
Jan 12 10:10:31 dnsmasq[968]: forwarded router to 1.0.0.1
Jan 12 10:10:31 dnsmasq[968]: reply router is NODATA-IPv6

The only difference I see is that when request for router.local fails, nslookup on raspberry pi requests the name of router (no suffix) so that gets a response. BUT I have 'local' configured as domain:

I've read a similar topic here: Cannot ping pihole server. Its hostname "pihole" does not resolve to its static IP address - #19 by DL6ER but I didn't want to revive a 2 years old thread. Also, the resolution there (put static entries in /etc/hosts) does not work in my case.

[DL6ER]

Try to restart your Pi-hole after manually editing /etc/hosts:

pihole restartdns

to have to re-read the HOSTS file. The local lookups work fine as the Rasperry Pi can lookup the name in it's HOSTS file even when Pi-hole itself is not aware of the entry (yet).

[Bucking_Horn]

It would seem you are using a domain name of local under DHCP settings and have set Never forward non-FQDNs under DNS settings.

That would enforce the use of FQDN names (like router.local).
EDIT: But only on fowarding those requests, so may not apply to your situation.
You could still try and see if disabling Never forward non-FQDNs under DNS settings makes any difference.

You may also want to consider chosing a different domain name, as .local is the default suffix for mDNS services (like Bonjour) used e.g. by Apple devices as alternate local name resolution service and may provoke unwanted behaviour if you use Apple devices on your network.