Reverse DNS lookups of client's IPs

The issue I am facing:
I recently set up Pi-Hole on a Raspberry Pi 4B and it works flawlessly, except for the fact that I only see client IPs on the dashboard, and I'd prefer if it displayed hostnames instead. I know this question has probably been asked quite often, but the information I could find was confusing and each network is unique !

Details about my system:
My ISP is Free SAS (I'm based in France) and their CPE/box is called a "Freebox". It acts as a router, DHCP server and DNS server, but that last one is only used for external/internet DNS name resolutions, i.e. it doesn't offer management of a local domain nor does it answer to local DNS queries even though it knows about the DHCP leases from its own DHCP server. Which means that devices behind the box must rely on other means to resolve names and IP addresses, such as mDNS, NETBIOS and local /etc/hosts files.
I have set up the Pi-Hole as the primary and only DNSv4 and DNSv6 server on the box. For IPv6, I have chosen the Pi-Hole UGA address, maybe I should have selected the LLA (fe80:*) address instead ? At any rate, the box doesn't support ULA addresses.
Most devices on my network fully support IPv6 and since my ISP is also fully IPv6 compliant (they actually encapsulate IPv4 into IPv6 packets), most of my local and internet trafic uses IPv6 instead of IPv4, as confirmed by Pi-Hole's dashboard.
The box sends SLAAC+RA ICMPv6 packets (DHCPv6 is turned off), so most devices are auto-configured and they successfully get the Pi-Hole IPv6 address as DNSv6 server. DHCP/DNSv4 works fine as well.
Most devices also have IPv6 Privacy Extension enabled, which means that their UGA IPv6 address changes every 24 hours or so.

What I've done to try and get client's hostnames instead of IPs:
Since the Freebox doesn't answer to local DNS queries, Conditional Forwarding isn't going to help here.
For IPv4, since the box is configured to provide static DHCP leases, I added all known devices to the /etc/hosts file on my Raspberry Pi. This however leaves guest devices (which have no static DHCP lease configured) unknown to Pi-Hole.
For IPv6, it gets more complicated due to temporary IPv6 addresses which are used by most IPv6 devices on my LAN. There is no point in trying to add those IPs to the hosts file.
Interestingly enough, it seems Pi-Hole can deduct the host name of some IPv6 addresses based on the MAC address of the client and the static IPv4 resolution I put in the hosts file. But that doesn't work all the time.

Questions:
What would be the best way to get reverse DNS working for all IPv4 & IPv6 addresses ? Is it even possible for privacy enabled IPv6 devices ?
Would switching the advertised DNSv6 address to the Pi-Hole LLA address instead of UGA force clients to use their own LLA addresses instead of their (temporary) UGA address, thereby making reverse lookups possible (e.g. using /etc/hosts) ?
Would enabling the Pi-Hole DHCP server (and disabling the freebox DHCP server) help in my situation ? Would I get conflicting SLAAC+RA packets coming from both my box and the Pi-Hole in this case (I think the box allows configuring a Next Hop for the first /64 subnet which is used by all my devices, but I have no idea of the consequences of activating this, and if the Pi-Hole can serve as an IPv6 router in place of the freebox).

Long post, sorry, but I prefer to give as much details as possible in the first post !
Thanks in advance for your help !

Hello jfb. This FAQ isn't really relevant to my problem: I DO see individual client IPs and not my router's IP for all of them. The issue is the reverse DNS resolution of those IPs.

While a client may present a name during DHCP lease negotiation, there is no requirement that a receiving DHCP server must register that name with a colocated or some other known local DNS server.
While most DHCP servers on router's would inject the respective DNS records into their internal DNS nonetheless (as it is obviously beneficial), from what you describe it would seem your Freebox router would not create those corresponding DNS entries.

You should be able to verify that by forcing a lookup for a known local IP or hostname directly through your router's IP, e.g.

nslookup hostname router-IP
nslookup host-IP router-IP

We've had a few reports with respective similar observations for other router models.
I recall a few workarounds for those, e.g. for some Mikrotik models, a dhcp hook script injecting DNS entries can be installed on the router, and for some of Ubiquiti's Edge Router models, the internal DHCP server can be replaced by dnsmasq.

If you want to address this on your router model, you should consider to consult your router's documentation and support channels.

If you would want to address this via Pi-hole, you'd have two options:

(i) create the necessary Local DNS records

Note that you may need several entries per host, for plain and FQDN host names as well as for IPv4 and IPv6

(ii) enable Pi-hole's DHCP server and disable your router's

Note that a client will pick up the new settings only upon DHCP lease renewal (so after 1 day the latest in your network, unless you force a client to request a fresh lease before)

Hello @Bucking_Horn,

I can confirm that the freebox router doesn't reply to reverse DNS queries (I tried with nslookup and dig and always received NXDOMAIN). This is a CPE box, so the configuration options are pretty basic (actually, I think it's not that bad compared to other French ISPs CPEs !).

Using local DNS records is what I did so far, but as I explained, it's not perfect, especially for IPv6 privacy-enabled addresses.

I'm willing to move my DHCP server from my box to my Pi-hole, but I'm not sure it would help with IPv6 addresses ? Would using LLA instead of UGA addresses help with reverse lookups ?

Reverse resolving IPv6 Privacy Extension addresses to a fixed hostname would defeat their very purpose of obfuscating a client IPs identity.
In addition, your ISP is usually in control of DNS for your public IPv6 addressses, so I'd expect to see generic names in a pattern similar to <somehow-transcoded-IPv6-address>.<ISP-domain-name> for a reverse lookup.

Note that Privacy Extensions themselves are not your issue:
It is the fact that some of your clients may send their DNS request from their IPv6 PE address, and those then would hamper associating a host name.

There is not one fail-safe path to address this, but you may try the following options:

a) Configure your router to not provide an IPv6 DNS server address at all.
In absence of an IPv6 DNS server address, clients will always use their IPv4 for DNS. Hence it's important that your router doesn't offer its own IPv6 nor any other. Depending on your router, that may not be configurable.

b) configure a ULA address for Pi-hole.
This may or may not reduce the amount of queries posed via a public IPv6 address, depending on a client's IPv6 prefix policies (see next)

c) change a client's IPv6 prefix policies to prefer IPv4 (or IPv6 ULA) over public IPv6 in your local network.
This isn't supported on every device (e.g. IoT or smartphones).

d) configure your client to stop creating temporary IPv6 Privacy extension addresses and create a local DNS record for the public IPv6, overlaying your ISP's generic names
As those addresses are meant to improve privacy by regularly changing your IP address (e.g once every two hours), I do not recommend doing so

e) configure your router to make use of your Pi-hole machine's link-local IPv6 address (range fe80::/10 ).
This would result in your clients sending DNS requests from their link-locals.
This is only on an option as long as there are no L3 switching devices in your network, since link-local addresses are accessible by same link or same network segment devices only.
It should be safe if all of your devices are connected directly to your router.

Thanks @Bucking_Horn for the detailed answer ! I'm still new to IPv6 (like most people I guess!) but I really want to learn about it, since it's the future !

It looks like option e) is the most promising and the one I was going to try! You just confirmed that it might work, since all my devices are indeed directly connected to my router.

Since I don't want to mess around with IPv6 settings on every connected device in my network, I won't try options b, c or d.
BTW, I think Privacy Extension is a bit of a joke since the 64-bit network prefix provided by my ISP is unique and all IPv6 devices use it to build their SLAAC UGA address, so it would be trivial to track me on the web using the network prefix. A bit like my NAT IPv4 router address can be used to track me. But that's another can of worms :wink:

Regarding option a, if I remove the Pi-Hole IPv6 address from the router's IPv6 DNS server configuration and leave it empty, I think the box will automatically silently advertise the ISP IPv6 DNS server instead, which will circumvent the Pi-Hole since Windows - for example - prefers IPv6 DNS servers over IPv4. I could set a bogus IPv6 as the DNSv6 server (::1), but it's a bit dirty.

I'll let you know what I ended up doing and if it solved all my issues !

Thanks for your help !

Depending on your ISP, your plan and your country of residence, your public IPv6 prefix (just as your IPv4 address) may be changed by your ISP regularly (e.g.every day or once a week) as required by local regulations for consumer plans.
Usually, that prefix would also be subject to change if you power-cycle your router.

That's one of the reasons why we recommend to avoid using a GUA address for Pi-hole, as Pi-hole needs a stable address.

1 Like

As far as I remember, when I launched the basic install shell script and then the setup wizard, it did ask me for a static IPv4 address which it put in the /etc/dhcpcd.conf file, but didn't ask me for a static IPv6 address. The setupVars.conf file was auto-populated with my GUA IPv6 address. Which lead me to the problem I described in my original post. So maybe some kind of warning or recommendation should be displayed during the initial setup and in the pihole -r utility ?

Anyway, I disabled slaac private and activated slaac hwaddr in /etc/dhcpcd.conf and set the PiHole's LLA as DNSv6 server on my router, and everything looks much better now ! All my client's IPs are resolved now, even though PiHole is not the DHCP server. I guess PiHole uses the IPv4 hostname I mapped in the local hosts file to resolve IPv6 LLAs to a client hostname based on its MAC address, which is shared between IPv4 and IPv6.

I might still move my DHCP server to my Raspberry Pi, just because it sounds like a fun project :wink:

Setting a static IPv6 address isn't recommendable, since that comes with a couple of drawbacks. The change of your IPV6 prefix would be the most prominent one, as that would invalidate your static address immediately.

That option has no bearing on your issue, especially since you've opted for using link-locals for your Pi-hole installation.

Setting slaac [hwaddr | private] in your Pi-hole host machine's dhcpcd.conf controls whether an interface identifier for a network's interface IPv6 addresses on that machine (and that machine only) would be calculated as EUI-64 (using and thus also exposing its MAC) or as a stable, private opaque RFC7217 address. An interface identifier created by the latter is guaranteed not to change for a given NIC as long as the IPv6 prefix won't change. This would be true for both link-local and ULA addresses (as long as you don't change your ULA prefix).

However, your Pi-hole host will still use RFC4941 Privacy Extension addresses in addition to any EUI-64 or RFC7217 addresses its calculating for itself, unless you explictly disable them.

DHCP is strictly IPv4 - switching your DHCP server would have no bearing on your IPv6 issue.

That's what solved your issue. :wink:

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