Older Macs lookup own address every 15 seconds

Help Community Help
1

I'm using pi-hole 5.0 on a Raspberry Pi with DHCP enabled, on a mostly-Mac network. It's working fine but I'm wondering about some unexpected log entries where some devices look up their own local domain name every 15 seconds.

In a typical entry, a mac named "Pinky" looks up pinky.lan every 15 seconds.

The Macs doing this are running older versions of Mac OS X. One uses 10.7.5, and the other uses 10.13.6. Other Macs don't show this behavior but they're mostly running more recent versions of Mac OS X. There's overlap though, because one Mac running 10.13.6 doesn't do this.

The setup is working fine but these lookups are messing up my logs. The "top permitted domains" are overwhelmingly A record lookups of these two Macs asking for their own address. Also the cache hit percentage is ridiculously high because these requests are of course cached.

I'd love to know why this happens and whether I can do anything to stop it.

Debug Token: https://tricorder.pi-hole.net/c6bfk8fb33

2

What is shown for a query and reply sequence in /var/log/pihole.log?

If the Mac cannot resolve the name, it may continue asking.

One option is to map the domain name to an IP in the /etc/hosts file on the Mac, then the DNS request will be resolved at the Mac and not get to Pi-hole.

3

The log file is several MB so far for today so I won't try to post it all (but I could make a gist if that would help). Here's a representative sample from this morning, showing only requests relating to one of the Macs with this behavior-- "pinky", with address 192.168.1.207. Let me know if other details would be worth posting.

For what it's worth, devices on the network can all resolve pinky.lan correctly.

Jun  8 08:30:06 dnsmasq[584]: query[PTR] 1.0.0.127.in-addr.arpa from 192.168.1.207
Jun  8 08:30:06 dnsmasq[584]: query[PTR] 1.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.ip6.arpa from 192.168.1.207
Jun  8 08:30:06 dnsmasq[584]: query[PTR] 9.a.1.3.f.3.e.f.f.f.3.e.9.1.2.0.b.8.0.0.7.8.8.a.5.7.3.6.6.b.d.f.ip6.arpa from 192.168.1.207
Jun  8 08:30:06 dnsmasq[584]: query[PTR] db._dns-sd._udp.0.1.168.192.in-addr.arpa from 192.168.1.207
Jun  8 08:30:06 dnsmasq[584]: query[PTR] r._dns-sd._udp.0.1.168.192.in-addr.arpa from 192.168.1.207
Jun  8 08:30:06 dnsmasq[584]: query[PTR] dr._dns-sd._udp.0.1.168.192.in-addr.arpa from 192.168.1.207
Jun  8 08:30:06 dnsmasq[584]: query[PTR] lb._dns-sd._udp.0.1.168.192.in-addr.arpa from 192.168.1.207
Jun  8 08:30:06 dnsmasq[584]: query[A] pinky.lan from 192.168.1.207
Jun  8 08:30:06 dnsmasq[584]: DHCP pinky.lan is 192.168.1.207
Jun  8 08:30:08 dnsmasq-dhcp[584]: DHCPREQUEST(eth0) 192.168.1.207 00:19:e3:3f:31:a9 
Jun  8 08:30:08 dnsmasq-dhcp[584]: DHCPACK(eth0) 192.168.1.207 00:19:e3:3f:31:a9 Pinky
Jun  8 08:30:09 dnsmasq[584]: query[PTR] 207.1.168.192.in-addr.arpa from 192.168.1.207
Jun  8 08:30:09 dnsmasq[584]: DHCP 192.168.1.207 is Pinky.lan
Jun  8 08:30:10 dnsmasq[584]: query[A] ocsp.apple.com from 192.168.1.207
Jun  8 08:30:16 dnsmasq[584]: query[PTR] b._dns-sd._udp.0.1.168.192.in-addr.arpa from 192.168.1.207
Jun  8 08:30:16 dnsmasq[584]: query[PTR] db._dns-sd._udp.0.1.168.192.in-addr.arpa from 192.168.1.207
Jun  8 08:30:16 dnsmasq[584]: query[PTR] r._dns-sd._udp.0.1.168.192.in-addr.arpa from 192.168.1.207
Jun  8 08:30:16 dnsmasq[584]: query[PTR] dr._dns-sd._udp.0.1.168.192.in-addr.arpa from 192.168.1.207
Jun  8 08:30:16 dnsmasq[584]: query[PTR] lb._dns-sd._udp.0.1.168.192.in-addr.arpa from 192.168.1.207
Jun  8 08:30:16 dnsmasq[584]: query[PTR] b._dns-sd._udp.lan from 192.168.1.207
Jun  8 08:30:16 dnsmasq[584]: query[PTR] db._dns-sd._udp.lan from 192.168.1.207
Jun  8 08:30:16 dnsmasq[584]: query[PTR] r._dns-sd._udp.lan from 192.168.1.207
Jun  8 08:30:16 dnsmasq[584]: query[PTR] dr._dns-sd._udp.lan from 192.168.1.207
Jun  8 08:30:16 dnsmasq[584]: query[PTR] lb._dns-sd._udp.lan from 192.168.1.207
Jun  8 08:30:16 dnsmasq[584]: query[A] 1-courier.push.apple.com from 192.168.1.207
Jun  8 08:30:16 dnsmasq[584]: query[A] p07-btmmdns.icloud.com from 192.168.1.207
Jun  8 08:30:16 dnsmasq-dhcp[584]: DHCPREQUEST(eth0) 192.168.1.207 00:19:e3:3f:31:a9 
Jun  8 08:30:16 dnsmasq-dhcp[584]: DHCPACK(eth0) 192.168.1.207 00:19:e3:3f:31:a9 Pinky
Jun  8 08:30:17 dnsmasq[584]: query[TXT] push.apple.com from 192.168.1.207
Jun  8 08:30:18 dnsmasq[584]: query[SOA] local from 192.168.1.207
Jun  8 08:30:18 dnsmasq[584]: query[PTR] b._dns-sd._udp.0.1.168.192.in-addr.arpa from 192.168.1.207
Jun  8 08:30:18 dnsmasq[584]: query[PTR] db._dns-sd._udp.0.1.168.192.in-addr.arpa from 192.168.1.207
Jun  8 08:30:18 dnsmasq[584]: query[PTR] r._dns-sd._udp.0.1.168.192.in-addr.arpa from 192.168.1.207
Jun  8 08:30:18 dnsmasq[584]: query[PTR] dr._dns-sd._udp.0.1.168.192.in-addr.arpa from 192.168.1.207
Jun  8 08:30:18 dnsmasq[584]: query[PTR] lb._dns-sd._udp.0.1.168.192.in-addr.arpa from 192.168.1.207
Jun  8 08:30:18 dnsmasq[584]: query[PTR] b._dns-sd._udp.lan from 192.168.1.207
Jun  8 08:30:18 dnsmasq[584]: query[PTR] db._dns-sd._udp.lan from 192.168.1.207
Jun  8 08:30:18 dnsmasq[584]: query[PTR] r._dns-sd._udp.lan from 192.168.1.207
Jun  8 08:30:18 dnsmasq[584]: query[PTR] dr._dns-sd._udp.lan from 192.168.1.207
Jun  8 08:30:18 dnsmasq[584]: query[PTR] lb._dns-sd._udp.lan from 192.168.1.207
Jun  8 08:30:18 dnsmasq[584]: query[A] p07-btmmdns.icloud.com from 192.168.1.207
Jun  8 08:30:18 dnsmasq[584]: query[A] 1-courier.push.apple.com from 192.168.1.207
Jun  8 08:30:18 dnsmasq[584]: query[A] ocsp.apple.com from 192.168.1.207
Jun  8 08:30:18 dnsmasq[584]: query[SOA] local from 192.168.1.207
Jun  8 08:30:18 dnsmasq[584]: query[PTR] 207.1.168.192.in-addr.arpa from 192.168.1.207
Jun  8 08:30:18 dnsmasq[584]: DHCP 192.168.1.207 is Pinky.lan
Jun  8 08:30:19 dnsmasq[584]: query[A] pinky.lan from 192.168.1.207
Jun  8 08:30:19 dnsmasq[584]: DHCP pinky.lan is 192.168.1.207
Jun  8 08:30:34 dnsmasq[584]: query[A] pinky.lan from 192.168.1.207
Jun  8 08:30:34 dnsmasq[584]: DHCP pinky.lan is 192.168.1.207
Jun  8 08:30:49 dnsmasq[584]: query[A] pinky.lan from 192.168.1.207
Jun  8 08:30:49 dnsmasq[584]: DHCP pinky.lan is 192.168.1.207
Jun  8 08:30:53 dnsmasq[584]: query[A] pinky.lan from 192.168.1.207
Jun  8 08:30:53 dnsmasq[584]: DHCP pinky.lan is 192.168.1.207
Jun  8 08:30:55 dnsmasq[584]: query[A] ocsp.apple.com from 192.168.1.207
Jun  8 08:31:08 dnsmasq[584]: query[A] pinky.lan from 192.168.1.207
Jun  8 08:31:08 dnsmasq[584]: DHCP pinky.lan is 192.168.1.207
4

I don't know what would cause this. It's not a Pi-hole problem. Pi-hole is answering the queries as they are received.

5

I suspected as much. Since it only became apparent when I started using the pi hole, I thought someone else here might have seen the same thing.

6

I'll move this topic to Community Help.

7

This may not be related to your issue - it's just something I observed from your log:
The reverse lookup for pinky's address is yielding a hostname that starts with a capital P: Pinky.lan.

DNS itself is case-insensitive (i.e. mylaptop and MyLaptop are treated the same), so in theory this shouldn't matter at all (but it is also known to cause issues in DNS lookups, e.g. when 0x20 padding is applied).

Just to preclude that this causes hiccups for your older MAC OSs, you could try to harmonise the spelling of the name and see if that changes anything for you.

8

Thanks, I didn't think of that. Unfortunately that's not it, because changing the case produces the same results.

I'm dealing with this by reserving an IP address for these Macs on the pi-hole, and then adding an /etc/hosts entry on each Mac that's doing this. I added one line that's just

192.168.1.207	pinky.lan

And the constant lookups disappear. I don't know if I'm fixing the problem or working around it, but things are working the way I'd like now.

9

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