Confusing setup of friendly names and their mapping to IP- instead of MAC adresses

[Slluxx]

Versions

Pi-hole version is v5.7 (Latest: v5.7)
AdminLTE version is v5.9 (Latest: v5.9)
FTL version is v5.12 (Latest: v5.12.1)

Platform

• OS and version: Ubuntu 21.10

• Platform: Raspberry Pi

Expected behavior

If a client is added through /admin/groups-clients.php, i expect that to be the friendly name of every place where an ip or mac adress is shown (for example /admin/queries.php).

Actual behavior / bug

The friendlyname of ip adresses in /admin/queries.php is actually the result of mapping a domain to an ip adress on /admin/dns_records.php.

Additional context

The problem is that ip adresses can change quite frequently inside a network. The device/friendly name should be mapped to the mac adress and internally it should resolve ip to mac adress. This will not just completly remove the confusing part of adding a friendlyname (which i had to figure out and read about on a discourse feature request post) but also fix the problem with changing ips between devices inside a network. Thats the reason why this is a bug report and not a feature request.

[Slluxx]

looks like #2010 is on the same page but slightly different.

[github-actions]

This issue is stale because it has been open 30 days with no activity. Please comment or update this issue or it will be closed in 5 days.

[Slluxx]

Why is my attention required if i was the last one responding to this issue?

[jgrisham]

I just left some thoughts about this in #2010.

(This topic has been in discussion elsewhere over the past year, possibly in addition to the Discourse link you mentioned above - see also issue #1889, PR #1931, and PR pi-hole/FTL#1255).

[github-actions]

This issue is stale because it has been open 30 days with no activity. Please comment or update this issue or it will be closed in 5 days.

[iteqla]

I added some thouhghts on #2010

[github-actions]

This issue is stale because it has been open 30 days with no activity. Please comment or update this issue or it will be closed in 5 days.

[Slluxx]

.

[PromoFaux]

The way around this is to use Pi-hole as your DHCP server and assign static leases to each client - one can define the hostname there (or use that which is reported by the client)

It gets complex when trying to tie the IP address of an historical query to an existing (or even no longer existing) client, we can't store it in the database at the time of the query, because a DNS packet does not contain the MAC address of the client that is requesting.

I know @DL6ER has done some work on the query table to pave the way for a more optimal way of looking at this, which is mentioned above in pi-hole/FTL#1255

[Bucking-Horn]

The device/friendly name should be mapped to the mac adress and internally it should resolve ip to mac adress. This will not just completly remove the confusing part (...)

It won't.

For once, MAC addresses may not be as static as you wish for.

While they always could be assigned dynamically, mobile devices like smartphones in particular have pushed randomised MAC addresses as a privacy feature over recent years. But those would not be the only instances where MAC addresses could be spawned routinely, e.g. virtualisation software also is known to do so.
Granted, most of those cases would allow you to make a MAC static again within Pi-hole's immediately observable environment, though that may require respective client-side configuration.

In addition, one should also be aware that MAC addresses are directly observable on the same link only.

Any L3 switching equipment like additional routers, certain APs or the fancier varieties of managed switches may split your network into multiple links, as could VLANs. Any cross-link communication relies on IP addresses rather than MAC addresses.
While you would have no problems in observing a unique IP address in such scenarios, even if that's located on another link, the MAC address you see may just belong to your link's L3 switching gateway between those different links, and may thus aggregate a number of different hostnames.

You'd be more likely to ecounter such equipment in company networks, but even if most standard consumer grade home networks would likely still be flat, single-link only - with the growing number of network devices (like IoT and home automation), I'd expect L3 switching to become more common.

From strictly a DNS perspective, one could even argue that an IP address is a far stronger identifying criterion than a MAC address, as in fact, MAC addresses are absent from regular DNS queries.

[github-actions]

This issue is stale because it has been open 30 days with no activity. Please comment or update this issue or it will be closed in 5 days.