IPv6 per protocol requires clients to change their addresses frequently (<1 week). This is a problem which may require to rethink client mapping.
While the Network section is useful to identify clients, it becomes a big hurdle to track clients through the Query Log.
I would love to have a feature that enables the user to map the client MAC to any name they wish.
From a security standpoint, if all the clients are mapped to nice names, any 'intruder' would stand out this way.
While changing IPv6 addresses can be expected to be observed on most modern OSs, IPv6 does not require clients to do so.
Creation of temporary IPv6 addresses by generating a randomised interface identifier is optional. Client OSs may be configured to not use or to not prefer temporary IPv6 addresses.
Depending on your country of residence and/or your ISP's policies, there may be regulatory requirements to change an IPv6 prefix regularly, and that may also change on certain events like power-cycling a router.
The DNS protocol is unaware of MAC addresses, using IP address information to identify a requestor.
Pi-hole puts in additional effort (beyond DNS) to associate IP addresses to MAC addresses, by inspecting its host's ARP and IPv6 neighbour tables.
As MAC addresses are strictly same link only, those tables only holds MAC address information for devices on the same network link as Pi-hole.
Any client IP connecting through additional L3 network equipment (like a router or managed switch) would show under that equipment's MAC rather than its own.
Furthermore, MAC addresses are not guaranteed to reliably track a device over time, as modern OSs may randomise their MACs.
Being aware of this, you could consider to employ Pi-hole's experimental alias clients, but note that this would only affect Pi-hole's dashboard.
The best approach for reliable client identification is to force them to use IPv4 exclusively for DNS.
To that effect, you could consider to alter each clients IPv6 prefix policy tables accordingly.
But the easier way would be to configure your router to not advertise an IPv6 address for DNS at all (see e.g. Unresolved ipv6 adress in my top list - #4 by Bucking_Horn).
Thanks for the prompt reply and the clarifications. You are correct, IPv6 does not require per se clients to use and change temp IPs, but rather recommends it.
Bottom line is most modern OSes, at least the ones I've tried - Debian/Mint, Windows, Android, MacOS - use temp IPv6s by default, that change frequently (<1 week) and even every (interface) reset.
The same argument for MAC (in)visibility applies to IPv4 as well: if the pi-hole server is accessed through a gateway/NAT, all requests from all the LAN devices will have the same IP. The idea behind client MAC mapping is that many pi-hole users have relatively flat LANs, with the pi-hole server being part of that network.
In this regard, the alias clients feature sounds very promising and it would be great to have it in the logs too.
Unfortunately my tp-link router is very limited on IPv6 DNS options, allowing only ISP DNS or custom DNS IPs that must be non empty ( ::0 is 'not valid'). Again, the alias sounds like the right solution.
Another option is host names. Pi-hole will try to resolve your client's addresses to host names. Most often, IPv4 devices announce their host names during lease allocation and this should allow Pi-hole to obtain names for them. To ensure this, use either your Pi-hole as DHCP server or configure conditional forwarding accordingly.
Pi-hole does the same for IPv6 but actually goes a step beyond here: If there is no name associated with a given IPv6 address, we automatically revert to the network table to try to infer the host name indirectly by checking if there is an associated IPv4 address (via MAC address) and use their host name (if available). This will obviously only work in on-link sites, but, as you said, this is very often true for Pi-hole.
Example: If you have a laptop with host name laptop and IP address 192.168.0.12, Pi-hole will try to get the MAC address and store the relationship in the network table. Whenever a new IPv6 address comes up, we try to correlate via the MAC address to get the same host name for the same device.
There is currently a separate discussion going on where we are investigating a possible timing issue when your IPv6 address immediately makes a query and we try to resolve the name before the MAC address could be determined (this will obviously fail to correlate in this case).
In flat, one link only networks, you could consider to configure your Pi-hole machine's link-local IPv6 address in your router, which would prompt clients to use their LLA in their DNS requests to Pi-hole. LLAs have infinite liftetime (so no temporary addresses), allowing for more reliable identification.
Hi @DL6ER, thanks for the additional details, was not aware of that. While it makes sense, because IPv6s are - in vast majority of cases at least - global, they'd be resolved to things like syn-XXXX-XXXX-XXXX-XXXX-XXXX-XXXX-XXXX-XXXX.res6.spectrum.com, which definitely does not help.
For IPv6 in particular it may help to look up the host name based on the MAC too, then would be useful to return the shorter client hostname.
@Bucking_Horn Thanks, that makes sense, but not in tp-link world. Using the local address was the first thing I tried. For tp-link, link local addresses are not valid either - just tried with the latest firmware. It also comes with a Broadcom chip, so forget about dd-wrt or SSH access.
I don't think that would change.
Those are the correct official public domains, and as reverse lookups for public IPs would fall into the responsibility of public DNS, it'd commonly be your ISP that would run the authoritative DNS servers for them and provide those correct answers.
If you would want to undercut that, Pi-hole would have to deal with those reverse lookups as well, potentially by shadowing public DNS records. But in general, it's not a good idea to mess with public DNS. It may bite you back, e.g. when you'd want to run a public domain with HTTPS certificates.
That restriction may only make sense for your router's own upstream DNS servers, which would be a different router configuration option.
So just to be sure, your router does allow to configure an IPv6 address to be advertised as local DNS server to your IPv6 clients?
If link-locals don't work, you could consider to have your router advertise a ULA prefix, and use your Pi-hole machine's ULA address. That would at least avoid client address changes caused by prefix changes, and there's also a chance that clients would not use temporary IIDs for ULAs.
Hmm, yes, I do get your but also @Bucking_Horn's arguments. We could change the existing option
[resolver]
...
# Should FTL try to resolve IPv6 addresses to hostnames?
resolveIPv6 = true
to maybe something like
[resolver]
...
# Should FTL try to resolve IPv6 addresses to hostnames? #
# Possible values are:
# - "NO"
# Never try to resolve IPv6 host names
# - "YES"
# Always try to resolve IPv6 host names, if DNS
# resolution fails, try to obtain a related host name
# through the network table
# - "LOCAL"
# Only try to obtain IPv6 host names through the local
# network table
resolveIPv6 = "YES"
Any comments? Or is this maybe making things to complicated?
Indeed, when IPv6 is enabled, tp-link router will provide a DNS IPv6 server, either from the ISP or custom. The problem is the custom one format is very, very picky - perhaps something to follow up with tp-link, but honestly IPv6 has been around for quite a while and their implementation is probably rooted in some other (corporate) interests.
This "LOCAL" configuration option would solve my particular case. BUT the caveat would be if one wants to use a local pi-hole server to also resolve global queries, i.e. through a gateway, it would always get the gateway name - something in the line of @Bucking_Horn's valid pain arguments.
For this reason the alias client names feature starts to make even more sense at this point, but then at the cost of manually adding them. Looks like there is no elegant way out.
In my opinion these IP based hostnames (syn-XXXX-XXXX-XXXX-XXXX-XXXX-XXXX-XXXX-XXXX.res6.spectrum.com) don't have much real use, especially valid in the IPv6 case. So another option is to detect these IPv6 - and IPv4 to some extent - host names, then prioritize local or shorter names, if they exist. It is messy.
At the end of the day it goes down to what would be the easiest thing to do to make pi-hole even more versatile, to better cope with the emergence of IPv6 challenges.
This topic was automatically closed 7 days after the last reply. New replies are no longer allowed.