Nope - seems like the branch switch did it. Tested it two more times now. After branch switch pihole is disabled by default. pihole enable took care of it, too easy...
Current situation related to the original issue of this topic:
With FTL version is release/v5.10.2 vDev-ccf8d15 (Latest: v5.10.1) AND REPLY_ADDR4 being set: everythingĀ“s working (pi.hole is correctly resolved)
With FTL version is release/v5.10.2 vDev-ccf8d15 (Latest: v5.10.1) and WITHOUT REPLY_ADDR4 being set: *** no internal type for both IPv4 and IPv6 Addresses (A+AAAA) entries for pi.hole available. for Windows client
With FTL version is v5.10.1 (Latest: v5.10.1) WITH or WITHOUT REPLY_ADDR4 being set: *** no internal type for both IPv4 and IPv6 Addresses (A+AAAA) entries for pi.hole available. for Windows client
Regarding 2.:
Sep 30 21:27:39 dnsmasq[30620]: query[A] pi.hole from 192.168.0.56
Sep 30 21:27:39 dnsmasq[30620]: Pi-hole hostname pi.hole is Pi-hole hostname
Sep 30 21:27:39 dnsmasq[30620]: query[AAAA] pi.hole from 192.168.0.56
Sep 30 21:27:39 dnsmasq[30620]: Pi-hole hostname pi.hole is Pi-hole hostname
ThatĀ“s a ( within a comment line (# comment with a (here and a ) there), not sure whereĀ“s the problem with it (but thatĀ“s a side issue I donĀ“t really care about, just FYI maybe itĀ“s interesting to you).
THX for that too, no idea why those guys exist multiple times in that file. Little extra benefit having devs and experts looking at my debug log. I like
By the way: those two lines are meanwhile in /etc/pihole/setupVars.conf again 2 times, donĀ“t know what action added them. Just FYI, I personally donĀ“t really care -.-
Thanks, we had a bit of conversation over there and I've also checked the configuration which is plain standard. This means FTL is unable to obtain any kind of information about the interfaces connected to your system. On none of the test systems we used during development, we've seen such a behavior which leads me to the question:
On which hardware is this system running? Do you use any kind of virtualization?
Raspberry Pi 4 on Raspbian. No virtualization. Only āspecialā config as mentioned is a virtual interface on top of eth0 which runs a separate IP address Pi-Hole is bind to.
When I'm configuring the virtual eth0:0 IP for IPV4_ADDRESS in setupVars.conf to as well as for REPLY_ADDR4 in pihole-FTL.conf, the latter still get's overwritten with the IP of the physical eth0: interface on every pihole restart (in my case the docker container).
There's at least one more "not so special" use case for using virtual interfaces: Running two (or more) pihole instances together with keepalived for failover. And this is exactly, why I'm running into this issue.
And it's a problem, because the failover doesn't work, if pihole advertises the physical IP instead of the virtual IP to clients. When the master node is gone, the virtual IP switches over to the backup node, but as clients got the physical IP as their DNS setting from the master node (which is down), they still try to reach the master node for name resolution. This would only work again, if the client re-connects or if the dhcp lease has to be renewed, in which case the backup node pushes it's physical IP to clients as the primary DNS.