That would be my assumption as well, and therein lies the rub. I really, really, really don’t want to be giving any of my DNS records any regular attention at all. If they need to be changed, let them change. MiaB is the tool I’ve chosen to trust to keep my mail related records in perfect shape. Because I develop a web service, I do have to add or change a custom A or CNAME record every now and then and I’m happy to do that using the MiaB WebUI, but then I don’t want to be saddled with the burden of going through the whole auditing process of what should and shouldn’t be in the set of changes I feed through to my external provider.
Am I the only one? Possibly. If I am I am pefectly content with the arrangement I’ve come up with for myself. If it turns out there are enough others suffering the consequences of using external DNS it would go against my nature to know how to take their pain away and not offer it to them.
From my perspective the assumption that mail related DNS records don’t change that often is a dangerous one I don’t want to make.
I should add that it seems logical that the people who choose to self-host email would tend to have a computing related background to start with. The unintitialised couldn’t be bothered beyond signing up for a gmail address or using whatever address their phone manufacturer, network provider, ISP or bank sets up for them, or their mailbox they get with their Microsoft365 subscription. That how the masses roll, oblivious to what self-hosting even means let alone what it takes.
Consequently, it is not that far fetched to expect that those who’d consider self-hosting, who’d look for something like Mail-in-a-Box, would be actively involved in the IT domain which today almost invariably means some form of web development is part of their lives. They might have big infrastructure including entire Microsoft Server eco systems to look after at work, but at home for their private stuff they have their reasons to have and run their own domains. Those who want to be bothered with the intracacies of what makes an email service tick will not choose MiaB but implement the packages themselves, so we can probably assume that those who end up choosing MiaB specifically have chosen it so they can set it up and forget it exists until it lets you know there’s a problem. But they will be interacting with it to set up custom DNS records in support of their web development work every so often. That doesn’t mean they’re signing up giving their email setups more time than it needs, only that they need to make sure their changes to their DNS zones don’t mess up the mail settings. I think anyone who hopes that MiaB would attract genuinely technically uninitiated people are being unrealistic.
Probably, but are you in a position to state that as an absolute fact? If Josh or anyone else discovers that something needs to be different my expectation of the MiaB is that it would make the change as required. There are multiple weekly and daily opportunities to do so, there are several packave updates happening all the time. I run sudo apt-get update; sudo apt-get upgrade -y; sudo mailinabox from the console when my daily status email tells me that there are packages that can be updated and there had been version upgrades since I first installed. So for all I know the DNS records can change at any time if and when they are required by best practices to be changed. If it’s not the case and the DNS setup is a once-off thing that happens only for fresh installs and when a domain is added then the value of trusting MiaB to keep my email and related DNS records in perfect shape is greatly reduced.
Let’s put it that way. I used MaiB for servral years and the keys never changed, also I don’t know any mail server appliance that does automatic DKIM key rollovers, which would be the only thing (besides a DNSSEC key rollover) that would require you to change any records, and a full DNSSEC rollover would even be require you to set a new DS record at your registrar, and then remove the old one after a safe period. Don’t know how you would automate that. Maybe if your registrar is also your DNS provider and provides an API for that you could automate it, otherwise you would have at least to use two separate APIs or do it manually. Trust me, even large companies don’t automate this, if they do it at all.
# Force the dns_update script to be run every day to re-sign zones for DNSSEC
# before they expire. When we sign zones (in `dns_update.py`) we specify a
# 30-day validation window, so we had better re-sign before then.
cat > /etc/cron.daily/mailinabox-dnssec << EOF;
#!/bin/bash
# Mail-in-a-Box
# Re-sign any DNS zones with DNSSEC because the signatures expire periodically.
$PWD/tools/dns_update
EOF
chmod +x /etc/cron.daily/mailinabox-dnssec
So at least for the sake of DNSSEC whether it’s enabled or not, I’ve witnissed the effect of this code (in the brief period I had tried running MiaB as primary authoritative) and I’ve quoted the code responsible for it directly from the repository, so two independently verifiable sources say you’re wrong about that.
I don’t want to be fine, call it my OCD acting up, call it whatever you want. I want to be perfect and that means forgetting that MiaB exists until it needs human intervention. As it stands it’s asking for intervention too frequently (because of the ppa sources for some of the packages that changes way too often - every weekend and after every weekend) but it’s OK, I log in, rerun the last commandline, press enter a little later when the upgrade wants to confirm which services to restart, and wait for the machine to reboot.
In case you wondered. I run self-host (my own physical hardware) on my own premises for 5 domains across two servers. One is for my personal email and email for my wife’s employees, and the other is dedicated to email verification emails from my website. I used to run Centos Web Panel for many years until it became apparent that they cannot deal not serving the web site on the same box. MiaB recognises that the www related records of a domain points to a different server and handles it gracefully. If I could afford it and I was willing to get into bed with any specific cloud provider I’d rent what I needed either from Microsoft or AWS or both. But they are all about customer lock-in and I am compelled by my web service business to avoid getting locked into any cloud provider at al costs. I remain compatible with them all but I run a Kubernetes stack on bare metal as starting point. On my Kubernetes stack I run a Phoenix LiveView application written in Elixir against a PostgreSQL PostgreSQL database also running in HA mode. LiveView can be rather demanding if you don’t handle it right, so most of my attention goes into getting the full benefit of that game changing piece of technology to achieve a result oganisations with a two orders of magnitude more servers than me would not touch with a ten foot barge pole. My application is designed from the ground up as a distributed app scaling first and formost horisontally. That way when I need more capacity in hurry, I can rent containers from any of them while I roll out regional hardware to where it’s needed if that’s more economically which it normally is.
That’s all background stuff. The impact on my MiaB usage is that ideally I only want my daily email from it to say all is perfectly under control.
Yes, but this is not key rollover. It just re-signs the zone periodically because otherwise the signature will expire.
All it does periodically, and after every change you make to the zone file, is to increment the serial number in the zone file and then re-sign the zone using the same set of keys, and since it doesn’t generate new keys (just a new signature), you don’t need to change any records.
To-mah-to, to-may-toh. The serial changing is what triggers a zone update, so it happens, and when it is meant to happen but doesn’t the onus is on the user that dared to elect using External DNS to figure out what the changes are. If you yourself also added some records into the mix because you’re a developer trying to test a site or a certificate issuing protocol, then not only are you in a hurry but you also don’t want to be making mistakes that will cost you hours of waiting for a TTL to run down.
I don’t know as much about your use case and involvement as you know about mine, but you come across as seeing it as your assigned duty to tow the MiaB party line. It’s tiring and non-productive.
Again, no records need to be changed when the zone is re-signed. Or to put it simply. The box never changes anything on its own that would require you to change your external DNS records after you have set them up correctly.
And by the way, even if MaiB would e.g. automatically generate new DNSSEC keys (which it doesn’t), it would have no effect when using external DNS, because you are no longer using the nameserver on the box, but the external ones. That’s why the External DNS section of the admin interface says the following:
If you do so, you are responsible for keeping your DNS entries up to date! If you previously enabled DNSSEC on your domain name by setting a DS record at your registrar, you will likely have to turn it off before changing nameservers.
I won’t go into this because that would actually be unproductive. Just this much: I suggest you read up a little more on how DNS works in general and specifically DNSSEC, DKIM, DMARC and SPF, and then it might become more clear to you, why I made certain arguments.
I can’t explain it better because a) I’m not an absolute expert either and b) it’s a complex topic that’s hard to break down into a consistent forum post and I have other things to do in my life
