Client names in too many clients

Expected Behaviour:

I've configured local DNS to give names to some local devices (IPs are fixed on the router). I expect only that device to show with the name on the different pages like the home page top clients, tools network, etc.

Actual Behaviour:

One of the client names is misbehaving. It appears for several devices on the network. I have even removed this entry from the local DNS but the name continues to appear on several pages even after a few days. See home-acer in attached screenshots. It appears that pi-hole uses some heuristics to determine a client name. I would like to understand that logic and help to fix this issue.

image

I think it's just cached. In the Pi-hole's terminal try the command

pihole restartdns reload

That didn't help. Continue to see that name.

Why did the pihole assign the same name to multiple devices?

For each of those 5 devices named home-acer, when you look at the blurred out MAC addresses and vendors (no need to unblur them here), does that show different MAC addresses and vendors which belong to other devices that are not home-acer? The first and third groups kind of look the same and the second one different.

Are those IPs all current devices on the network belonging to other devices but which are showing in Network overview as home-acer? And presumably one of them really would be home-acer.

Is the router definitely always giving the same fixed IP to home-acer? Which IP would it be in that list?

Is there anything more complex on the network or on acer-home, like VMs, Docker, VPNs etc?

I had a friend who had a similar issue but not quite the same. His Pi-hole was using previous hostnames for a machine that was booting multiple OSs, because the naming was based on the MAC address. He was able to flush those from the web admin interface with the Flush network table and then Restart DNS resolver buttons in Settings. You could try that too.

If that doesn't clear them then it might need some manual database tweaks, and the Pi-hole devs can advise. The pihole -d command will do a debug log which you can read in /var/log/pihole afterwards, and you get an option to send it to the devs securely and then post just the token URL in here so they can review it.

You could try to clear your network table.

On the web interface, go to Settings page and click on Flush network table button.
This will remove all items from the table and only new entries will be shown.

As requested by our template, please upload a debug log and post just the token URL that is generated after the log is uploaded by running the following command from the Pi-hole host terminal:

pihole -d

or do it through the Web interface:

Tools > Generate Debug Log

Thank you! Here's the debug log: https://tricorder.pi-hole.net/ixWw0prt/. I just generated this without doing any other actions like flush, etc. Let me know if a debug is needed after certain actions.

I can confirm that each of the clients are distinct clients as they appear on the network page and top clients. The IP of home-acer is definitely fixed and it is a normal PC without VMs, etc.

I also just checked that over time, 8 distinct devices have received this name. The only one that I want to have this name is the 4th one.

Your debug log shows that Pi-hole is neither using any local upstream resolvers nor is Conditional Forwarding enabled.
As no third-party DNS resolver is involved, that would suggest that Pi-hole actually observed those names on-link as shown in the network table at some time.

Run on your Pi-hole host machine, would arp -a perhaps return similar results while some of the clients listed above are online at the same time?

If not, you should follow rdwebdesign's suggestion of flushing the network table.

Turned on all possible devices and ran arp -a on the pi-hole host. What did you mean by similar results? I don't see hostnames in arp output.

image

Anyway, I flushed the network table. Looks like I lost the stats of the network page :grimacing: And home-acer has appeared on 5 devices after few minutes! Here's a debug log again: https://tricorder.pi-hole.net/q7Ay4F2B/

Is home-acer a Chromebook? I'm wondering if it's doing MAC address randomisation and presenting different MACs to your DHCP server, causing it to hand out multiple addresses. The fact that you've had 5 new instances in just a few minutes after flushing them makes me wonder.

If you go to Tools / Pi-hole diagnosis, does that have any warnings showing DNSMASQ_WARN - Ignoring query from non-local network and an IP in there starting with 100.115...? You may not have, just helps narrow things down.

If its a Windows 10 laptop, that could similarly be doing MAC randomisation and using up your address scope quickly.

Try this. In the Pi-hole terminal run the command

pihole -t | grep -E "DHCP(REQUEST|ACK)"

That will show devices requesting and being assigned IP addresses in real time. Then use your home-acer machine as normal, and observe the log in the terminal. Are you seeing home-acer appearing many times, each with a different MAC and IP?

Obviously, arp fails to determine hostnames completely, i.e. it's only showing a '?' instead, for all currently observed MAC addresses.
Usually, arp would make an effort to return hostnames, e.g. similar to
my-router (192.168.1.1) at 28:cd:c1:c0:ff:ee [ether] on wlan0

Run on your Pi-hole host machine, what's the result of

sudo grep -m 10 -i home-acer /var/log/pihole/pihole.log*

Please share the output, preferably as text.

I also notice that only 2 out of those 5 h/w addresses are actively using Pi-hole for DNS.

What kind of device is your original home-acer at .131?
And what kind of device is your .102?

For the devices sharing that name:
Is there something they would have in common that puts them apart from other clients, e.g. would they connect to your network through the same piece of network equipment (e.g. the same wifi access point or switch)?


I don't think that will return anything, as rubtriangulum is not using Pi-hole for DHCP.

Oops yes you're right.

Thanks for the analysis. :slight_smile:

Pi-hole diagnosis has no issues found.

sudo grep -E "DHCP(REQUEST|ACK)" /var/log/pihole/pihole.log returned nothing as bucking_horn pointed out.

sudo grep -m 10 -i home-acer /var/log/pihole/pihole.log* is returning an empty result.

In the few minutes after the flush when I took the screenshot yesterday, the other devices did not make a query. Here is how it looks now after about 24 hrs - still 5 devices with that name.

Home-acer (.131) is a Windows 10 laptop with MAC randomisation turned-off as I want to use a reserved address at the router. Devices that I want to use fixed names have fixed/reserved IP in the router and a name given in pi-hole local DNS (as was recommended here). As mentioned in OP, home-acer is not present currently in local DNS.

.102 is an amazon echo device. The 2 clients with least counts are smart bulbs. .101 probably went to 2 different devices in the last 24 hrs as far as I can determine. Don't see anything common in these devices vs. other clients. IP+MAC should be the unique client, IMHO. While the network page seems to show 2+ IPs for one client, it appears that it doesn't show 1 IP for 2+ clients as separate lines.

I also just tried a flush network table, restart system. That seems to have removed that name from pi-hole. After 30 mins too, I see the clients but not the home-acer name! I'll try adding the name to local DNS later and report back here.

I can't readily explain your observation.

We already have established that there is no other local DNS server involved in Pi-hole's resolution chain that would source those names, but just to be sure: You wouldn't run another local DNS resolver, would you?

Let's also check your Pi-hole host machine's hosts file:

cat /etc/hosts

And let's see what Pi-hole returns as hostnames for a few of those IP addresses:

dig @192.168.1.2 -x 192.168.1.131 
dig @192.168.1.2 -x 192.168.1.102 
dig @192.168.1.2 -x 192.168.1.105 

And the same when querying your router at 192.168.1.1:

dig @192.168.1.1 -x 192.168.1.131 
dig @192.168.1.1 -x 192.168.1.102 
dig @192.168.1.1 -x 192.168.1.105 

Thanks again for persisting! There isn't any other DNS resolver. :slight_smile: As per pi-hole guide, my network's router gives out the pi-hole as DNS server. And pi-hole uses opendns as the upstream.

/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       rpi

dig output:

; <<>> DiG 9.11.5-P4-5.1+deb10u7-Raspbian <<>> @192.168.1.2 -x 192.168.1.131
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 16049
;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1

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

;; Query time: 1 msec
;; SERVER: 192.168.1.2#53(192.168.1.2)
;; WHEN: Sat Sep 24 18:23:41 IST 2022
;; MSG SIZE  rcvd: 55


; <<>> DiG 9.11.5-P4-5.1+deb10u7-Raspbian <<>> @192.168.1.2 -x 192.168.1.102
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 59506
;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1

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

;; Query time: 1 msec
;; SERVER: 192.168.1.2#53(192.168.1.2)
;; WHEN: Sat Sep 24 18:23:41 IST 2022
;; MSG SIZE  rcvd: 55


; <<>> DiG 9.11.5-P4-5.1+deb10u7-Raspbian <<>> @192.168.1.2 -x 192.168.1.103
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 49697
;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1

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

;; Query time: 1 msec
;; SERVER: 192.168.1.2#53(192.168.1.2)
;; WHEN: Sat Sep 24 18:23:41 IST 2022
;; MSG SIZE  rcvd: 55


; <<>> DiG 9.11.5-P4-5.1+deb10u7-Raspbian <<>> @192.168.1.1 -x 192.168.1.131
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 4351
;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1

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

;; Query time: 18 msec
;; SERVER: 192.168.1.1#53(192.168.1.1)
;; WHEN: Sat Sep 24 18:23:41 IST 2022
;; MSG SIZE  rcvd: 55


; <<>> DiG 9.11.5-P4-5.1+deb10u7-Raspbian <<>> @192.168.1.1 -x 192.168.1.102
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 61569
;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 1

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

;; AUTHORITY SECTION:
168.192.in-addr.arpa.   3600    IN      SOA     prisoner.iana.org. hostmaster.root-servers.org. 1 604800 60 604800 604800

;; Query time: 13 msec
;; SERVER: 192.168.1.1#53(192.168.1.1)
;; WHEN: Sat Sep 24 18:23:42 IST 2022
;; MSG SIZE  rcvd: 132


; <<>> DiG 9.11.5-P4-5.1+deb10u7-Raspbian <<>> @192.168.1.1 -x 192.168.1.103
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 15905
;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1

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

;; Query time: 7 msec
;; SERVER: 192.168.1.1#53(192.168.1.1)
;; WHEN: Sat Sep 24 18:23:42 IST 2022
;; MSG SIZE  rcvd: 55

I wonder if home-acer has ever been queried before, which could be verified by running:

pihole-FTL sqlite3 -header -column /etc/pihole/pihole-FTL.db "SELECT id, timestamp, domain, reply_type FROM queries WHERE domain LIKE '%home-acer%' LIMIT 10;"

Your results show a consistent NXDOMAIN reply by Pi-hole for those IP addresses, i.e. Pi-hole isn't aware of any hostnames for any of them at all.

You router also doesn't know about them, though each of its answers looks slightly different (which is also unusual).
What make and modle is your router?

A DHCP client may supply a name for itself during lease negotiation with a DHCP server. Not all router's DHCP servers would in turn register such a client-supplied hostname with its co-hosted local DNS server - and yours obviously doesn't.

In absence of any direct DNS definitions for those IP addresses within P-hole itself and any potential delegated DNS sources, Pi-hole may resort to use hostnames as passively observed through its host systems networking stack, i.e. using tools like ip neighbor and arp. Those results are limited to those clients that are on the same link (or network segment) that your Pi-hole host machine's NIC is connected to. Pi-hole's network overview is a representation of its knowledge gathered that way, but note that it is not related to DNS.

Using arp, we tried to get a better understanding of what your OS knows about names for same-link neighbors, but unusually enough, that didn't return any hostnames at all.

This leaves me puzzled for an explanation of your observation.

The good news is that your dig results have shown your observation to be limited to Pi-hole's network overview, i.e. they haven't spoiled your DNS, as none of those IPs is associated to a hostname by means of a DNS record definition.

Also this:

4. DNS Reverse Mapping for Private-Use Addresses
As noted in Section 2, private-use addresses have only local significance. This means that sending queries out to the Internet is not sensible: there is no way for the public DNS to provide a useful answer to a question that has no global meaning. Despite the fact that the public DNS cannot provide answers, many sites have misconfigurations in the way they connect to the Internet; this results in such queries relating to internal infrastructure being sent outside the site. From the perspective of the public DNS, these queries are junk -- they cannot be answered usefully and result in unnecessary traffic being received by the nameservers which underpin the operation of the reverse DNS (the so-called reverse servers [RFC5855], which serve "IN-ADDR.ARPA"). To isolate this traffic and reduce the load on the rest of the reverse DNS infrastructure, dedicated servers have been deployed in the Internet to receive and reply to these junk queries. These servers are deployed in many places in a loosely coordinated effort known as the "AS112 project". More details about the AS112 project can be found at http://www.as112.net/.

5. AS112 Nameservers The nameservers responsible for answering queries relating to private-use addresses are as follows:
o PRISONER.IANA.ORG (192.175.48.1)
o BLACKHOLE-1.IANA.ORG (192.175.48.6)
o BLACKHOLE-2.IANA.ORG (192.175.48.42)
A request sent to one of these servers will result in a response being returned to the client. The response will typically be a UDP datagram, although it's perfectly valid for requests to be made over TCP. In both cases, the source port of packets returning to the site that originated the DNS request will be 53.

https://www.rfc-editor.org/rfc/rfc6305.html

I still haven't added home-acer to local DNS. Here's the pihole-FTL output:

id       timestamp   domain           reply_type
-------  ----------  ---------------  ----------
429086   1637426470  home-acer
1139958  1640695682  home-acer
1139959  1640695682  home-acer
1139965  1640695699  home-acer.local
1139966  1640695699  home-acer.local
1139967  1640695699  home-acer.local
1139968  1640695699  home-acer.local
1259282  1641268812  home-acer
1259283  1641268812  home-acer

The router is a 2-unit tp-link deco M5. Yeah, I noticed the slightly different answer for .102. Some of the devices do give their name (specially Windows and Apple devices, but not Android, other smart devices) - they are visible in my router UI and other tools like the LAN scan of this app. The router allows me to name devices and I had hoped to name my devices in a single place. But it doesn't give out these names - had tried this long back with conditional forwarding and since it doesn't work, it is now disabled and I use local DNS of pi-hole additionally.

I'm beginning to think that your router's missing support for local hostname resolution is causing your observation.

If that's the case, providing the respective DNS records within Pi-hole should help.
You can do so via Pi-hole's Local DNS records.

Alternatively, you may also try to switch on Pi-hole's DHCP server, after either switching off your router's or limiting its DHCP range to accomodate just your Pi-hole (and maybe the second TP-Link unit).