I’ve searched for the answer and tried multiple things (dns_update.py, ttl.py, zonefile.py, etc.) and eventually found a github mention to setting DEFAULT_TTL in /etc/mailinabox.conf
I set it, made an update via the web admin, and all zone files were updated with the DEFAULT_TTL. I thought I was finally all set with a simple and working solution … not … Two problems:
-
The box.domain.com zone files do not use either PUBLIC_IP or DEFAULT_TTL
-
I have no idea why, but although the zone files WERE updated at some point with the desired TTL, after a reboot they’re back to 86400. Yes, mailinabox.conf still has the DEFAULT_TTL entry.
Has anyone solved this? A hard-coded TTL of 86400 and inability to change the public IP are real impediments to manage the servers … especially through upgrades requiring a new server build.
From your question I deduce that you want to change the ip address of the box, and that you want to lower the DNS TTL to make propagation of DNS entries quicker. Is that correct?
In the meantime I can offer the following:
- I think you got DEFAULT_TTL from this pull request which was never incorporated in the Mail-in-a-Box release. Setting DEFAULT_TTL should thus have no effect.
- The short guide to changing the ip address is:
** Change IP address of your box
** Run the mailinabox setup again
** Check the new ip address was taken over in mailinabox.conf
- Before doing this, I recommend setting up secondary DNS to decrease downtime of the box
- If you want to manually change the TTL look at this code. If you change that line, and restart mailinabox, a shorter ttl will be used on the next dns update.
Hi, thank you for the feedback. Yes, that’s the pull request that I saw. What you’re describing suggests that I got caught in a case of correlation. At the time I had both dns_update.py AND mailinabox.conf modified to include the TTL that I want. Leading up to this … I had previously managed to get TTL to the desired value on the source system. I made the same dns_update.py changes on the new (v61.1) system and did NOT see the TTL updated. I concluded that the old dns_update.py hack no longer worked, and that’s what landed me at trying the mailinabox.conf change. Again, correlation, I went via the web admin to make a change to one custom DNS record, and the GUI confirmed that ALL zones were updated for some reason (I assumed the script saw a discrepancy in the DEFAULT_TTL value, and that triggered the update to all zonefiles) … and all zones ended up with the desired TTL. I incorrectly concluded that my last change (mailinabox.conf) was the cause … sounds like whatever happened at that moment triggered a DNS update, and that invoked dns_update.py to result in the modified TTL.
In that context, two follow-on questions:
- I’ve now updated dns_update.py again with the desired TTL, and I still don’t see the modified TTL. I’ve rebooted, made changes to individual custom DNS records, and the TTL remains the same. So, the question is, what action can I take to force a DNS update of all zones?
- Even if I get that to work, I am still left with the problem of the first zone that is created, the one for the box itself. I’ve never been able to modify that one, and it appears immune to dns_update.py.
So, we’re obviously into modification territory, so no warranties 
If you change something to the Python code, you first need to restart the Mail-in-a-Box daemon, so the new code is taken into account:
sudo systemctl restart mailinabox
To force a dns update run the following from your mailinabox root folder:
sudo tools/dns_update --force
1 Like
Awesome! Pieces of the puzzle are coming together … I’ve been in the general vecinity; thanks for the pointers! I can see - given the number of iterations that I’ve been through - the combination of factors in my case.
So, my remaining puzzle is the initial zonefile (the one created during install for the box, holding the NS records)? Any insights on that one?
PS - Warranties? What’s that? Sounds like an intriguing concept … 
I do not quite understand what you mean by the initial zonefile. I have files under /etc/nsd/zones for my domain which are all updated by dns_update, and a file /etc/nsd/nsd.conf.d/zones.conf which is also quite recently updated. Which one do you mean? Or something else entirely?
During initial setup when we answer box.domain.com, that initial setup creates the first zonefile for the mailinabox installation (box.mydomain.com). That zonefile contains the NS record entries (ns1.box.mydomain.com & ns2.box.mydomain.com). That zonefile is not updated by dns_update; all others are.
So, my /etc/nsd/zones folder has 81 files. I have 26 domains. I have both mydomain.com and box.mydomain.com zone files. The box.mydomain.com zonefile is the first one created after initial installation. That zonefile is not updated - no matter what I do. All other 78 files are updated (e.g., with the tools/dns_update --force command). In the dropbox in Custom DNS the box.mydomain.com is NOT listed (mydomain.com IS listed), so not possible to custom DNS edit box.mydomain.com. This initial zonefile appears to be a special case.
This is easy to replicate in a fresh install, so I know it’s not some interference that I’ve introduced through some customization.
I don’t have a zone file for box.mydomain.com, only for mydomain.com. Also, all the domain files contain the NS record entries. I wonder if the box domain file is actually used…
1 Like
Very interesting, indeed! Why would I have box.mydomain.com and mydomain.com separate? In full disclosure, I don’t name my box box.mydomain.com. Still, what you see is what I would have expected but is not what I see. I’ll play with the box name and see if that makes a difference …
Wait … as I’m writing this I may have figured out why … that may be coming from the VPS sysgen definition, not MIAB! I didn’t check before and assumed (yeah, I know) that MIAB took over all resolver configurations. But maybe that’s not the case. Thanks for that tidbit … that helps … I would have never seen that unless I went digging into the resolver BEFORE I installed MIAB, which I didn’t do.
In summary, what appears to have been the case:
- I had correctly modified dns_update.py with the desired TTL but had failed to restart the MIAB daemon (sudo systemctl restart mailinabox) after I made the change.
- I was unaware of how to trigger a DNS update (sudo tools/dns_update --force)
- I was distracted by the pull request referencing DEFAULT_TTL in the MIAB config file (/etc/mailinabox.conf), which DOES NOT WORK (would be very nice if it did, though).
- I was distracted by the VPS sysgen resolver configuration, which created a box.mydomain.com zonefile that I incorrectly interpreted as being under MIAB control.
Everything appears fine. Having a different perspective was really helpful. Thanks!!!
2 Likes