Show name in Top Clients lists rather than IPv6 addresses

Expected Behavior:

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.

Actual Behavior:

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.

My devices are all either Linux or Android.

Debug Token:

Hi there and welcome.

It's definitely possible to show hostnames for clients, you can do this one of two ways:

  1. Use PiHole as your DHCP server.
    Do this if your DHCP server does not set hostnames for devices on the network
    How do I use Pi-hole's built in DHCP server (and why would I want to)?

  2. Forward requests for your local domain to your DHCP server (usually your router)
    Do this if you want to (or are unable to not) keep using your router as your DHCP server.

It is also possible to use /etc/hosts on the pihole to add static entries for local domains but this is bad practice for a network where the given IP address for a device may change.

For clarification, I'm already using Pi-hole as my DHCP server. However, DHCP doesn't affect IPv6.

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.

Turn off the IPv6 DNS, you dont need it, you can resolve IPv6 whit a IPv4 DNS, i do that. I run full IPv6.

Sep 23 22:13:13 dnsmasq[966]: query[AAAA] from
Sep 23 22:13:13 dnsmasq[966]: forwarded to ::1
Sep 23 22:13:13 dnsmasq[966]: query[A] from
Sep 23 22:13:13 dnsmasq[966]: forwarded to ::1
Sep 23 22:13:14 dnsmasq[966]: reply is
Sep 23 22:13:14 dnsmasq[966]: reply is NODATA-IPv4
Sep 23 22:13:14 dnsmasq[966]: query[AAAA] from
Sep 23 22:13:14 dnsmasq[966]: forwarded to ::1
Sep 23 22:13:14 dnsmasq[966]: query[A] from
Sep 23 22:13:14 dnsmasq[966]: cached is NODATA-IPv4
Sep 23 22:13:14 dnsmasq[966]: reply is 2a00:1450:400e:80c::200e
Sep 23 22:13:14 dnsmasq[966]: reply is
Sep 23 22:13:14 dnsmasq[966]: reply is 2a00:1450:400e:80c::200e

Please secify where you turned off IPv6 DNS. On each client or in the pi-hole/FTLDNS configuration?

Maybe @DL6ER can say something about this and bring some light into the darkness.

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:

  1. 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.
  2. 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.

Yes, my router acts as DHCP server for IPv4 addresses and also assigns the IPv6 ULA address prefix.
All my clients have IPv4 and IPv6 addresses.

For example, query log and network overview shows like this:
Query Log:

Network overview:

I expected that the query log could display the clients hostname instead of simply the IPv6 address, because the corresponding hostname is known as shown in the network overview.

Storing the corresponding hostname for IPv6 addresses would also be useful when using the long term data.

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.

Added and tested. Awaiting code review.


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").

1 Like

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

Setting to implemented because hostname resolution for IPv6 is possible by /etc/host, Local DNS Records or conditional forwarding.