I would like to see hostnames for all entries in the top clients lists on the web interface. Distinguishing between IPv4 and IPv6 is optional.
Requests using IPv4 (or perhaps more properly, A records) are associated to the hostname configured in DNS, as expected. However, Requests using IPv6 (or perhaps AAAA records) are displayed as the IPv6 address. I have no idea how to figure out which hosts have those addresses.
I also see the same behavior while using my router as DHCP server and with Condentional Forwarding activated:
If the Query was made via IPv4, then in query log the clients hostname is shown.
But in most time the queries comes via IPv6, so the query log shows only the IPv6 address instead of the corresponding hostname.
If I take a look into the Network overview, there is the correct assignment of the hosts current IPv6 address to the hostname.
Where shall I shed light on? Pi-hole will only be able to show IPv6 hostnames with conditional forwarding if the configured server actually replies to IPv6 PTR requests.
Things need to be differentiated now:
Pi-hole is used as DHCP server - in this case, it makes no sense to configure conditional forwarding as your Pi-hole should be the single source of truth in the network.
However, as has already been mentioned, the DHCP server has nothing to do with IPv6. This means that in such a setup, the IPv6 addresses have to be assigned to host names manually, e.g., in /etc/hosts.
Pi-hole is not your DHCP server and conditional forwarding is used - in this case, the upstream DHCP server (which is to be specified as conditional forwarding server) is responsible for giving replies to IPv6 name resolution requests. This usually doesn’t work for similar reasons mentioned in my point 1.
You’re mixing things here. A requests are requests for IPv4 addresses. These questions can be asked from both, IPv4 and IPv6, clients. Similarly, AAAA requests are requests for IPv6 addresses, they can euqally well come from IPv4 or IPv6 clients.
This is what I would expect in a normal setup. It is the only downside I have found to date with the self-configuring protocol IPv6.
Well, I assume this goes only for those clients where also an IPv4 address is there? We store the most recently found host name for a given hardware (MAC) address and do not differentiate between IPv4 and IPv6 therein.
Different sources of information populate the network table. If for at least one of the IP address (this will be the IPv4 address) a host name is known, this host name is correlated with the hardware address which is the unique constraint in the network table.
We only store the information there but don’t read it right now. We could theoretically use the network table as a secondary source of information to get IPv6 host names. This would immediately affect all data FTL processes and shows and offer host names in the Top Clients, Query Log, etc. lists.
This (edit: i.e. the following question) is probably relevant only for a smaller part of Pi-hole installations, and it is of course dependant on your method of acquiring a device’s MAC address initially, but if you are achieving this by associating a hostname to a device’s MAC address:
Isn’t a device’s original MAC addresses only guaranteed to be directly observable in the data link layer packets within the same physical network?
Couldn’t this get messy in configurations with several subnets involving routers, switches and repeaters, at least if they are physically separated (i.e. replacing their MAC address on forwarding traffic)?
I disagree. Even though we have no numbers, I still think the vast majority of Pi-hole’s will run on dedicated Raspberry Pis in ordinary (read as “standard”) home network setups. When they run dual-stack (which is more and more rolled out), the routers may often be able to resolve host names from IPv4 addresses, however, they usually fail to do so for IPv6 addresses. This is where our implementation kicks in and improves the users experience.
Yes, this is a limitation. One that we cannot easily but also do not intend to overcome as this feature is meant to assist the small network not the large and complicated ones (where the admins should be able to resolve the IPv6 host name issue “properly”).