Top Client / Queries show IPv6 ULA instead of hostname

[Roo]

The issue I am facing:

If we look at the top clients:

(I've blanked out working hostnames - but left the ULA addresses.

Now if I go looking at the "Tools->Network" - I can see that these addresses are know to the pi-hole internal db for mapping MACs

Looking here in the doc: https://docs.pi-hole.net/ftldns/configfile/#names_from_netdb

My route which provides local DNS is OpenWRT based and my ISP provides IPv6 connectivity. This means my network is full of IPv6 traffic.

The OpenWRT DNS system hands out multiple IPv6 addresses to every client - including ULA addresses. The ULA addresses in question (see first screenshot of top clients) - those do not reverse lookup correctly against my router DNS.

However - the doc appears to point to a patch that is supposed to deal with this.

The code looks like it is supposed to handle this too? FTL/src/resolve.c at b90ab8b1e78d7aece11c8fee1c3c00817761de52 · pi-hole/FTL · GitHub

but clearly - either I'm mis-interpreting what is supposed to happen here, or something is wrong.

Details about my system:

Raspberry Pi 4 - running Ubuntu server (20.04 LTS) - details on my base install on my blog: https://lowtek.ca/roo/2021/raspberry-pi-ubuntu-server/

I am NOT using the pi-hole DNS, but have configured conditional forwarding to point back to my local DNS run by my router. This is how it is getting the names (at least for ipv4)

Summary:
Pi-hole on Rpi hardware. Yes - my DNS doesn't do reverse names for the ULA addresses, but I expected that the patch that went into FTL was going to fix this. It doesn't appear to.

What I have changed since installing Pi-hole:

Pretty stock - as this is just setup.

[Daxtorim]

@Roo

The ULA addresses in question (see first screenshot of top clients) - those do not reverse lookup correctly against my router DNS.

Did you tell Pi-hole to conditionally forward PTR queries for those ULAs to your router? If you only filled out the settings page on the dashboard, the ULAs won't be included since Pi-hole will really only conditionally forward queries for the specific (probably IPv4) network you entered there.

To set up conditional forwarding for the ULAs as well (or generally for other networks) you need to create a custom config file. Something specific to each of your subnets or prefixes like this:

$ cat /etc/dnsmasq.d/conditional_forwarding.conf
# Additional networks for Pi-hole's conditional forwarding
server=/0.8.e.f.ip6.arpa/10.0.0.1
server=/7.6.6.1.f.c.e.f.4.a.d.f.ip6.arpa/10.0.0.1

The first pattern is the domain you want to match, the second is pattern is the IP address of the server that should recieve the DNS query, i.e. your router.

Alternatively, server=/arpa/10.0.0.1 will universally match all PTR queries for any prefix or subnet (and more that's probably handled by your router anyways).

@Roo

However - the doc appears to point to a patch that is supposed to deal with this.

You might have the same problem that I have with my installation:

IP addresses on the dashboard are not replaced by names from the network table if they cannot be associated with a MAC address *immediately*

Expected Behaviour: IP addresses without a known hostname associated to them should be replaced with another hostname of the same device from the network table, if possible. The corresponding setting (NAMES_FROM_NETDB) defaults to TRUE. Actual Behaviour: Sometimes IP addresses are not replaced by names from the network table. [grafik] In the case of the green underlined address, it is already filed under an existing entry which has several known hostnames associated with it. The hostnames …

TLDR: There won't be any more attempts after the first one to associate a hostame with any given IPv6 address by default. When there is no immediate mapping of the IPv6 address to a known host in the network table, Pi-hole has no way to know what hostname to use as a replacement from the network table and there won't be any update after that. You have to change this behavior manually by adding REFRESH_HOSTNAMES=ALL to /etc/pihole/pihole-FTL.conf in order to have Pi-hole try more than once to update the hostname.

---

@Roo

I am NOT using the pi-hole DNS, but have configured conditional forwarding to point back to my local DNS run by my router. This is how it is getting the names (at least for ipv4)

I guess you mean Pi-hole's DHCP server here, not DNS, otherwise this makes little sense .

[Roo]

Thank you for the reply.

@Daxtorim

Did you tell Pi-hole to conditionally forward PTR queries for those ULAs to your router? If you only filled out the settings page on the dashboard, the ULAs won't be included since Pi-hole will really only conditionally forward queries for the specific (probably IPv4) network you entered there.

You are correct. No. I only told it to conditionally forward IPv4 -- partly because the web UI seems to be somewhat IPv4-centric.

Thank you for the pointer to how to configure additional conditional forwarding - it was something I had made a note of when I was doing the original setup and simply forgot about. I suspect because I do not have this additional configuration none of my IPv6 addresses are being sent for reverse lookup. Of course - as pointed out in my original post - my OpenWRT DNS isn't reverse mapping all of the IPv6 addresses it assigns (each client gets more than one). I'm not sure if this is an OpenWRT bug, or just how things are in IPv6 land.

Wow - your post appears to be exactly what I'm seeing. I'm going to have to read through that and make a few changes to see if this gets better.

@Daxtorim

I guess you mean Pi-hole's DHCP server here, not DNS, otherwise this makes little sense .

Yes - I meant DHCP. My OpenWRT manages DHCP and maintains the local lan DNS. Pi-hole is configured as every client's DNS server, and should smartly forward things to the right places.

[Roo]

Adding REFRESH_HOSTNAMES=ALL to /etc/pihole/pihole-FTL.conf then restarting FTL (sudo service pihole-FTL restart) fixed me up.

I do still have something weird here

A single client - which has two unique IPv6 addresses - and in the Tools->Network view is merged as the same device (ie: this is a wifi device with a single MAC).

Ideally I'd like pi-hole to collapse those two IPv6 addresses - into a single client. Does it ever make sense to have two unique clients with the same reverse mapped name on a given network?

Tools->Network shows me this view of the client

Aside from this duplication of names - which is probably a different issue - this is the answer (with all credit to @Daxtorim for pointing me at it)

[yubiuser]

@Roo

Does it ever make sense to have two unique clients with the same reverse mapped name on a given network?

From a DNS point of view yes. DNS works on IP level, so for Pi-hole they are unique clients. From a human point of view it might be the same client. But having Pi-hole to judge what constitutes as a single client is nearly impossible. Different users will have different opinions about this, sometimes definition will change according to the problem to solve: Client defined by IP, hostname, MAC, interface, physical device...?

You might want to check out Alias clients, see the thread here

Adding alias-clients to Pi-hole FTL

Many devices have multiple addresses (e.g., IPv4 and IPv6) and we've been asked often if they can be grouped together in the statistics. Well, grouping them has a number of drawbacks (discussed elsewhere), but I think I found a way how to achieve what everyone wants without having to rip apart everything inside FTL. Here, I introduce super clients. Super-clients are (in some way) ordinary clients but are only virtual. They appear everywhere on the dashboard just like the other clients, but they…

[Bucking_Horn]

In addition, note that IP address-to-hostname is a many-to-many type of association, i.e. it is perfectly valid to have multiple names for the same IP as well as multiple IPs for the same name as well as both.

[Roo]

@yubiuser @Bucking_Horn Thank you for your replies.

@yubiuser

Different users will have different opinions about this, sometimes definition will change according to the problem to solve: Client defined by IP, hostname, MAC, interface, physical device...?

I agree - you can't make everyone happy. I'm fine with it being as it is, but on my network - I've got a particular point of view over how things should map. My questions are about understanding what the pi-hole point of view is - and I value all the work-arounds that exist.

Given that we should not allow a solved thread to continue to grow - I will stop here. Thank you all for reading.