Cannot ping pihole server. Its hostname "pihole" does not resolve to its static IP address

Help
1

Expected Behaviour:

The hostname of the Raspberry Pi running the pihole service is pihole (192.168.1.2). If I ping pihole from a Windows 10 PC it should reply.

Actual Behaviour:

Ping request could not find host pihole. However, if I ping pi.hole it succeeds. Unlike "pihole", "pi.hole" is resolved correctly.

I read the following thread carefully and my configuration appears to be the same as in the thread except for the very last part where the host pihole command should return 192.168.1.2. In my case it returns 127.0.1.1

My results are as follows:

$ cat /etc/hostname
pihole

$ hostname; hostname -s; hostname -f
pihole
pihole
pihole

$ cat /etc/hosts
127.0.0.1       localhost
::1             localhost ip6-localhost ip6-loopback
ff02::1         ip6-allnodes
ff02::2         ip6-allrouters
127.0.1.1       pihole

$ ping pihole
64 bytes from pihole (127.0.1.1): icmp_seq=1 ttl=64 time=0.120 ms

$ cat /etc/resolv.conf
# Generated by resolvconf
nameserver 127.0.0.1

$ sudo grep localise-queries -R /etc/dnsmasq.d
/etc/dnsmasq.d/01-pihole.conf:localise-queries

$ cat /etc/pihole/local.list
192.168.1.2 pihole
192.168.1.2 pi.hole

$ host pihole
pihole has address 127.0.1.1

Based on what I read in the linked thread, "host pihole" should return 192.168.1.2, not 127.0.1.1.

Here are the results for nslookup on the Windows PC:

>nslookup pi.hole
  Server:  pihole
  Address:  192.168.1.2

  Name:    pi.hole
  Address:  192.168.1.2


>nslookup pihole
  Server:  pihole
  Address:  192.168.1.2

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

How do I fix this?

Other than that, the Pihole service itself works like a charm and, besides blocking unwanted ads, has helped me identify exceeding chatty devices on my network (and silence them, wherever possible).

Be advised that if you have any speakers employing technology from LinkPlay, they contact baidu.com and sina.com.cn every few seconds (the mobile apps designed to control these speakers behave in the same manner). The speaker's configuration offers no way to stop this behavior. I have blacklisted the two sites but now I normally leave the speaker off to prevent it from overwhelming Pihole's daily logs (and polluting the statistics).

2

The host result is no issue. For me it shows the same:

$ host raspberrypi
raspberrypi has address 127.0.1.1
raspberrypi has IPv6 address fda2:2001:....

From another device, name resolution works just fine:

$ dig +short raspberrypi
192.168.2.11

$ dig +short pi.hole
192.168.2.11

Please go to your Pi-hole and run

tail -f /var/log/pihole.log

Then go to your Windows machine and run the two nslookup commands again and provide the output generated by tail on your Pi-hole.

3

For nslookup pihole the results are:

Dec 27 11:57:21 dnsmasq[571]: query[PTR] 2.1.168.192.in-addr.arpa from 192.168.1.100
Dec 27 11:57:21 dnsmasq[571]: /etc/pihole/local.list 192.168.1.2 is pihole
Dec 27 11:57:21 dnsmasq[571]: query[A] pihole.local from 192.168.1.100
Dec 27 11:57:21 dnsmasq[571]: cached pihole.local is NXDOMAIN
Dec 27 11:57:21 dnsmasq[571]: query[AAAA] pihole.local from 192.168.1.100
Dec 27 11:57:21 dnsmasq[571]: cached pihole.local is NXDOMAIN

For nslookup pi.hole the results are:

Dec 27 11:59:35 dnsmasq[571]: query[PTR] 2.1.168.192.in-addr.arpa from 192.168.1.100
Dec 27 11:59:35 dnsmasq[571]: /etc/pihole/local.list 192.168.1.2 is pihole
Dec 27 11:59:35 dnsmasq[571]: query[A] pi.hole.local from 192.168.1.100
Dec 27 11:59:35 dnsmasq[571]: cached pi.hole.local is NXDOMAIN
Dec 27 11:59:35 dnsmasq[571]: query[AAAA] pi.hole.local from 192.168.1.100
Dec 27 11:59:35 dnsmasq[571]: cached pi.hole.local is NXDOMAIN
Dec 27 11:59:35 dnsmasq[571]: query[A] pi.hole from 192.168.1.100
Dec 27 11:59:35 dnsmasq[571]: /etc/pihole/local.list pi.hole is 192.168.1.2
Dec 27 11:59:35 dnsmasq[571]: query[AAAA] pi.hole from 192.168.1.100
Dec 27 11:59:35 dnsmasq[571]: cached pi.hole is NODATA-IPv6

I can see there's a difference but I admit I don't understand the results. nslookup pi.hole produces more activity.

Here are my results for "dig":
$ dig +short pi.hole
192.168.1.2
$ dig +short pihole
127.0.1.1

4

I guess (but cannot verify myself) that Windows does not allow domains without a TLD. Hence, it it file with pi.hole (pi is the domain, hole the TLD), but it doesn't like pihole (as there is no . in it). Hence, for pihole it tries only the domain appended by .local.

This may be a technical limitation of Windows you cannot circumvent. Asking @Mcat12 and @PromoFaux for their opinions.

I guess one probabl alternative would be to use the Pi-hole DHCP server as this would make domains like pihole.local queryable as the Pi-hole itself would also manage the host names in the internal network.

5

I agree with @DL6ER's thoughts. Windows is funny about DNS a lot of the time, though you should be able to get to the hostname in a browser without the .local being added on. If you use Pi-hole for DHCP it will correctly handle the .local domains with the default settings.

6

I tried nslookup and ping with another Windows 10 PC and had the same (negative) results.

I don't have any computers running Linux (other than the Raspberry Pi running Pi-Hole) but I do have an old Blackberry Playbook (!). I used it to ping pihole and it was successful. Therefore it supports your theory that the name-resolution problem may be limited to Windows PCs.

These URLs fail to resolve in the browser (MS Edge):
http://pihole.local/admin
http://pihole/admin

However, this works:
http://pi.hole/admin

I appreciate everyone's assistance and will try the suggestion to disable DNS DHCP on my router and enable it on pihole.

7

I disabled DHCP on my router and enabled it on pihole. I added several Static DHCP Leases (same as the ones I had on my router) for the devices on my network.

The first improvement is that now I see hostnames in pihole's Query Log instead of IP addresses. However, the main problem still exists, ping pihole fails on my Windows 10 PC.

Here is what the Query Log shows after I tried to ping pihole twice (from "lux").

Time Type Domain Client Status
2017-12-27 23:10:36 IPv4 pihole.local lux.local OK (forwarded)
2017-12-27 23:12:39 IPv4 pihole.local lux.local OK (cached)

I don't know if it is relevant but if I ping pi.hole (which works) it does not appear in the Query Log.

Here are the results of ipconfig -all on lux. It appears to understand the domain is local.

Ethernet adapter Ethernet:

   Connection-specific DNS Suffix  . : local
   Description . . . . . . . . . . . : Realtek PCIe GBE Family Controller
   Physical Address. . . . . . . . . : xx-xx-xx-xx-xx-xx
   DHCP Enabled. . . . . . . . . . . : Yes
   Autoconfiguration Enabled . . . . : Yes
   IPv4 Address. . . . . . . . . . . : 192.168.1.100(Preferred)
   Subnet Mask . . . . . . . . . . . : 255.255.255.0
   Lease Obtained. . . . . . . . . . : Wednesday, December 27, 2017 10:48:29 PM
   Lease Expires . . . . . . . . . . : Thursday, December 28, 2017 11:01:51 PM
   Default Gateway . . . . . . . . . : 192.168.1.1
   DHCP Server . . . . . . . . . . . : 192.168.1.2
   DNS Servers . . . . . . . . . . . : 192.168.1.2
   NetBIOS over Tcpip. . . . . . . . : Enabled

I don't understand why pihole's IP address cannot be resolved from the Windows PC.

8

I'm having the same problems. Have the system running pi-hole as the dns and the dhcp server. I had setup static addresses for those systems that I do want to be able see the dns name in Pi-Hole and be able to use the dns name for the system running pi-hole in the web page (as will as for the netdata web page).

9

It is hidden by default in the Query Log because otherwise it would be filled with these requests as each time you visit a subpage on the dashboard may generate another entry. Sorry for not having pointed that out earlier!

How do the entries in /var/log/pihole.log look like now that DHCP is handled by the Pi-hole?

Note that this feature does not depend on static leases being set up. In fact, I use not a single static lease on my Pi-hole at home and still can use host names everywhere. Linux machines will tell the DHCP server about how they want to get called when they request an IP address. However, I'm not sure if Win PCs will behave correctly, so I stressed "Linux machines" as I have nothing else for testing (Android works fine as well but it is also Linux under the hood).

10

Now that both DNS and DHCP are served by the pihole server, here is /var/log/pihole.log after pinging pihole from the Windows PC:

Dec 29 10:15:27 dnsmasq[29810]: query[A] pihole.local from 192.168.1.100
Dec 29 10:15:27 dnsmasq[29810]: forwarded pihole.local to 208.67.220.220
Dec 29 10:15:27 dnsmasq[29810]: forwarded pihole.local to 208.67.222.222
Dec 29 10:15:27 dnsmasq[29810]: reply pihole.local is NXDOMAIN

If I understand this correctly, pihole's DNS doesn't know how to resolve pihole.local so it forwarded the request to OpenDNS (resolver2.opendns.com and resolver4.opendns.com). Obviously OpenDNS doesn't know how to resolve pihole.local so its response is NXDOMAIN (Non-Existent Domain).

The pihole server still doesn't know how to resolve its own hostname (pihole).

11

I agree.

What is the content of /etc/pihole/local.list? Maybe running pihole -g can also help after switching to Pi-hole's DHCP server (at least it cannot hurt).

12

Thank you for continuing to assist me with debugging this problem!

Here is the information you requested:
$ cat /etc/pihole/local.list
192.168.1.2 pihole
192.168.1.2 pi.hole

I ran pihole -g and it completed successfully (all green checkmarks) and then I rebooted the Raspberry Pi (pihole). Unfortunately, it did not fix the problem. I still cannot ping pihole from the Windows PC.

I've done more testing, using a Windows 10 PC and a Blackberry Playbook (closest device I have to Linux, other than the Raspberry Pi running Pi-Hole) and discovered the results are not the same for both devices.

1 - Samba magic
First thing I discovered is that if Samba is running on my router (hostname is "router"), then I can successfully ping router from the Windows PC but not from the Playbook. For both cases, pihole's log shows it cannot resolve router.local:

Dec 30 09:58:37 dnsmasq[601]: query[A] router.local from 192.168.1.100
Dec 30 09:58:37 dnsmasq[601]: reply router.local is NXDOMAIN

Therefore, using some mechanism I don't understand, the Windows PC can resolve the hostname "router" when Samba is enabled on the router. It does this independently of pihole's DNS.

I disabled Samba on the router (I don't really need it), rebooted the router, and now "router" cannot be pinged by the Windows PC. Now it behaves more like the Playbook.

2 - Printer magic
Second thing I discovered is that the hostname "printer" can be pinged by the Windows PC even though it cannot be resolved by pihole. The Windows PC's host file does not contain an entry for "printer". Nevertheless, through yet another mechanism I don't understand, it knows how to resolve the printer's name, independently of pihole's DNS. The Playbook fails to ping printer but that's understandable because pihole cannot resolve "printer".

3 - /etc/hosts FAIL
Third thing I discovered, and possibly the most revealing, is that hostnames added to pihole's /etc/hosts, work for DNS queries from the Playbook but not the Windows PC!

I added two hosts, having static IP addresses, to pihole's /etc/hosts file.

192.168.1.4     obi110
192.168.1.5     io

If I ping obi110 from the Playbook, it works. Here is how pihole responds:

Dec 30 11:32:55 dnsmasq[2268]: query[A] obi110.local from 192.168.1.102
Dec 30 11:32:55 dnsmasq[2268]: forwarded obi110.local to 208.67.220.220
Dec 30 11:32:55 dnsmasq[2268]: reply obi110.local is NXDOMAIN
Dec 30 11:32:55 dnsmasq[2268]: query[A] obi110 from 192.168.1.102
Dec 30 11:32:55 dnsmasq[2268]: /etc/hosts obi110 is 192.168.1.4

If I ping obi110 from the Windows PC, it fails. Here is how pihole responds immediately after its DNS service has been restarted:

Dec 30 11:34:46 dnsmasq[2424]: query[A] obi110.local from 192.168.1.100
Dec 30 11:34:46 dnsmasq[2424]: forwarded obi110.local to 208.67.220.220
Dec 30 11:34:46 dnsmasq[2424]: forwarded obi110.local to 208.67.222.222
Dec 30 11:34:46 dnsmasq[2424]: reply obi110.local is NXDOMAIN

Here is how it responds for all subsequent attempts to ping obi110 from the Windows PC:

Dec 30 11:35:25 dnsmasq[2424]: query[A] obi110.local from 192.168.1.100
Dec 30 11:35:25 dnsmasq[2424]: cached obi110.local is NXDOMAIN

How odd is that? Why doesn't it respond like it did for the Playbook?

  1. In the case of the Playbook's query, it is forwarded to OpenDNS, which (obviously) fails to resolve "obi110.local", then pihole responds with the entry from its /etc/hosts file. All subsequent obi110 requests from the Playbook, are handled the same way by pihole

  2. For the Windows PC, pihole never looks in its /etc/hosts file. On the first request it forwards to OpenDNS and responds with NXDOMAIN. For all subsequent obi110 requests from the Windows PC, pihole responds with NXDOMAIN from its cache.

I think the answer to why I can't ping pihole from the Windows PC is in understanding why pihole appears to handle DNS requests from the Windows PC in a different manner (compared to the Playbook). Any ideas?

13

Pi-hole handles each DNS request the same. The issue seems to be in how the clients make the requests.

Playbook requested obi110.local first, then since it didn't get it, it asked for obi110.

Windows requested obi110.local and never asked for obi110.

14

I disagree, Windows just asks a different question that cannot be properly answered (it always appends .local). @Mcat12 said something about Windows's behavior further up.

15

Sorry, I did not mean to make it sound like I was assigning blame to pihole.

If I understand you correctly, pihole responds the same in all cases and the only reason I see a difference is because the two devices aren't making precisely the same requests.

Both ask to resolve obi110.local (which fails to be resolved) but only the Playbook also asks to resolve obi110 (which succeeds to be resolved).

So how do I fix this? Should I modify pihole's /etc/hosts file like this:

192.168.1.4     obi110.local obi110
192.168.1.5     io.local io

Would it help me to resolve the main issue, namely an inability to ping pihole, if I also add this?

192.168.1.2 pihole.local pihole

My only concern is that /etc/hosts already contains this:
127.0.1.1 pihole

Will it cause confusion if "pihole" is known by 127.0.1.1 and 192.168.1.2?

16

You said you are now using Pi-hole for DHCP. What is the domain set in the DHCP settings? By default it is local, so Pi-hole should know the hostname and hostname.local domains of every client. However, check the DHCP leases to see if you need to rename some clients (through a static lease) so that you get the hostnames you want for each client. Then, if obi110 has that hostname, it will have its IP returned for any obi110.local queries. I'm not sure that the DHCP server itself will have the .local domain as well (the Pi-hole), so try adding it alongside pihole in the hosts file. It is not an issue that pihole has more than one mapping.

17

Yes, the domain is the default value, local.

There are seven devices (a mix of Apple, Android, and Windows) with static DHCP leases and all can be successfully pinged from a Windows PC.

The ping-failure is limited to devices with static IP addresses. There are 4 devices with static IP addresses: router, pihole, printer, and obi110.

I added all devices with static IP addresses to the Pi-Hole server's /etc/hosts file. I listed each device with and without its domain name (local).

$ cat /etc/hosts
127.0.0.1       localhost
::1             localhost ip6-localhost ip6-loopback
ff02::1         ip6-allnodes
ff02::2         ip6-allrouters

127.0.1.1       pihole

192.168.1.1     router.local router
192.168.1.2     pihole.local pihole
192.168.1.3     printer.local printer
192.168.1.4     obi110.local obi110

I restarted dnsmasq (for good measure) and then, from the Windows PC, successfully pinged each one of the 4 devices. Progress!

Here's what pihole's log looks like for each pinged device. Nice and clean!

Dec 30 18:07:26 dnsmasq[4947]: query[A] pihole.local from 192.168.1.100
Dec 30 18:07:26 dnsmasq[4947]: /etc/hosts pihole.local is 192.168.1.2
Dec 30 18:07:56 dnsmasq[4947]: query[A] obi110.local from 192.168.1.100
Dec 30 18:07:56 dnsmasq[4947]: /etc/hosts obi110.local is 192.168.1.4
Dec 30 18:08:08 dnsmasq[4947]: query[A] printer.local from 192.168.1.100
Dec 30 18:08:08 dnsmasq[4947]: /etc/hosts printer.local is 192.168.1.3
Dec 30 18:11:05 dnsmasq[4947]: query[A] router.local from 192.168.1.100
Dec 30 18:11:05 dnsmasq[4947]: /etc/hosts router.local is 192.168.1.1

As a final confirmation of proper operation, now I can use http://pihole/admin in my browser to access the Pi-Hole server.

It would appear that all devices with static IP addresses, such as the router and Pi-Hole server, must be listed in the Pi-Hole server's /etc/hosts file in order for them to be "seen" by my Windows 10 PC.

Thank you all for helping me whittle this problem down to a solution.

1 Like
18

Ah, yes. Devices with static IP addresses aren't managed by the DHCP server, so they don't get an automatic .local domain or hostname.

19

I agree, maybe we should put that to some FAQ as many users may be affected (at least their routers will have static addresses) @jacob.salmela

1 Like