Changing router DNS to keepalived/pihole kills it

[michaelblight]

Actually - scratch all the below. If I try to set my router's DNS back to automatic everything dies as well. So I will have to think about this some more.

BEFORE EDIT:

I'm having issues that are only indirectly related to pi-hole, but struggling to find info elsewhere. I'm hoping somebody has seen similar, or has experience in this area.

Before making any of these changes, pi-hole was working fine with the router configured to use it as DNS and DHCP.

But now I have keepalived using VRRP to provide failover for DNS running on two pi-hole machines. It all works wonderfully if I set the DNS server to individual computers to the virtual IP as a test.

However, the minute I set the router (Netgear D6200) to use the same virtual IP as the DNS server, it kills the whole router and I have to reset it to factory settings. And since it's the gateway, nothing can access the internet during this time. I'm sort of assuming it's because the router is old, but I would not have thought the router would care much about how DNS worked, just where it was. So maybe if I buy a new router it will work?

It's a bit hard to see if anything is going awry in the pi-hole logs at this time, because when connectivity is lost, my Google Nest Home devices spam "connectivitycheck.gstatic.com" and swamp the logs.

As further background, the router does not do DHCP - the master pi-hole does. The whole plan is to allow DNS to keep working should I need to reboot/service the master. During this (brief) period I don't really care that there'd be no DHCP, until the master is back up again. As I say, it all works fine as long as I don't try and set it on the router too. And the DHCP seems to 'magically' hand out the virtual IP rather than the machine one, so "technically" I probably don't have to care about the router's DNS settings.

[Bucking_Horn]

DNS provides redundancy by allowing clients to make use of multiple DNS servers.

Since your Pi-hole is providing DHCP, you could have it distribute your two Pi-hole's IPs, and clients would switch to one or the other.

@michaelblight

However, the minute I set the router (Netgear D6200) to use the same virtual IP as the DNS server (...)

Your description would suggest that you are configuring your router's upstream to point to Pi-hole.

But as Pi-hole is your DHCP server, why would you want to point your router to use Pi-hole?

Pi-hole is already telling its DHCP clients to use it for DNS.

@michaelblight

when connectivity is lost, my Google Nest Home devices spam "connectivitycheck.gstatic.com" and swamp the logs.

This could hint at a DNS loop of sorts.

Please upload a debug log and post just the token URL that is generated after the log is uploaded by running the following command from the Pi-hole host terminal:

pihole -d

or do it through the Web interface:

Tools > Generate Debug Log

[michaelblight]

@Bucking_Horn

Since your Pi-hole is providing DHCP, you could have it distribute your two Pi-hole's IPs

This is a good idea that I hadn't considered. However, since pi-hole seems to be distributing the virtual address, it may not be necessary.

@Bucking_Horn

But as Pi-hole is your DHCP server, why would you want to point your router to use Pi-hole?

Really only to be confident nothing is pointing to the old IP address. I guess I'll find out soon enough when I stop that server.

Thanks for your help. The debug token url is https://tricorder.pi-hole.net/Jfg5UsCf/

In the log I noticed:

• It's finding the keepalived virtual IP (192.168.0.111) as the DHCP server. So I sort of have two DHCP servers, but they're both the same machine (as long as the master is running), so I assume that's not a problem.
• The DHCP range starts at .1, so I've changed this to .2 to allow for the gateway, but since it knows about it, I assume it wouldn't hand it out anyway.

[Moto]

If one Pi is acting as a dhcp server and hands out IP addresses then reboots causing the other pi to act as dhcp server how does your new dhcp server know what IP addresses the other pi allocated. It doesn't.
You need separate none-overlapping scopes on each server.

[michaelblight]

I don’t have DHCP running on the second pi-hole. I’m only trying to do it to handle DNS while the master is down for a short time. I don’t care that during this time there would be no DHCP server running. But yes, if I cared I would set them up as separate ranges.

[Bucking_Horn]

@michaelblight

This is a good idea that I hadn't considered. However, since pi-hole seems to be distributing the virtual address, it may not be necessary.

If you just need DNS redundancy, then IP address failover would not be the best fit, as it affects the whole machine, not just DNS.

If you are going to put your x86_64 machine to more duties than just DNS, it may negatively affect those other duties.

IP address failover works ok for stateless processing, but any communication relying on session states will likely fail on fail-over. DNS will work, but it'll confuse DHCP clients, e.g. when trying to renew leases from a machine, or a printing job talking to a CAPS service, or a caldav client syncing calendar entries.

If you do not need IP address failover for other reasons, and DNS redundancy is what you are trying to establish, then you should just offer a set of DNS servers to your clients.

@michaelblight

It's finding the keepalived virtual IP (192.168.0.111) as the DHCP server. So I sort of have two DHCP servers

Your debug log shows that only the DHCP server is responding on that very IP only.

It also shows a double assignment of that address to your enp0s3 interface:

   2: enp0s3: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc fq_codel state UP group default qlen 1000
   (...)
       inet 192.168.0.111/24 scope global enp0s3
          valid_lft forever preferred_lft forever
       inet 192.168.0.111/32 scope global enp0s3
          valid_lft forever preferred_lft forever
       inet 192.168.0.61/24 brd 192.168.0.255 scope global secondary noprefixroute enp0s3
          valid_lft forever preferred_lft forever

Note that the second assignment is for /32 netmask, i.e. an isolated address.
This may cause routing issues, unless that's how keepalived handles its IPs.

@michaelblight

The DHCP range starts at .1, so I've changed this to .2 to allow for the gatewa

You have declared your DHCP pool range from .1 to .255.
Your DHCP range should not include your router's IP, which you have fixed already.
It must also not include the broadcast address - for a 192.168.0.1/24 network, that would be 192.168.0.255.

[michaelblight]

I’m not interested in redundancy, just continuity during maintenance. I have set up two pi-holes on separate Proxmox machines under VMs running docker containers (the second is not running yet, but will replace the current .61 master). The master has nothing else running on the VM other than pi-hole, keepalived and orbital.

The intention was that when I wanted to do maintenance I would start the slave container and stop the master. Then vice versa when finished. I don’t actually have a need for both to be running at the same time. Maybe there’s a better way to do what I’m after?

[jfb]

@michaelblight

Maybe there’s a better way to do what I’m after?

Run two Pi-Holes in parallel (and independently). Advertise the IP of both as DNS servers. If either of the Pi-holes go offline, the other will immediately pick up all the DNS traffic.

[michaelblight]

Ok thanks. I’ll go with that then. I didn’t think i really wanted 2 running at the same time as it seems like overkill, but it’s simpler and they don’t use many resources.

I can’t find anything in the UI, so I assume this is still the way to tell pi-hole’s DHCP server about both DNS’s.

EDIT: A better way is mentioned further down in that thread to create a separate file so UI changes don’t overwrite it.

[Bucking_Horn]

@michaelblight

I can’t find anything in the UI, so I assume this is still the way to tell pi-hole’s DHCP server about both DNS’s.

Yes.

You can create a custom configuration, e.g. at /etc/dnsmasq.d/42-dns-servers.conf, with the following contents:

# distribute two Pi-hole IP addresses as DNS servers
dhcp-option=option:dns-server,192.168.0.61,192.168.0.62

@michaelblight

The master has nothing else running on the VM other than pi-hole, keepalived and orbital.

I assume orbital is referring to GitHub - mattwebbio/orbital-sync: Synchronize multiple Pi-hole instances?

If so, that would be another reason to always keep your two redundant DNS servers running. so you don't have to remember to trigger a sync and wait for it to complete after starting your second container.

[michaelblight]

Just updating on how I went with this.

• I had a DCHP/DNS server on 192.168.0.61 and have now moved to DHCP/DNS running on 192.168.0.161 and DNS on 192.168.0.162. They all run in docker btw, and I use Orbital to copy config from 161 to 162 every 15 minutes (it does not copy DHCP config).
• I no longer use keepalived to broadcast a virtual IP. I might try this again at some stage because with two DNS servers I need to pause both when needed, check two logs instead of one, etc.
• The DHCP server is handing out the two addresses for DNS - 161 and 162.
• The router is set to get DNS servers from the ISP, but has DHCP disabled, so the DHCP server (161) should hand out the correct IPs.
• The problem started because I couldn't set my router to use the keepalived IP without it crashing. But then every change I made crashed it, even when I restored from a backup. I reset to factory settings and applied each change manually and it seems happier now. I'm not sure I'm game to try it with a virtual IP again though.
• A bunch of IoT devices struggled. TP-Link devices kept the old DNS IP beyond the TTL period and did not change until I power-cycled them. Tuya devices kept using the old IP even after a power cycle. I found I had to start up the old DNS server with DHCP off (61), and with the new DHCP (161) advertising the new DNS (161 and 162). I still have the old one running but the query log has been empty for long enough. This is what I should have done from the start - look at the log and deal with each device separately.