Pi-hole DNS server advertising using IPv6 SLAAC

Help
1

Expected Behaviour:

Pi-hole IPv6 DNS server address should automatically be added to clients using the Enable IPv6 support (SLAAC + RA) option in settings.

I am not using the DHCP server on my router for IPv4 or IPv6, for IPv4 DHCP is handeled by Pi-Hole, IPv6 is using SLAAC.

  • OS: DietPi
  • Hardware Raspberry Pi

Actual Behaviour:

This seems to work, but not for every device. Some devices seem to lose the IPv6 DNS server over time while the IPv4 server remains. Also wondering if my set-up is done well, and I made the right assumptions here. I just started using IPv6.

Debug Token:

https://tricorder.pi-hole.net/DVvJ3Fx5/

2

Could you elaborate on this?
What IPv6 address are those clients using for DNS (before and after they 'lose' it)?

Also, did you configure your router to stop distributing a local IPv6 DNS resolver address?

3

I decided to change my config and use a static ULA address for my Pi-Hole using this guide: Use IPv6 ULA addresses for Pi-hole - #5 by DL6ER
Now my router uses RA to distribute the ULA address to clients. This works perfectly for iOS and MacOS clients, but Windows only seems to use the IPv6 DNS server when IPv4 is turned off on the client.
When dualstack is used, Windows only uses the IPv4 DNS server instead of both. This seems to be a problem with Windows 10/11 and the RFC 6106 implementation.
Interestingly enough, the Windows clients did seem to get both IPv4 and IPv6 DNS servers when the option "Enable IPv6 support (SLAAC + RA)" was turned on in Pi-hole, but that option was quite unstable on my Apple clients (the IPv6 server dissapeared often).

4

Having either or server is fine. Both, the IPv4 and the IPv6 server will handle all types of queries just fine. There is no benefit in using IPv6 locally, it only starts to shine in terms of performance when packets have to cross a large number of routers.

1 Like
5

I respectfully disagree.

6

What is the advantage of IPv6 for DNS on your local network?

Whether the client gets to your DNS server (Pi-hole) via IPv4 or IPv6 on your LAN, it's the exact same path and endpoints.

9

Could you explain why?

I don't see how your linked article would contradict or invalidate any of DL6ER's statements.

1 Like
10

I might be a bit obsessive but I feel there should be a IPv6 nameserver involved in IPv6 deployments, so there could be full IPv6 connectivity (including DNS) which will benefit performance and prepare us for the future. Again, just starting to dive in to IPv6 personally so I might be overthinking it.

11

An IPv4 DNS resolver on your network can fully resolve both IPv4 (A) and IPv6 (AAAA) queries.

It's only when you need to connect to an IPv6-only destination that you need IPv6 active.

As an example, on a network running IPv4 only, including DNS and clients, here are the responses for A and AAAA requests sent over an IPv4 DNS path:

dig +short -t A cnn.com @127.0.0.1 -p5335
151.101.67.5
151.101.131.5
151.101.3.5
151.101.195.5

dig +short -t AAAA cnn.com @127.0.0.1 -p5335
2a04:4e42:c00::773
2a04:4e42:200::773
2a04:4e42:e00::773
2a04:4e42::773
2a04:4e42:600::773
2a04:4e42:800::773
2a04:4e42:400::773
2a04:4e42:a00::773

Same DNS resolver, no IPv6 path to the resolver, correct answers for both queries.

13

Aside from this discussion, can one of the devs elucidate what the option "Enable IPv6 support (SLAAC + RA)" does exactly and why it seems to behave differently from RDNSS on my router for Windows devices? Does it also enable DHCPv6?

14

AAAA records have been introduced to DNS almost three decades ago. Pi-hole has supported them right from its start.

There is no performance gain in a local network - queries will be handled with the same speed, regardless whether they are transported via IPv4 and IPv6.
IPv6 may put its protocol advantages in effect for longer multi-hop routes, i.e. when a client in your network communicates with a public server on the Internet - when compared to an IPv4 packet taking the exact same route, that is!

Querying Pi-hole via IPv6 does not speed up that communication - it does not affect that communication at all. It's completely irrelevant how your client has determined the IP address of its peer.

In the current transition phase, it is difficult to judge whether you would overall benefit from IPv6, e.g. your favourite website may run IPv4 servers world-wide so data is served from the closest node, while it may run IPv6 only in its head-office country, so IPv6 packets may actually take longer. Also, there are still a lot of IPv4 only sites out there.

It's true that IPv6 offers certain advantages over IPv4, but organisational and computational benefits (e.g. larger address space, easier renumbering, faster routing, less load on routing nodes) lie mostly with ISPs and Internet infrastructure providers.
None of those are really relevant within a home network.

For a home user, the only tangible advantage I can think of would be if you would run multiple publically accessible servers on the same port from your home network, which is but a bit easier and cleaner with IPv6 than setting up multiple forwards for different ports with IPv4.

Pi-hole does not configure a Stateful DHCPv6 server.

Enabling that option will have Pi-hole advertise its own IPv6 as DNS server via NDP/RDNSS RAs and reply to a client's Stateless DHCPv6 requests by adding the following lines to your Pi-hole's pihole-FTL/dnsmasq configuration:

dhcp-option=option6:dns-server,[::]
dhcp-range=::,constructor:wlan0,ra-names,ra-stateless,64

I don't know how that differs from your router as I don't know your router.
(I may not even know that if I would know your router.:wink:)

In general, you should configure your router to advertise Pi-hole's IPv6 address, or not offer any IPv6 DNS options at all.
So Pi-hole's option is primarily there to handle the case if your router wouldn't allow you to supply an IPv6 DNS server address, but only allow to switch off DNS options for IPv6.
Even then, I'd recommend not to use it, as IPv4 is fully sufficient to handle DNS in your home network.

2 Likes
15

Thank you @Bucking_Horn and others for the detailed explanation. While I did not fully accomplish my purpose (which might not be that relevant after all) I definately learned a lot from this discussion. It is great to see the time and efford you are all putting in this project voluntarily!

1 Like
16

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