DNS hostname resolution in the Pi-Hole console

Help
1

Please follow the below template, it will help us to help you!

Expected Behaviour:

All clients DNS names should be listed in Top Clients

Actual Behaviour:

  • only some are, and the rest are IP addresses.

Debug Token:

There was no useful info (to me) in the debug.

Describing the issue so far - I have pi-hole running successfully on my network in a Xen VM on Ubuntu 16.04. It's DNS and DHCP server. Upstream DNS works fine. Clients get ads blocked just fine, including android devices (even in-game ads most times). Internet browsing is legit snappier on my whole network.

What I am seeing on the admin console is that SOME of the devices are reporting DNS properly and resolving on the Top Clients list. My Sony smart-tv (Android under the hood) has been resolving right with no fiddling. A couple machines I have on static IPs that initially were not resolving right and were manually added to the pi-holes local hosts file are now resolving correctly. But anything that's getting a DHCP address is NOT resolving in the clients. And that's mostly Linux Mint laptops or a couple phones (androids and an iPad).

It's at this point I'm not sure where I'm missing something. The DHCP clients have correct information in their hosts files, but I know phones will report their DNS name (it happens all the time in the Windows DHCP scope for wifi at work) so I'm not sure what's missing in pi-hole to get it resolving right.

Thanks!

2

I agree, this should work. Please run

dig -x 192.168.1.2 +short

on one of your machines (e.g. the Mint laptop) and on your Pi-hole. Replace 192.168.1.2 by the IP address of any device where the name resolution does NOT seem to work right now. Please try also an IP address for which name resolution works.

3

Sorry for the wall of text - the +short option produced zero result for the .113 address on either machine. (It's my android phone, FYI) The laptop in question (.108) is resolving right.

FROM LAPTOP

rich@rich-t420 ~ $ dig -x 192.168.1.113

; <<>> DiG 9.9.5-3-Ubuntu <<>> -x 192.168.1.113
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 51045
;; flags: qr aa rd ra ad; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 1280
;; QUESTION SECTION:
;113.1.168.192.in-addr.arpa. IN PTR

;; Query time: 2 msec
;; SERVER: 127.0.1.1#53(127.0.1.1)
;; WHEN: Thu Feb 08 15:51:27 CST 2018
;; MSG SIZE rcvd: 55

rich@rich-t420 ~ $ dig -x 192.168.1.108

; <<>> DiG 9.9.5-3-Ubuntu <<>> -x 192.168.1.108
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 8762
;; flags: qr aa rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 1280
;; QUESTION SECTION:
;108.1.168.192.in-addr.arpa. IN PTR

;; ANSWER SECTION:
108.1.168.192.in-addr.arpa. 2 IN PTR rich-t420.local.

;; Query time: 10 msec
;; SERVER: 127.0.1.1#53(127.0.1.1)
;; WHEN: Thu Feb 08 15:51:57 CST 2018
;; MSG SIZE rcvd: 84

rich@rich-t420 ~ $

FROM Pi-HOLE

rich@pi-hole:~$ dig -x 192.168.1.113

; <<>> DiG 9.10.3-P4-Ubuntu <<>> -x 192.168.1.113
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 47055
;; flags: qr aa rd ra ad; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 1280
;; QUESTION SECTION:
;113.1.168.192.in-addr.arpa. IN PTR

;; Query time: 0 msec
;; SERVER: 127.0.0.1#53(127.0.0.1)
;; WHEN: Thu Feb 08 15:51:24 CST 2018
;; MSG SIZE rcvd: 55

rich@pi-hole:~$ dig -x 192.168.1.108

; <<>> DiG 9.10.3-P4-Ubuntu <<>> -x 192.168.1.108
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 50517
;; flags: qr aa rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 1280
;; QUESTION SECTION:
;108.1.168.192.in-addr.arpa. IN PTR

;; ANSWER SECTION:
108.1.168.192.in-addr.arpa. 2 IN PTR rich-t420.local.

;; Query time: 0 msec
;; SERVER: 127.0.0.1#53(127.0.0.1)
;; WHEN: Thu Feb 08 15:52:26 CST 2018
;; MSG SIZE rcvd: 84

rich@pi-hole:~$

4

Okay, so this is what I was expecting. Can you run a tail on the log on your Pi-hole while you repeat the request from some other machine?

pihole -t
5

Relevant lines

Feb 8 16:27:26 dnsmasq[25906]: query[PTR] 113.1.168.192.in-addr.arpa from 192.168.1.108
Feb 8 16:27:26 dnsmasq[25906]: config 192.168.1.113 is NXDOMAIN
Feb 8 16:27:28 dnsmasq[25906]: query[PTR] 108.1.168.192.in-addr.arpa from 192.168.1.108
Feb 8 16:27:28 dnsmasq[25906]: DHCP 192.168.1.108 is rich-t420.local

6

.113 definitely has a DHCP lease from my pi-hole, FYI.

7

Can you grep for DHCP in your log?

grep 'DHCP' /var/log/pihole.log

You should see something like

Feb  9 09:20:25 dnsmasq-dhcp[32479]: DHCPREQUEST(eth0) 192.168.1.113 d0:50:99:vv:bb:aa 
Feb  9 09:20:26 dnsmasq-dhcp[32479]: DHCPACK(eth0) 192.168.1.113 d0:50:99:vv:bb:aa desktop

telling you that a DHCP lease was requested and handed out.

Please also note that just defining static DHCP leases isn't sufficient for name resolution. They are only activated after this client has actively requested a lease from the server (to avoid being able to resolve names that aren't present on the network!).

Does it say at some place that it handed out a DHCP release? Just to be sure (as you didn't post a debug log): Are you using Pi-hole's DHCP server or are you just using another DHCP server (like isc) on the same machine? I assume the former, but want to be sure.

8

I'm not using any other DHCP service other than pi-hole.

Logs as requested. Though I'm honestly not sure why it's requesting so often. Leases are set to 72 hours and the phone has been in range and connected the whole time. Maybe Android 8.1 is dropping the wifi and only re-connecting it when needed?

rich@pi-hole:/var/log$ grep 'DHCPREQUEST(eth0) 192.168.1.113' pihole.log
Feb 9 03:55:05 dnsmasq-dhcp[25906]: DHCPREQUEST(eth0) 192.168.1.113 my mac address
Feb 9 08:49:00 dnsmasq-dhcp[25906]: DHCPREQUEST(eth0) 192.168.1.113 my mac address
Feb 9 09:03:02 dnsmasq-dhcp[25906]: DHCPREQUEST(eth0) 192.168.1.113 my mac address
Feb 9 09:04:13 dnsmasq-dhcp[25906]: DHCPREQUEST(eth0) 192.168.1.113 my mac address
Feb 9 09:07:10 dnsmasq-dhcp[25906]: DHCPREQUEST(eth0) 192.168.1.113 my mac address
Feb 9 09:08:16 dnsmasq-dhcp[25906]: DHCPREQUEST(eth0) 192.168.1.113 my mac address
Feb 9 09:09:05 dnsmasq-dhcp[25906]: DHCPREQUEST(eth0) 192.168.1.113 my mac address
Feb 9 09:10:21 dnsmasq-dhcp[25906]: DHCPREQUEST(eth0) 192.168.1.113 my mac address
rich@pi-hole:/var/log$ grep 'DHCPACK(eth0) 192.168.1.113' pihole.log
Feb 9 03:55:05 dnsmasq-dhcp[25906]: DHCPACK(eth0) 192.168.1.113 my mac address
Feb 9 08:49:00 dnsmasq-dhcp[25906]: DHCPACK(eth0) 192.168.1.113 my mac address
Feb 9 09:03:02 dnsmasq-dhcp[25906]: DHCPACK(eth0) 192.168.1.113 my mac address
Feb 9 09:04:13 dnsmasq-dhcp[25906]: DHCPACK(eth0) 192.168.1.113 my mac address
Feb 9 09:07:10 dnsmasq-dhcp[25906]: DHCPACK(eth0) 192.168.1.113 my mac address
Feb 9 09:08:16 dnsmasq-dhcp[25906]: DHCPACK(eth0) 192.168.1.113 my mac address
Feb 9 09:09:05 dnsmasq-dhcp[25906]: DHCPACK(eth0) 192.168.1.113 my mac address
Feb 9 09:10:21 dnsmasq-dhcp[25906]: DHCPACK(eth0) 192.168.1.113 my mac address

9

Yes, it does that as long as you don't specify that it should keep WiFi on all the time to save battery.

So it shows only

Feb 9 03:55:05 dnsmasq-dhcp[25906]: DHCPACK(eth0) 192.168.1.113 my mac address

but there is no host name behind the MAC address?

10

Correct, no name behind the MAC.

11

Did you configure it as a static DHCP lease? If so, did you specify a host name? Just for testing, if you specify it as a static lease (with a host name) and then reconnect it, does it then work?

12

I've configured nothing as static DHCP. Tried it and it hasn't registered the name as yet, though it's only been a few minutes.

Ideally, I don't want to and shouldn't have to do this for each device. That's the beauty of DHCP, not having to manually manage things like this.

13

I know and this is how it works also here: Nothing defined as fixed, still everything is working.

So far, I'm guessing that this particular device (192.168.1.113) that queried a DHCP lease did not tell the DHCP server any host name, so it also registered none. My idea was now that when you create a static lease with a given host name, it would use this one instead. If it is a WiFi device, try turning the WiFi connection off and again on to renew the lease from the DHCP server.

14

OK. Couple annoying things here. The phone does NOT report DNS name. I set one as 'static dhcp' (being able to not set the IP address is a nice option in pi-hole, just the hostname and MAC) and it reports fine now. I suppose I'll have to do the same for the couple of devices that also do this. I'd rather tweak the setting in Android 8.1 to report hostname, but apparently that's a root only 'feature'.

Thanks for your help diagnosing this! It's appreciated!

1 Like
15

Okay, thanks for finding that out! My newest Android device is Android 7 and there they always report themselves with android-qegf7w9e8f6bwq98e7f6 or something similar.

Yeah, I coded this for the case of such long and not very useful host names to be able to rename them to e.g. android-tablet. So you can use that also to name them if they don't report a host name. Glad we found a solution for you!

16

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