Lack of IPV6 aspects in documentation

Help
1

Dear Pi-hole Team

I asked myself the following questions and had a hard time finding relevant answers in the Pi-hole documentation:

  • How can one ensure, that no clients can bypass pi-hole via IPV6 DNS resolving? Especially in docker setup.
  • In the router config: Must "Local IPv6 DNS server" be disabled and/or "Announced IPv6 DNS servers" be configured with pi-hole's host IPV6 IP (if possible)?
  • What are the consequences if above is not possible? Only disabling IPV6 network wide?

Maybe I am missing something, but it looks like the Pi-hole documentation lacks some of these IPV6 aspects. At least there seems to be misleading or inconsistent information about how Pi-hole/router should be configured to enable IPV6 DNS blocking.

In the "Post-Install" section of the documentation (Post-Install - Pi-hole documentation and How do I configure my devices to use Pi-hole as their DNS server?) IPV6 is not mentioned at all, at least in method 1 & 2. In the articles in the "Router setup" section (e.g. Fritz!Box (EN) - Pi-hole documentation) it look's like it is recommended to "Distribute Pi-hole as DNS server via IPv6".

Above is supported by Bucking_Horn's statement in [Solved] Extra DNS server advertised with pihole as dhcp server saying "You'd have to find a way to configure your router to advertise your Pi-hole host machine's IPv6 as DNS server instead." But this contradicts Bucking_Horn's statement in Pi-Hole and IPV6 - How to make it work? saying "I'd personally go for NOT distributing/advertising an IPv6 address as DNS resolver - if that's possible with your router."

Maybe adding a paragraph in the "Post-Install" section of the documentation helps, so that all relevant information in easy to understand words can be found at one place and must not be searched in multiple discource posts. Not all users are network specialists and understand the discussions. :wink:

Besides this I missed some information in pi-hole's docker documentation regarding IPV6 (prerequisites). E.g. I assume it is recommended to setup the docker network with IPV6 support, right? This might not be the default config in some docker installations. Any other aspects that must be considered? Btw in https://github.com/pi-hole/docker-pi-hole?tab=readme-ov-file#deprecated-environment-variables "FTLCONF_LOCAL_IPV6" is mentioned but not described elsewhere in the docs.

My setup: Docker Tag 2024.02.2, Pi-hole v5.17.3, FTL v5.25.1, Web Interface v5.21 on Raspberry Pi. Turris Omnia OpenWrt Router.

Please apologize if I have overlooked something. Many thanks for this great product and your efforts for the pi-hole project. I am a satisfied pi-hole user since many years and appreciate your work (and donated as well for sure) :wink:

Best regards
Markus

2

I concur that the docs could need a bit of extra love for IPv6.

But the basic rule from the docs is quite simple:
Pi-hole has to be the sole DNS server for your clients.
This applies to both IPv4 and IPv6 alike.

Configuration details would be specific to a certain router model and firmware version.

By controlling your router not to propagate alternate IPv6 DNS server addresses, or none at all (especially in Docker setups).

The main goal is to have clients talking exclusively to Pi-hole, either via IPv4 only or via IPv4 and IPv6.
So either option will do, depending on personal preferences and router's configuration options.
Routers may allow to control none, one or both of those options.

If you can't control the IPv6 address your router is telling your clients to use, a client is free to use that IPv6 address at its own discretion, and thus will be able to by-pass Pi-hole.

If the router would allow you to control its upstream DNS servers instead, you may try to configure it to use Pi-hole for DNS.

This would only work if client's would use your router's IPv6 address for DNS. If your router tells its clients to use your ISP's DNS servers, clients would take to those directly, by-passing both your router and Pi-hole.

If your clients would talk to your router, and your router to Pi-hole, you would not be able to attribute those DNS requests to the original individual clients.

Also, this option may close a partial DNS loop if Pi-hole's Conditional Forwarding would be enabled, so should be used with care.

If the router does not allow to control neither its upstreams nor its local DNS servers, disabling IPv6 would be the only measure to prevent Pi-hole from being by-passed.

In cases where that is not possible or desirable, changing the router may be the ultimate option.

As you can see, there are quite a few things to consider, and one size does not fit all.
Statements from different topics are often tailored to the specific issue at hand: A suggestion I made in one case may not be appropriate for a user in another case. That does not mean they are contradictory.

In a similar sense, the options described in our Fritzbox router guide are to be viewed individually, i.e. they are not meant as 'do all of those for a perfect configuration', but rather as 'pick the ones that suite you best'.

No, you can stick with IPv4.
Docker is IPv4 by default, and its IPv6 connectivity is still considered partially experimental.

Fortunately, for DNS, there is no difference in functionality whether it is queried via IPv4 or IPv6 - it will deliver the same replies.

But as stated in the docs, Pi-hole has to be the sole DNS server for your clients.

If they would be aware of any alternate DNS server, clients may by-pass Pi-hole via that server - regardless whether that would be reachable via an IPv4 or an IPv6 address.

2 Likes
3

Many thanks for the detailed and quick response! This really helps.

I have decided to leave Docker on IPv4 only and disable "Local IPv6 DNS server" on my Turris Omnia (OpenWrt) router. i.e. no IPv6 name resolutions will be possible in my network anymore. (Further, I will try to add a FW rule so that connections to potential hardcoded DNS servers are also no longer possible.)

One additional question: What happens if a dual-stack client wants to communicate via IPv6? IPv6 communication to servers outside my network is still possible, correct? Are there fallbacks to IPv4 DNS resolution in place, which provide IPv4 and IPv6 addresses and can communication via IPv6 still take place afterwards (which I would appreciate, because they are "protected" by pi-hole)?

4

A dual-stack client will send an AAAA request to Pi-hole via IPv4, and Pi-hole will return a set of IPv6 addresses (if they are configured for that domain by the domain maintainers).
The client can then use any of the returned IPv6 addresses for communication.
If there are none, it will use an IPv4 from a respective A request.

1 Like
5

Many thanks!

6

As is alluded to here in this topic, I feel the router is key, to how ipv6 works on your network. I used to use my own router behind the AT&T fiber router. I can no longer do that. With the AT&T router set up in its 'as delivered' condition IPv6 is enabled but has very few settings (compared to openWRT or even other commercial routers) and there is no way to set up a private IPv6 prefix for my home. As I understand it, the IPv6 addresses it provides my network are world routeable. I turned ipv6 off in PiHole but my clients were bypassing the PiHole via ipv6 as the router was providing the ipv6 dhcp and DNS. To get any sort of ipv6 privacy, I have to disable ipv6 totally on the router and my clients.
I run a PiHole on an RPi and use it as my ipv4 DHCP server. I also put ipv6.disable=1 in /boot/cmdline.txt to ensure that ipv6 is not used on my network nor by the PiHole.
To be clear, the problem is not the PiHole, but AT&T and I just want consistency on my network so I turn it off in the kernel for the PiHole as well as on the router so that it no IPv6 is used here. Previously, I was able to use a privacy prefix on my local network and have my openWRT router handle all dhcp for ipv4 and ipv6 and maintain privacy as I understand it.
If I have any of this wrong, let me know.

7

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