MiaB as BLIND DNS Master

Improvements
21

@JoshData (and @KiekerJan et al),

I would like to formally propose official support for running the Mail-in-a-Box as a hidden primary if and only if two or more secondary servers have been nominated and those nominated (without the xfr; prefix) matches the name server records at the domain’s registrar.

I believe it would actually be quite simple to implement and can be done reliably and safely because of the available checks and bakances.

The changes I propose would have no impact on users who’ve never messed with secondary name servers or External DNS.

On the assumption that the options to appoint secondary name servers and/or deal with External DNS had been added because sufficient users had been asking for it in the first place I won’t be arguing the pro’s or con’s of having those options. The rationale I present instead is that when you make use of especially the External DNS option the loss of Mail-in-a-Box’s exacting command of the required DNS zones is not only unfortunate but unnecessary too.

With a few minor changes in the zone file generation code and modifications to the Status Checks called from the Admin page, a large proportion of users currently using External DNS would benefit enormously from the direct propagation chain that would be created from the Mail-in-a-Box server to their External DNS service to ensure the zones are always exactly how they should be.

Of course there will be users with even more advanced requirements such as setting records in their external DNS zones that Mail-in-a-Box simply does not provide support for. If and when that happens I presume those users would either continue to use the existing External DNS options as is, refrain from using Mail-in-a-Box at all, or ask for support for their additional record types as well.

In my first draft of this proposal I listed the zone files as generated and as modified as per my suggestion but found that it’s too noisy with irrelevant details making it hard to see how simple the suggested changes really are. I’ve opted to describe the changes instead.

Assuming we are talking about MiaB being installed on box.mydomain.com serving email for mydomain.com and otherdom.net. we’ll find

If the administrators for box.mydomain.com need to use external DNS and elect to have only his secondary name servers hit box.mydomain.com with DNS queries (.i.e. if they elect to hide box.mydomain,com as the actual primary) then they’d fill in two or more names as secondary name servers in a new format wush as ns1.mydomain.com:1.2.3.3, ns2.mydomain.com:1.2.4.4, ns3.mydomain.com:1.2.5.5, ns4.mydomain.com:1.2.6.6 and check the option below that to remove the name server on box.mydomain.com from the list of nameservers for domains and replace the list of expected glue records with the list given as secondary name servers.

The expected result would be the following changes to the zone files produced:

In the NSD configuration all the secondary name servers provided are set up to be notified and authorised for zone transfers. If the hidden primary option is in effect, then the box.mydomain.com zone is only set up to notify and allow transfers for secondary name servers in the xfr:IP format (because the box.mydomain.com in the eyes of the rest of the world does not have a SOA record and zone file. It is simply a A record defined in the mydomain.com zone and used for multiple purpose such as MX and webmail access as per normal).

That’s what I propose. I do not consider this a definitive text on the matter, merely a proposal with some rationale and details as might start a constructive conversation. Feel free to rip it apart and suggest additions and alternatives of your own. The objective is to create a shared understanding of the opportunity that exist and if all goes well to expose a path towards seizing that opportunity for the potential benefit of many existing MiaB users.

P.S. I am aware that attaching such special meaning to the format in which secondary name servers are specified is a really idea. I am sure we can come up with a way to make the available options a lot more clear and foolproof. One example would be to have these replacement name servers specified in its own section of the admin page which provides for names and IP addresses. One can in that case limit both the names and the IPs to what is already specified as glue records at the registrar. It would also be possible then to show the user which of the name servers will have their A records defined by a zone managed by MiaB and which they need to ensure are defined elsewhere because they are not in a controlled domain. I just did not want to clutter my proposal for a slightly modified behaviour by MiaB with so many possible user interface modifications that the essense of it becomes obscured.