Same configs, but different dns responses?!

General Beta 6.0
1

Hey guys, I'm sorry.. Im desperate .. :smiley:

I'm using 2 Piholes (v6 beta, up2date) + unbound for local DNS resolution + split horizon.

Locally, I have true DualStack available, so I'd like to use both IPv4 and IPv6 to get a better feel for it. Therefore, every device here currently has both an internal IPv4 and a v6 address... This will be important in a moment...

  • Devices freshly installed, Pihole installed, unbound installed. Did the same on the other device (same unbound config on both) - also installed keepalived for HA and that's about it.

Configured Pi number 1: set up local DNS names, groups, etc., exported settings, and IMPORTED them onto Pi number 2. Tested everything, and it works as usual... But when Pi number 1 briefly goes offline and number 2 takes over, it suddenly responds with IPv6 addresses - I've only done the name resolution locally in IPv4, and some services still depend just on v4 here..
I did not change any hosts file. Everything is configured via Pi GUI / unbound config.

The settings are the same on both Piholes, including the OS' of the hosts. The only difference is that one is connected via LAN and the other via WLAN... Oh, and number 2 also has Docker running. Could it be because of that?! I've been looking for ages and just can't see what the issue is.

Maybe someone here has an idea of what I could look into. I'm really at a loss...

Or how I can set it so that in such cases it responds with IPv4. Because in general, I don't want to completely disable IPv6 in the config... :confused:

Thanks!

The .99 is master and respnds with ipv4, the .11 slave obviously and returns an ipv6. The .254 is keepalived's vIP for both of em.

Edit: While reading this text again I wonder... Could it be possible this happens because Pi number 2 is answering for a c name of its own dns name?

Only services which have a c-name of "madPi" are the ones becoming ""unresolvable"" when Pi 1 goes down.

response

norm_ipv4_response

ip6_response
ip6_response278×607 79.1 KB

Log Nr. 1: https://tricorder.pi-hole.net/ahGpc3aq/
Log Nr. 2: https://tricorder.pi-hole.net/codl7BUv/

1 Like
2

Pi-hole's CNAME UI explicitly states:

The target of a CNAME must be a domain that the Pi-hole already has in its cache or is authoritative for. This is a universal limitation of CNAME records.

Your CNAME definitons use madpi as target, e.g.

     cnameRecords = [
       "radarr,madpi"

However, you haven't configured a local DNS record matching that hostname, only one for the FQDN:

     hosts = [
       "192.168.0.11 madpi.madstack.lan",

For CNAMEs defined in such a way (i.e. without a target domain existing within Pi-hole's scope), I would expect resolution to return the plain CNAME record.

This only may have worked coincidentally on your 192.168.0.11 host, as that is named madpi, and by chance on your 192.168.0.99 (named zeropi), if the Pi-hole on that machine would still hold a reply for an earlier lookup of madpi in its cache.

Your Pi-hole on your .11 would provide resolution for madpi from its hosts file, while the one on your .99 would have requested resolution for madpi via your 192.168.0.100, as defined by your Conditional Forwarding configuration.

The solution should be simple enough:
For each of your Pi-hole's, either point your CNAMEs to madpi.madstack.lan, or create a local DNS record for madpi.

2 Likes
3

Yes, thanks! That was the issue...
After I finally managed to get some sleep until the next morning, I immediately noticed that the entry was missing. Really awkward...

I added it back in, and lo and behold, the responses now look correct again.

Sorry for wasting your time with such nonsense—sometimes, one should just get some sleep and take another look afterward.

Thanks again so much for your effort!

Best regards :slight_smile:

P.S.: I'm not a native english speaker, so I think I understood that " dns.expandHosts" feature wrong - and because of that, I deleted those critical records while "testing"..

1 Like
4

Many of us aren't. We're always thankful for suggestions on how to make the documentation easier to understand.

1 Like