Top Clients honor DNS Records in homepage only

[robertofabrizi]

The issue I am facing:
I've used Local DNS -> DNS Records to replace IPs or unintuitive hostnames with my own aliases, the aliases show up in the Top Clients tables in the dashboard, but are ignored in the Top Clients tables in Long Term Data - Top Lists

Details about my system:
Docker Tag pihole/pihole:2021.09-arm64-buster

What I have changed since installing Pi-hole:
I've added domain names in Local DNS Records

[Coro]

@robertofabrizi

ignored in the Top Clients tables in Long Term Data - Top Lists

This is expected. The data there is historic data and there is no way to reliably know if the UP back then had the same hostname associated to it that it has now

[robertofabrizi]

I'm sorry, I omitted an important detail. I made the associations between domain name and ip address a couple weeks ago, but when I go to Long Term Data - Top Clients and use last 24 hours as a filter, they still appear as ip addresses or default device hostnames. I wasn't pretending for it to be applied "historically", but clearly I forgot to specify that part better in my original post.

[yubiuser]

What is the content of your /etc/resolv.conf?

[robertofabrizi]

roberto@raspberrypi4:~$ cat /etc/resolv.conf
# This file is managed by man:systemd-resolved(8). Do not edit.
#
# This is a dynamic resolv.conf file for connecting local clients directly to
# all known uplink DNS servers. This file lists all configured search domains.
#
# Third party programs should typically not access this file directly, but only
# through the symlink at /etc/resolv.conf. To manage man:resolv.conf(5) in a
# different way, replace this symlink by a static file or a different symlink.
#
# See man:systemd-resolved.service(8) for details about the supported modes of
# operation for /etc/resolv.conf.

nameserver 192.168.1.47
nameserver 192.168.1.1
search .
roberto@raspberrypi4:~$

[yubiuser]

nameserver 192.168.1.47 is this your PI?

[robertofabrizi]

Correct

[yubiuser]

Linking this bug report for reference:

pi.hole/admin/db_queries.php doesn't show client's name but shows client IP

---

In your case you should not edit /etc/resolv.conf by hand, but via /etc/systemd/resolved.conf. Try to set DNS=127.0.0.1 and see if this helps.

https://www.freedesktop.org/software/systemd/man/resolved.conf.html

[DL6ER]

Quoting from an older post - even if it was about a different topic:

@DL6ER

The issue is more with the statistics. Given many users have a non-deterministic DHCP server (handing out IP addresses sequentially in the order of appearance of the device), it is a commonly seen situation that a smartphone gets the IP address 192.168.0.2 which was associated to a laptop on the day before. And this just because the device was switched on before the laptop on this day. All the statistics that were counted for the laptop yesterday would now be added to the same "device" because of the same IP address. I don't think I like this...

Note that the Pi-hole's internal DHCP server is in fact deterministic, i.e., tries to assign the same dynamic IP address to the same devices every time. This is also the reason why the first device can receive a pretty high terminal address such as 192.168.0.216 because we computed this IP from the hash of the MAC address of the requesting device. This to make per-client filtering possible even with devices that may do not even support (or honor) static assignments. I, for instance, do not have a single static IP (only exception is the Pi-hole itself) in my network. Everything else is dynamic.

The problem is that sequential DHCP servers are still out there. And, actually, a large number of them. Many simple ISP-provided routers but also the cheaper, e.g., TP-Link or Netgear ones do this IIRC. Hostnames are updated once per hour by FTL for all known devices. This will account for the situation described in the quote (same IP used by two devices on two days). However, there is no such possibility for the database. We'd have to store the hostname in the database at the time the query is made to be sure we know the right name for this IP at that time.

We discussed this somewhere in the past and did some benchmarks. The result was about 30-50% in database size increase when storing the hostname for each query. So a typical database with a size of 3 GB can almost double in size. This seems unacceptable for what we are trying to achieve here. I'd rather rewrite the database altogether using linked-lists with domain and client tables linked by foreign keys. However, this is something not easily done and also nothing we could upgrade existing databases to (processing a full year worth of queries could take days on a Raspberry Pi).

TL;DR We should remove even try to resolve hostnames from the long-term pages altogether. It is inherently broken at this time.

[robertofabrizi]

I'm not sure that I'm following why this has specifically to do with aliases-ip pairs, the whole idea that my Top Client Total is 192.168.1.15 is per se possibly misleading under the assumption that the dhcp server might be using sequences, because regardless of the mapping between ip and hostname that traffic might have been caused by two different devices, one that was super chatty first, and another that made almost no traffic at all. Seeing .15 is basically useless in terms of debugging which client is misbehaving, so I'd go to my main router which is also the dhcp server and see who .15 is, and I'd see the latter, non misbehaving client. Seeing the same statistic in two different pages, one that has all aliases and the other that doesn't, is even more misleading or confusing imo.

[yubiuser]

@DL6ER

TL;DR We should remove even try to resolve hostnames from the long-term pages altogether. It is inherently broken at this time.

Open for discussion:

Do not try to resolve hostname of clients in long-term data