What is the CORRECT way to get local hostname resolution without pihole as DHCP?



I run pihole on my rpi 3; it works great! For a variety of reasons I don’t use it as DHCP server. I get pretty spotty hostname resolution to local devices, I don’t know why! Some of the time I can ping devices on my network using FQDN (or simply hostname), including pi.hole, other times it doesn’t work.

I’ve tried changing settings in the pi’s /etc/hosts, /etc/dnsmasq.d/01-pihole.conf, /etc/pihole/local.list /etc/dnsmasq.d/localhost.conf, /etc/dnsmasq.conf, /etc/pihole/lan.list, etc. I flush the DNS on my machine (and the relevant services on the pi) and have had some success; but a few hours later it stops working.
I can always ping the local devices from the pi-hole itself, of course.

So I ask: on a brand-new pi-hole, that isn’t a DHCP server, what is the correct way to have DNS clients discover local hostnames (with or without FQDN)?



As an example, I just got it to work again by doing:

sudo pihole -a hostrecord [hostname]

But I’m sure it’ll stop working again, later.


This is done on the Pi in file /etc/hosts. If you have a printer, for example, the line entry in the /etc/hosts file could be: Printer

Note that for this to be correct, your DHCP names have to be reserved (or static) from the router.


That is the very first thing I did. I use static reservations. I can of course ping from the pi.

It works on the clients… Until it doesn’t. I’ll see if it’s something else on my client.


The method I use is described here section Q/A - “Why so many local requests?”.
I’ve been using this for over a year now, pihole is NOT involved in this, I simply use a dnsmasq feature (does also work with pihole-FTL - pihole 4.0).

For this to work, you need to:

  • have static DHCP addresses (using the MAC address) configured on the router (or whatever you use to provide DHCP)
  • have a domain configured in your router.
    I use pfsense, the domain is configured under system / general setup / domain. A lot of routers allow you to specify a domain, this will be distributed, using DHCP, to all clients.

On windows, You can verify you have a domain name by using “ipconfig /all”, look for
“DNS Suffix Search List. . . . . .”

The solution works with ipconfig and nslookup:

ping y50

Pinging y50.localdomain [] with 32 bytes of data:
Reply from bytes=32 time=1ms TTL=128
nslookup y50
Server:  raspberrypi.localdomain

Name:    y50.localdomain

reverse lookup:

Server:  raspberrypi.localdomain

Name:    y50.localdomain


My Ubiquiti USG adds the .local suffix for my domain. I use static reservations from the USG.
I am using Ubuntu 18.04 on my laptop, and have tried adding my domain suffix (which I shouldn’t need - before the pihole, the USG appended the suffix automatically to any DHCP clients).

As of now, nslookup is showing the correct results, and I’m able to ping from my laptop… but from my mobile phone, I have to disconnect/reconnect my wifi connection to get to pi.hole - every time.

I might be looking at a problem outside the pi-hole; but I appreciate the help!


Hey guys. I was gone for a while; returned and saw that although any device with the .local suffix is browsable from my laptop, pi.hole still does not resolve! The /etc/hosts file on the pi-hole looks like: localhost
::1 localhost ip6-localhost ip6-loopback
ff02::1 ip6-allnodes
ff02::2 ip6-allrouters pi.hole yochai-server pi.hole

As you can see, the custom entries are at the bottom (I even appended the static IP of the device, though I don’t think it’s needed). My server is pingale with the .local suffix, but alas, nothing at pi.hole.

Very frustrating when I want to modify the web UI (though I can obviously still use the IP).


Are you sure that device is actually using Pi-hole and can reach it via IP address? You might have multiple DNS servers in use.


Of course. I can reach it by IP, and it is using the pi-hole as a DNS server. It just doesn’t consistently reach pi.hole (as opposed to the IP).


Check that Pi-hole is the only DNS server. Having inconsistent access to pi.hole is indicative of having multiple DNS servers in use.


It absolutely is. My devices (Ubuntu, OS X and Android respectively) all receive the pi.hole as the sole DNS provider from my Ubiquiti USG.


In some cases, intermittent performance problems are indicative of a hardware problem. What power supply are you using for your Pi, what card brand, and how do you have the Pi connected to the network?


What is the output of nslookup pi.hole?


If that were the case I’d see other issues. Ad-blocking works perfectly, and I’m seeing no network issues (drops, ping/traceroute tests, etc)
The thing is, it’s resolving now, so nslookup is resolving as it should. Other times it does not resolve (but everything else works properly).

:zap: nslookup pi.hole



Non-authoritative answer:

Name: pi.hole


Name: pi.hole

Address: fe80::a565:22f0:3710:1c06

And google:

:zap: nslookup google.com



Non-authoritative answer:

Name: google.com


Name: google.com

Address: 2607:f8b0:4006:80f::200e

The server address is listed as localhost, but that’s because of Ubuntu’s systemd.


When it’s not resolving correctly, share the nslookup output (and dig pi.hole if that’s available).


@op - How is your router configured to use pi-hole’s IP as the DNS? See: Pi-hole and ddwrt settings


It uses for itself, and hands out the pihole ip for DNS through DHCP.

That said, I think I fixed it. In my previous configuration, I had the router handing out the pihole as the primary DNS, and then (without much thought) I had set the secondary and tertiary DNS servers as and

A few days ago, I realized this was superfluous, and removed them, leaving only the primary. Since then I have had no problems with local hostname resolution, and my mobile ads were more consistently being blocked! It likely affected my Linux machines as well, but I wouldn’t have noticed because they have adblockers. It’s strange, though - pihole was definitely blocking (I had to frequently whitelist domains for my wife’s work) before these changes.

So I think I’m ok now - thanks for your help, everyone! And Graysky, see you in Archland.