[SOLVED] Swap of IPv4 MIAB PUBLIC_IP address

Morning all,

I’m preparing to swap my public IPv4 ( due to a large mail provider entirely blocking it and refusing and very slow to mitigate for a while now, which is causing significant disruptions for me and other hosted domains not able to send mail because of it ). My VM hosting provider supplied a clean new IPv4.

My question is could I have multiply PUBLIC_IP address in /etc/mailinabox.conf would the /mailinabox consider them? As for IPv6, I do have two public ones, and mailinabox does not take them into account had to do some manual editing.

Make sure you have a working backup, offsite! I had another VM spinned up and restored the current backups before the updates.

STORAGE_USER=user-data
STORAGE_ROOT=/home/user-data
PUBLIC_IP=139.xx.xx.xx
PUBLIC_IP=109.xx.xx.xx
PUBLIC_IPV6=2a01:
PUBLIC_IPV6=2a01
PRIVATE_IP=139.xx.xx.xx
PRIVATE_IP=2a01:
PRIVATE_IPV6=2a01:
MTA_STS_MODE=enforce

Besides the DNS entries, I will have these places where the IPv4 is used:

/etc/mailinabox.conf:
/etc/nsd/nsd.conf:  ip-address
/etc/postfix/main.cf:smtp_bind_address=
/etc/fail2ban/jail.d/mailinabox.conf:ignoreip =

The migration path is for in VM place; NOT a new VM/Host:

  1. Add the new IPv4 to the public ethernet interface as an alias & route on the fly and test if its reachable from the outside. As per suggestion bellow reduce TTL for all domains. and rerun “sudo mailinabox”

  2. DNS registrar’s side update ns1&ns2.box hosts and add the new IPv4 to the existing setup without removing the original IPv4 just yet - as this can take quite a bit of time up to 48h ;(.

  3. Add the new public IPv4 to the relevant configs and restart the nsd, postfix, fail2ban.

  4. Sit and wait for *h-48h, confirm new DNS glue records have propagated using public DNS for validation with dig +trace.

  5. DNS registrar’s side update ns1&ns2.box, check any any secondary NS if you have any and remove the old host IPv4, do not remove the old IP address under VM netowk settings on the hosting platform - Linode specific?.

  6. Go back to 4) If you have both public IPs you do not need to wait, as you VM can respond to both regardless of the DNS cache expire times.

  7. Reboot MIAB VM for the hosting provider to reclaim the old IPv4 (depends if you use DHCP or static netowrk configureation) and reconfigure the new IPv4 for my VM.

  8. After reboot, run ./mailinabox and check the configs above if they have picked up the change to the new IPv4 and remove keep the old IPv4 and route, as alias IP add on the fly, reload the services, and check the reverse record and MIABs and DNS records for the domains including the secondary ones but using an external public resolvers.

  9. Clean up the old IPs and configs, restore domain default TTLs.

Am I missing something?
** Update** All revised steps added with Italic+bold, some text stroked where needed.
Full disclosure: The Update did not go as I planned; I had more downtime than anticipated!! At 8. I released my old public IP from the hosting panel and could not use it anymore; I shot myself in the foot! And my two external NS servers - configured as secondaries got stuck with TTL of 24h! and were not picking the zone changes at all, regardless of the actions taken, including recreating the zones.
It could be a host-specific issue. I used my hosting provider’s NS as advertised servers in my domain registrar as well + ns1.box - it did take a day, and the public DNS was serving old/new records randomly. Finally, I got rid of them and used another DNS provider that worked in 30min.

Cheers,

1 Like

Yes. You are missing that all you need to do is to run sudo mailinabox once you have completed steps 1&2.

Though I would add it as your primary as MiaB is not configured for multiple IP addresses, so don’t waste your time trying.

Now, let me offer you a hint that will keep everything up during the propagation time period. Set up Secondary DNS as per my guide. Do this at least 48 hours before you change the IP address - or whatever value the glue record’s TTL is set to.

With Secondary DNS set up, only one of the two glue records will be affected so your service will not go down.

1 Like

Hi Alento,

Thanks for the input! I do have secondaries NS setup :wink:
The TTL times are very good point, and I usually do wind down TTL when doing changes for other DNS management systems ahead of time.

I asumed the times are low based on looking at the zone file for box.maildomain.com.txt where we have 1800s/30min!

Hmm, looking now for the second time NSD zone file for box.maildomain.com the default TTL time is:

:$ORIGIN box.maildomain.com.
/etc/nsd/zones/box.maildomain.com.txt:$TTL 1800; default time to live

But that is not the case for all the maildomain.com and the other hosted domains! Checking with “dig” revelead that all TTLs for maildomain.com and any other domains I’m hosting have TTLs 86400s/24h - that is a way too long… if there will be changes. Then I looked the domain.txt files and here it is ;(

$ORIGIN maildomain.com.
/etc/nsd/zones/maildomain.com.txt:$TTL 86400

Well, I’m now on step 6, and have not rerun “sudo mailinabox” as it’s messing up NSD and Postfix for my IPv6 as I have two public onces ( edge case ). But will wind down the TTLs first and give it some time. Thanks!

Do you know any way to do global TTL temporary override on all zones without editing every single zone file?
Update: found the template in the mailinabox/management/dns_update.py and modified lines to 1800 then ran “sudo mailinabox” it did changed all domains TTLs :wink:

   495	$TTL 86400          ; default time to live
   500             3600     ; Retry (when refresh fails, how often to try again, should be lower than the refresh)
   502	           86400    ; Negative TTL (how long negative responses are cached)

Do you know if the setup script accounts for multiply PUBLIC_IP address in /etc/mailinabox.conf? I’m lazy to case it down :stuck_out_tongue_winking_eye:
Update: it does not account for more than one IPv4&IPv6 per IF. Uses the first autodetected the primary ones

I think I may have found a bug related to the ns1&ns2,www A records for box.domain.com.txt. It looks like the setup is retaining an old/none existing IPv4 address on the A records for the box. zone only. But when I have the whole story will open a git issue. It does not seem to have an effect on the MIAB runing as Authoritative name server though.

Cheers,

This topic was automatically closed 40 days after the last reply. New replies are no longer allowed.