AAAA_QUERY_ANALYSIS=no configuration


If IPv6 is disabled or not available from the user side, AAAA_QUERY_ANALYSIS=no should be automatically configured in /etc/pihole/pihole-FTL.conf


…and automatically enable it again if IPv6 is available (e.g. via “Enable IPv6 support (SLAAC + RA)”) at a later date?


You have to run pihole -r to reconfigure right? So…


Good suggestion, if the interface selected only has a link-local we could populate that in the configuration. The problem with auto enabling is that the user may not know that they have IPv6, or not want it used. Once the configs are installed and set, I’m not sure about modifying that without the users express instruction.


I agree, I opened this feature request because I’ve seen some posts like these both in reddit and here, some people will never check the wiki…


Though we may be able to set a toggle button on the web interface to modify that line via API in the future. For now we should probably just keep the scope to the installer and handling just the condition in the Feature Request.

1 Like

@Mcat12 or @DL6ER I’m looking at this again, it’s pretty easy during the installation to have this added to setupVars.conf during the address detection, but how would we go about removing it if the user adds IPv6 at a later date? Or is it something as simple as If no IPv6 address in setupVars.conf, then set AAAA to no, if it’s populated, set AAAA to yes?


We could have that mirror the status of the IPv6 address, the only possible issue is if the user set it manually and we change it on them without telling them.


That’s why I was thinking along the lines of checking to see if the value was populated at that key in setupVars.conf, it wouldn’t automatically set AAAA if the user manually edited the field, but if they chose an IPv6 address during setup, or changed the IPv6 address during a web session then we’d toggle the AAAA checking depending on if the field was populated. I’m not sure offhand how often we check setupVars.conf for content, but it could be added during a content check.

I think the best option would be to set it based on the installation process since we know at that point if AAAA blocking is possible. Modifying the YES/NO based on web session is something else that we’ll have to figure out the best options available so that we do not munge an existing preference, but I don’t see someone enabling AAAA without an IPv6 address in very many cases, or disabling AAAA if they do have an IPv6 address. And we’d have to look to see if it’s a GUA/ULA address and not just a linklocal. I’ll bring this up in Mattermost for some more talk about the possible implementations, and then we can update this topic after we have some time to think it over.