Redundant NSD (master, slave)


as MIaB takes over the nameserver roles for my domain I’m somehow nervous about loosing access and services to my boxes. Therefore I would like to split ns2 from the MIaB box and mirror the config on another host.

Is there anybody who has tried such a setup or has it running in production?

I’ve found as an starting point, but it requires to change the main config on the master node (MIaB) and I’m unsure if this may break the admin portal or gets overwritten by next config change. Can someone comment on this?

Would others support a request for the improvement?

Best regards,

1 Like

This is referred to as ‘Secondary DNS’. MiaB is fully equipped to handle this in tandem with a proper secondary DNS provider such as or buddyns (just to name two).
Or the other option is to create your own DNS system which is what the linked article would help you to do. I have not read the article you linked, but from your comment, it is not necessary to change ANYTHING within MiaB’s DNS to achieve this, however it may not be quite as secure as it potentially could be.

There was a guide for setting up Secondary DNS linked from the installation guide, unfortunately that guide is no longer available. I have recreated it but it is not quite yet ready for publication. However the steps are simple.

If I understand your intent correctly I have two such implementations in production right now and let me tell you - it’s not fun. I might be new to Mail-in-a-Box but I’ve been managing many domains using CWP and I’ve delved deeper into DNS replication and safety than anyone should have to.

The PITA is that MiaB knows about secondary DNS servers and External DNS, but is yet to be tought about being a blind master to one or more secondary server. I’m set up to run two blind masters on my own servers which replicates to a DNS service provider which serves the public with their heavily protected and optimised infrastructure. My DNS servers are only open (at firewall level and in terms of ACLs) to the DNS provider’s servers coming in to do zone transfers. I can’t declare the dns service’s servers as secondary servers the way MiaB implementes it because the DNS records MiaB produces always puts itself (as as the nameserver in the SOA record and always includes its NS record in the file. I’m having to use External DNS and hand-edit the zone files to be suitable for public consumption. It works well, but making changes are painful.

Maybe this guide also helps? Guide: How to setup NSD as a secondary nameserver for Mail-in-a-Box

Thanks @KiekerJan. I’m confused though. On the maininabox homepage it is stated:

Please note that the goal of this project is to provide a simple, turn-key solution. There are basically no configuration options and you can’t tweak the machine’s configuration files after installation. If you are looking for something more advanced, try iRedMail or Modoboa.

My understanding from that and another reference which stated that mailinabox will overwrite changes to configuration as part of its self healing process is that any customisation I do in mailinabox that isn’t through the admin pages will sooner or later be overwritten and disappear.

There’s a huge amount of tweaking that is possible with almost all of the packages used but where is the line? How am I to know what I can tweak and expect to stay as I tweaked it and what will be subject to get reset the next time I run sudo mailinabox or the setup command?

In general this is a good principle to start from. A number of system configuration files are (re)generated during daily tasks, or on running of the Mail in a Box setup.

To know which modifications survive you should find out how specific configuration files are generated,which you can do by reading the source code. Of course, any such modifications should be accompanied by a disclaimer that they are not supported by the Mail in a Box community, so you are basically on your own in that regard. That said, there are usually people willing to answer questions even so. I consider this advanced usage of your Mail in a Box so putting in some effort might be expected. But in my opinion it is well worth it, as you can learn a lot about how your Linux server operates.

Specifically for the guide I linked though, the above does not apply. It is describing how to setup a secondary dns on another vps instance, so not the same as your Mail in a Box instance. The only change on the box is done via the admin interface which, as you already mentioned, survives the MiaB maintenance actions.

Some of the MIAB components (nsd, postgrey, spamassassin come to mind) have config systems which incorporate “local.cfg” files. For these, your local tweaks will be fine (if you put the changes in the local.cfg files).

Other packages (fail2ban) are setup less flexibly. For those, I have a couple of tweaks that get reinstalled after each MIAB update. If I get enthusiastic, I’ll get around to automating those config changes.

Not sure if @JoshData would be interested in a pull request for that config change automation. It sort-of goes against the approach of MIAB being a single, simple setup for basic mall.

I generally accept simple changes that allow for more flexibility in customization, but not the customization itself.

1 Like