Local hostnames not resolving

Help
1

Expected Behaviour:

I want to resolve local hostnames using dnsmasq. This is working using DNS on the router, but not from Pi Hole. DHCP is provided by the router, with three name servers: Pi Hole is first, then OpenDNS as backup. Pi Hole is running on Ubuntu, and upstream DNS is set to my router.

Actual Behaviour:

Below is output from a macOS client, but the results are exactly the same running on the Pi Hole machine itself.
192.168.4.2 is the Pi Hole
192.168.4.1 is the router
192.168.4.3 is a machine named Designare

% nslookup Designare 192.168.4.2
Server:		192.168.4.2
Address:	192.168.4.2#53

Non-authoritative answer:
*** Can't find Designare: No answer

% nslookup Designare 192.168.4.1
Server:		192.168.4.1
Address:	192.168.4.1#53

Name:	Designare
Address: 192.168.4.3

The contents of /etc/resolv.conf on the Pi Hole:

# Generated by dhcpcd from enp4s0.dhcp
# /etc/resolv.conf.head can replace this line
nameserver 192.168.4.2
nameserver 208.67.222.222
nameserver 208.67.220.220

I have tried pihole restartdns to clear the cache. The query log shows:

10:56:33: query[A] Designare from 192.168.4.5
10:56:33: config Designare is NODATA-IPv4

Debug Token:

https://tricorder.pi-hole.net/z831kvvqvl

2

Don't do this. There is no reliable concept of "backup". Given multiple DNS servers, clients are free to use any of them, which will lead to some DNS traffic bypassing Pi-hole.

How is Pi-hole aware of this domain name mapping to a local IP? Typically this is done in a local hosts file entry or by using Local DNS records in Pi-hole admin GUI. Example from my network (the commands are run from the Pi, but the answer is the same regardless of which client makes the dig request).

cat /etc/hosts
127.0.0.1   localhost nanopi-neo
::1         localhost nanopi ip6-localhost ip6-loopback
fe00::0     ip6-localnet
ff00::0     ip6-mcastprefix
ff02::1     ip6-allnodes
ff02::2     ip6-allrouters

127.0.1.1	NanoPi
192.168.0.1	Airport-Extreme-3TB
192.168.0.2	TC-Extreme-3TB-extender
192.168.0.90	Sonos-Beam

From any connected client, the answer is as follows:

dig sonos-beam +short
192.168.0.90
3

Thanks for your suggestion. The reason I like the backup is in case my Pi Hole server crashes or goes down for maintenance. I haven't fully researched "backup DNS" behavior on different operating systems, but so far my Mac clients seem to be always using the Pi Hole. For a blocked domain Pi Hole returns 0.0.0.0 which points to localhost on the Mac. I will test further and try to see under if there is any scenario where it doesn't work.

Since Pi Hole upstream DNS is set to the router (192.168.4.1), I expected it should send the Designare request there, is that how it works? The router is able to resolve it automatically because of its dnsmasq setting, as you can see from my output before. This should be a lower maintenance solution instead of manually editing the hosts file.
(It's an EdgeRouter-X)

The query log in the admin webpage shows the request is OK (cached), even though I have just restarted Pi Hole DNS. Not sure why.

4

As noted, this isn't a backup, it's a bypass. You might get lucky with Mac clients, they tend to stick pretty hard to the first server listed.

A reliable method is to run two Pi-holes in parallel and list them both as DNS servers. All DNS traffic goes to a Pi-hole and either can fail with zero network impact.

Maybe. If you have Pi-hole configured to not forward local domains to the upstream server, it won't do this.

See web admin GUI > Settings > DNS > Advanced DNS settings.

5

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