Hi. Using latest version of PiHole. For years I have had native IPv6 connectivity and PiHole is set up as the DHCP server so everything works well. The only issue is that the clients will show up in logs with the IPv6 reverse look up name that my ISP generates so it's sometimes difficult to tell which client is doing what. I note that the clients get the PiHole's IPv4 and V6 addresses for DNS servers. I would like PiHole to advertise only its IPv4 address so that it forces the clients to use IPv4 for DNS requests so I can see their names. How do I force PiHole to just advertise its IPv4 address for DNS? Is there a file to modify?
Just untick Enable IPv6 support (SLAAC + RA) under Advanced DHCP settings on Pi-hole's Settings | DHCP panel. 
That’s always unticked 
That would suggest that it is not Pi-hole advertising its own IPv6.
You could double check your /etc/dnsmasq.d/02-pihole-dhcp.conf.
Enabling Pi-hole's IPv6 support would add the following lines to that file:
dhcp-option=option6:dns-server,[::]
dhcp-range=::,constructor:wlan0,ra-names,ra-stateless,64
They shouldn't be in there if you've unticked that option.
The lines are not there. Maybe I’m also advertising through pfsense? I don’t remember doing it. I’ll check, thank you.
Could be.
For finding the RA that actually sends those RDNSS requests, you could consider installing radvdump, if that's available for your system.
Then run sudo radvdump and wait for a few minutes for the RA to appear.
It may take even a while longer before you happen to observe all relevant RAs on your network.
Look for RDNSS sections in the output where the IPv6 matches one of your Pi-hole's host. The router LLA at the top will at least tell you which device (but not which piece of software, obviously) has sent that RA.
That will look similar to
#
# radvd configuration generated by radvdump 2.17
# based on Router Advertisement from fe80::<issuing router IPv6 LLA here>
# received by interface wlan0
#
(...)
RDNSS <DNS resolver IPv6 here>
{
AdvRDNSSLifetime 3554;
}; # End of RDNSS definition
(...)
}; # End of interface definition
I will try when I get home. One thing to note is, I gave the Pi-hole its own, valid, static ipv6 address and that is the one that appears as the dns address on devices. I don’t even remember how I did that in the first place!
Holly molly! It's at least one of my AppleTVs that's sending those out. WTF? Have you heard of this? It seems to be keeping a ghost DNS server propagated in my LAN. Any idea on how to disable that?
Update: It's actually a bunch of my AppleTVs and HomePods doing it. Doing some preliminary digging seems to indicate that it's part of the "Thread" network advertising so that's why it's affecting DNS settings in Apple devices. Very rude. There doesn't seem to be a way to stop those advertisements.
I've never heard of something similar.
Are you sure it's the TVs link-local IPv6 that emits those RAs?
A guess:
Perhaps it might be doing so in order to offer its own wifi network for clients to connect?
Assuming that you have not configured this on those TVs yourself:
If they may have picked up and remembered that from an earlier router RA, they may probably forget about it after the RDNSS lifetime or the router lifetime expires.
If that would be the case, power cycling the TV could help, perhaps.
Another thought:
Maybe those devices are just repeating what they pick up from your router?
Remember: You would have to wait it out until you see an RA from your router itself.
But I'm really only guessing here.
If your observation persists, you should consider to bring that up with Apple's support.
Hi. Yes, I am certain those those IPv6 DNS addresses are being advertised by apple devices. My router doesn't do DHCP, only PiHole does. At some stage I may have selected the option to have PiHole advertise that custom IPv6 address (I made a simple one with the correct prefix and edited some config files on the RPi - the address is routable). Since stopping that option, I suppose the apple devices continue to advertise it as it continues to work. I suppose I could test this by removing that address from the RPi and see if it stops being advertised, I wonder how long it would take? This was one of the pages I found with info on it: AppleTV as resolver... why? | Page 2 | MacRumors Forums
Here's an example:
interface eth0
{
AdvSendAdvert on;
# Note: {Min,Max}RtrAdvInterval cannot be obtained with radvdump
AdvManagedFlag off;
AdvOtherConfigFlag off;
AdvReachableTime 0;
AdvRetransTimer 0;
AdvCurHopLimit 64;
AdvDefaultLifetime 1800;
AdvHomeAgentFlag off;
AdvDefaultPreference medium;
AdvLinkMTU 1500;
AdvSourceLLAddress on;
prefix xxxx:xxxx:xxxx::/64
{
AdvValidLifetime 86400;
AdvPreferredLifetime 14400;
AdvOnLink on;
AdvAutonomous on;
AdvRouterAddr off;
}; # End of prefix definition
route ::/0
{
AdvRoutePreference medium;
AdvRouteLifetime 1800;
}; # End of route definition
RDNSS xxxx:xxxx:xxxx::222 (<---This is the IPv6 address I created for PiHole and keeps appearing on Apple devices as a DNS server)
{
AdvRDNSSLifetime 1800;
}; # End of RDNSS definition
DNSSL lan
{
AdvDNSSLLifetime 1800;
}; # End of DNSSL definition
}; # End of interface definition
#
# radvd configuration generated by radvdump 2.18
# based on Router Advertisement from fe80::1463:6f65:ca53:4c31 <----This is a HomePod mini
# received by interface eth0
Just to be to sure:
For my system, a dump begins with # radvd configuration generated by radvdump and ends with # End of interface definition.
The bottom of your above output would thus suggest that we see a full RA of undisclosed origin and just the tip of a beginning RA for your HomePod mini?
That’s how each dump starts and ends for me. I just copied one of the dumps. And every time a dump has a dns advertisement it is associated with an Apple device (not necessarily the same one).
Edit: Ah crap you are right as always and my idiocy is in full display! Now it seems that that DNS advertisement is being sent by my router (pfsense). I'm not sure where that setting is. I will go to the pfsense forums. Thanks for the help.
This topic was automatically closed 21 days after the last reply. New replies are no longer allowed.