DNS fails on same day monthly

Unsupported Modifications
#1

Hey all,

I’ve been using MIAB for a few years now and enjoy using it greatly! So thanks to Josh and all the contributors.

On one of my servers though there’s an issue that keeps cropping up where the DNS fails to resolve on the same date each month.

The things unique about this installation compared to my other instances are:

  • Uses 2FA for all admin accounts
  • Has a mail relay (added rules to /etc/postfix/main.cf)

nsd’s logs look like:

[2021-07-10 13:52:30.653] nsd[967]: notice: nsd starting (NSD 4.1.17)
[2021-07-10 13:52:31.591] nsd[1014]: notice: nsd started (NSD 4.1.17), pid 967
[2021-08-09 13:43:15.692] nsd[1014]: warning: signal received, shutting down...
[2021-08-09 13:43:34.053] nsd[1030]: notice: nsd starting (NSD 4.1.17)
[2021-08-09 13:43:34.995] nsd[1075]: notice: nsd started (NSD 4.1.17), pid 1030
[2021-08-09 13:46:05.997] nsd[1075]: warning: signal received, shutting down...
[2021-08-09 13:46:05.999] nsd[1030]: error: xfrd: error writing shutdown to main: Broken pipe
[2021-08-09 13:46:06.024] nsd[13638]: notice: nsd starting (NSD 4.1.17)
[2021-08-09 13:46:06.171] nsd[13652]: notice: nsd started (NSD 4.1.17), pid 13638
[2021-09-06 17:57:40.649] nsd[13652]: warning: signal received, shutting down...
[2021-09-06 17:57:40.695] nsd[9177]: notice: nsd starting (NSD 4.1.17)
[2021-09-06 17:57:40.851] nsd[9189]: notice: nsd started (NSD 4.1.17), pid 9177
[2021-09-06 17:58:35.264] nsd[9189]: warning: signal received, shutting down...
[2021-09-06 17:58:50.863] nsd[979]: notice: nsd starting (NSD 4.1.17)
[2021-09-06 17:58:51.757] nsd[1022]: notice: nsd started (NSD 4.1.17), pid 979
[2021-10-06 06:30:07.902] nsd[1022]: warning: signal received, shutting down...
[2021-10-06 06:30:25.017] nsd[970]: notice: nsd starting (NSD 4.1.17)
[2021-10-06 06:30:26.046] nsd[978]: notice: nsd started (NSD 4.1.17), pid 970
[2021-10-06 06:33:08.774] nsd[978]: warning: signal received, shutting down...
[2021-10-06 06:33:08.799] nsd[7905]: notice: nsd starting (NSD 4.1.17)
[2021-10-06 06:33:08.897] nsd[7919]: notice: nsd started (NSD 4.1.17), pid 7905

I only noticed that the server was unreachable this morning.

To recover the server I need to ssh in using the ip, and run sudo mailinabox, then it is fixed for another month.

Has anyone else run into this? I’m on the latest (v0.54) and couldn’t put a finger on when exactly this started happening, possibly when I changed the ip address of the server. As the issue crops up even after reinstalling/upgrading, I’m unsure where to look to fix this, custom DNS records?

Any help would be appreciated,
Cheers

#2

possibly when I changed the ip address of the server

How did you do this?

The ip address is used in a number of configuration files. If you still know the old ip address you can perform the following search to see if that might be an issue:

cd /etc
grep -r 1.2.3.4 *
#3

Hey @KiekerJan

Thanks for the reply!

So what I did was capture a snapshot of the server on DigitalOcean, deploy it on a new machine with new ip, rerun the MIAB configuration - in the dashboard then everything looked correct and it had picked up the new ip address.

So I assumed (apparently wrongly) that if you do this it would also update the DNS records, which, it oddly did do in the admin dashboard, but searching for the old address as you suggest I can see it’s hanging around in all the nsd/zones/ files.

I guess my question now is, is it safe to manually update these files with the new IP? Equally, how is it that the server seems to currently function correctly whilst these are incorrect…?

#4

I think what you need to do is edit the file /etc/mailinabox.conf In there you’ll have to replace your old ipv4 and ipv6 addresses with the new ones. Then run the mailinabox setup once more. Alternatively, you could remove the PUBLIC and PRIVATE ip address lines (4 lines total). The setup will then figure out the ip addresses itself.
I am not entirely sure of the above, have never done this before, so it is untested. It would sure be nice if someone else could confirm this way ahead.

I have no idea, but not all configuration parts are depending on correct setting of the ip address.

#5

I have the exact same issue, every couple of months this happens. I actually got the same IP when we migrated to 18.04, (by doing a digital ocean restore) so something else must be causing this. I have to ssh in with the IP and run the setup again to fix. happens every few months.

#6

So the file in /etc/mailinabox.conf was the new ip address already.

I went ahead and manually changed the addresses in the nsd zones, so we may have to wait a month to see if that fixes it.

I’ve done in place upgrades using DO using the same method to keep the same IP and haven’t had this issue on other MIAB instances though.

If this is not fixed I may consider doing a fresh install and restoring from backup - I currently have all the user data on a DO Volume, @randy2134 are you using volumes too?

#7

Did you change only the files in the zones folder, or also the file nsd.conf?
Mail-in-a-Box checks daily if the files in the zones folder should be regenerated, so you might not need to wait a month.

#8

Only in the zones folder yeah, nsd.conf was correct, as it’s updated by MIAB from setup - this change just didn’t seem to get replicated in the zones files themselves.

#9

Okay so I’ve noticed that the overnight backups to s3 are not being performed despite re-adding the keys and I haven’t been getting the update email since changing ip, tried to run the daily tasks manually and this worked…
So the daily tasks script doesn’t seem to be run.

#10

Sorry for spam but seems to be a nextcloud issue:


aaron@box:~$ run-parts /etc/cron.d
/etc/cron.d/mailinabox-nextcloud: line 3: */5: No such file or directory
run-parts: /etc/cron.d/mailinabox-nextcloud exited with return code 127

Time for a reinstall?