Supporting DNS either on or off of my mailinabox

Josh, I know that you’ve expressed a desire to focus on DNS-on-the-box. I think that optimizing for that makes total sense for a big set of users, but also is a blocker for other major uses.

Right now, my Mail-in-a-Box is being configured to do its own DNS. This is easy because I’m not using that domain for anything else (it’s eric@ericmill.com). It’s nice to have all the DNS just work, and keeps the instructions very simple, and doesn’t need DNS provider-specific instructions.

But if I wanted to actually migrate from my main email address (eric@konklone.com) to a Mail-in-a-Box, that implicates a lot of other subdomains and infrastructure that are currently managed in my external DNS provider (in my case, iwantmyname). I would be very loathe to suddenly have a suite of services all depend on the DNS managed by Mail-in-a-Box, whose tools and instructions are naturally optimized only for the DNS records needed for its own work. I would absolutely make the tradeoff of having to manage DKIM/SPF/DNSSEC/DANE records myself in this case.

Even if the main guide optimizes for DNS on the Mail-in-a-Box, I think managing DNS externally should be an officially supported path for Mail-in-a-Box, with a guide that handles just that aspect of the process, for people who want that to use.

I really don’t want to be fielding questions about DNS, or about boxes that are only partially set up.

Do you think it could be structured in an obviously DIY way?

Basically: okay, you want to host DNS elsewhere? Here are the DNS records you need, to get…

a) anyone to be able to send you mail (MX)
b) anyone to be able to receive your mail (SPF/DKIM)
c) no one to be able to read your mail in transit (DNSSEC)

…and how you get them set is between you, your DNS provider, and your god.

Okay… I just committed a change so if you run management/dns_update.py from the console it will list the DNS records + explanation.

1 Like