DNS names and ipv6

Help
1

I don't have a problem, just a question. I know ipv6 is a much discussed issue and I don't want to get into it in any depth here. I am slowly educating myself on it.

I have enabled ipv6 on PiHole. This has resulted, as expected, in ipv6 derived adresses appearing in the logs. I have set

RESOLVE_IPV6=yes

in pihole-FTL.conf to reduce the number of those addresses (combine them with ipv4?) The aim is to get a readable and decluttered dashboard. This appears to work for my linux laptops and desktops. Android is a different issue though and ipv6 and ipv4 are separate. I have created DNS name records for those ipv6 addresses. That works too, until the a device creates a new address! A game of whack-a-mole ensues! No problem, it's all in the name of learning and understanding.

My question is regarding PiHole's process around resolving ipv6 names, how it works and how/when do the DNS name records get used. A broad strokes answer is all I'd like. I'd ultimately like to remove all the DNS name records for ipv6 (cease the wam game!) and ideally have Pihole resolve all queries to the same record/IP/MAC.

Edit: all my android devices are set to use device MAC on their WiFi connections

2

You certainly would not want that? E.g. queries for google.com, discourse.pi-hole.net, www.mozilla.org all resolve to the same 1.2.3.4 IP?

I'm going to instead assume that you want Pi-hole to identify a requesting client by its name rather than by its IPv6.

Note that in contrast to IPv4's single address, a client always has multiple IPv6 addresses per interface from different ranges with different scopes and purposes by default (the most common ranges being fe80::/10 (link-local ), fd00::/8 (ULA) and 2000::/3 (GUA)).

With DHCP, a client may register a hostname during DHCP lease negotiation, and a router's DHCP server may or may not inject the respective DNS records into that router's DNS server.

While Stateful DHCPv6 would allow a client to supply a Client FQDN, the majority of IPv6 clients would not use Stateful DHCPv6 at all.
Instead, they construct their IPv6 addresses autonomously by combining an IPv6 prefix (procured from your router via Stateless DHCPv6 or RAs) with an interface identifier computed by the device itself using SLAAC.

Pi-hole can make an effort to try to associate the same hostname it knows for an IPv4 address to an IPv6 that originates from the same MAC, but that approach has its limits, as it is obviously bound to same link devices and affected by randomised MAC addresses and L3 routing equipment.

Furthermore, public GUA addresses are publically resolvable, i.e. your ISP would be authoritative for providing names (and often does so, by supplying generic names somehow encoding the IPv6 address).
And temporary IPv6 addresses are even intended to make it harder to identify a device, by regularly changing at least an IPv6 address's interface identifier portion - it would be counterproductive to assign a unique hostname to those that would allow identification.

To be able to identify clients by name in Pi-hole's dashboard, there are probably three different approaches:
a. encourage clients to use their link-local address when talking to Pi-hole
by changing their IPv6 prefix policies accordingly (requiring respective changes on each device)
b.configure your router to propagate your Pi-hole machine's link-local IPv6 along with its IPv4 as local DNS server
c. configure your router to propagate exclusively your Pi-hole machine's IPv4 address for DNS

While a. and b. should result in clients using a stable LLA or ULA IPv6 for their DNS requests, you'd still have to procure and maintain names for those IPv6 addresses.

In contrast, c. would have clients send their DNS requests via IPv4 exclusively, i.e. you would not see any IPv6 client addresses in Pi-hole's Query Log anymore. And as IPv4 addresses are usually easily associated with hostnames, this would be my personal recommendation.
Pi-hole would still happily answer any allowed request for an AAAA record with a set of IPv6 addresses, so dual-stack clients would retain their full IPv6 resolution capabilities.

You'd have to consult your router's documentation and support in order to verify whether your router would support that.

In any case, as long as your router is advertising its own IPv6 address as DNS server, any device may by-pass Pi-hole via IPv6.

It's crucial to find a way to configure your router to advertise no IPv6 DNS address at all, or at least propagate your Pi-hole host machine's ULA (or LLA) IPv6 as sole DNS server.

1 Like
3

That's correct.

Thank you, that little snippet adds to my knowledge base. Sadly, some of what followed was beyond my current level of understanding. I'll let it sit and come back to it.

Can I clarify something with the above, because it might be achievable.

My ISP (SFR in France) provided the router (appears to be an Altice GR140CG) and it is, to be fair, pretty flexible and I do have a range of options on it (though not to prohibit ipv6). It does however enable me to specify local DNS, both ipv4 and ipv6. I currently have my PiHole's GUA address in the ipv6 slot (ipv4 has the PiHole's ipv4 address).

Are you saying that if I remove that ipv6 address setting, that all client DNS requests would go to PiHole via ipv4? I assumed that if I didn't specify an ipv6 address that those requests would handled by the ISP's DNS. Sadly, there's no documentation with the router.

It may well be. There is certainly one device (a Fire OS tablet) that is bypassing PiHole.

Edit: I've removed the local ipv6 dns address from the router and I'll watch what happens.... straight away, I see an ipv4only.arpa appearing in the query log. Is that success?

4

No, I said:

I cannot know whether omitting an IPv6 address from your router's DNS configuration would prompt it to advertise its own address or that of your ISP's DNS server, or none at all.
You'd have to investigate that yourself, either by finding relevant documentation or by trial and error.
The latter is always worth a try. :wink:

If you delete that IPv6 address and dis- and reconnect a device to your router, you could inspect its DNS servers (e.g. by looking into /etc/resolv.conf on Linux, or checking ipconfig /all output on Windows). And you could check if nslookup pi.hole resolves: It would be most significant if it doesn't, and then the server line from its output would tell you which alternate DNS server had been used for that request.

By-passes may also happen with certain software, e.g. if a browser would be configured to use DoH encryption, it would talk to DoH servers instead, so DoH needs to be disabled.

5

Which is what I have done.