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.

22

Salut comment allez vous veuillez me faire part de votre service ?

23

Well, I hope Google translates accurately.
Who are you asking and what service are you asking about, please?

Eh bien, j’espère que Google traduit avec précision.
À qui demandez-vous et de quel service parlez-vous, s’il vous plaît ?

24

That’s quite a story, thank you for putting it here. :+1:t2: I will start out with noting here that I have no influence whatsoever over whether your proposal will be included in Mail-in-a-Box. I advise you to think about if you want to put in the time and effort if you don’t get buy-in from @JoshData

I hope I summarize your proposal correctly as follows:

  • Add a checkbox to the Custom DNS admin page that enables Hidden Primary DNS
  • The administrator can only enable this checkbox if at least two secondary DNS servers are configured
  • Enabling Hidden Primary DNS causes the changes you mention to the zone files served by NSD.

I do not quite follow all of your reasoning:

  • You state that one of the gains of your proposal is that many people using External DNS would benefit from a direct propagation chain. What in your proposal would enable that propagation chain? The point of External DNS is that Mail-in-a-Box generated DNS records are transferred manually. How would that suddenly be automatic?
  • I don’t follow the need and the structure of the proposed Secondary Nameserver format. What does the new format offer that the old one does not? Why include the own domain in the secondary server format? Shouldn’t it point to the secondary server, e.g. freedns.afraid.org? Why not use the current format which can be either the url or the IP address of the Secondary Nameserver?
25

Hi @KiekerJan,

Thanks for taking the time. Your summary is good. I hope to explain the parts you didn’t follow.

Perhaps it’s simply that I used the term external DNS wrongly or perhaps what I am proposing is sort of half-way between a secondary and an external DNS. Either way, what I am referring to is this:

In the existing implementation you have only two options. Either your box.mydomain.com is named in the SOA record of your primary domain as your primary name server or if you do not want that to be the case you let MiaB say whatever it wants in the zonefiles it creates while you tell some external/independent name server solution what records to serve including what server to nominate as primary nameserver in the SOA for each zone, what NS records to define and which nameservers to provide A records for. Those are currently your oinly options - automated or manual.

Whether the name for what I propose involves the name external DNS or not is immaterial to me. For the purposes of my explanation, I have called any DNS service that MiaB does not set up itself by the name External DNS. I might havedone better to call it something like “additional name servers not managed by MiaB”. They are servers like you can rent from many DNS service providers out in the internet or can set up on your own virtual machines or even physical machines if you have them available. Just like the article you referred me to suggests. MiaB has nothing to do with their creation, configuration or maintenance.

You’re right in saying that so far the point of what MaB calls External DNS had been that MiaB tells you on a web page with a file download option what DNS records it has determined are required and you are to manually see to it that the same or equivalent recrods are set up at your DNS server(s) that MiaB isn’t aware of.

Like I said, perhaps one could better describe the servers I refer to not as External DNS but as Seondary name servers, which they would be. I chose (perhaps incorrectly) to refer to them as External DNS servers because the word secondary if they were called Secondary Name Servers wrongly sets the expectation that the servers listed there are indeed secondary and that box.mydomain.com would still be the primary name server stated in the SOA. When the option I am calling for is active then box.mydomain.com would no longer appear in the SOA and no records for ns1.box.mydomain.com or ns2.box.mydomain.com would be included in any zone file. As far as the world is concerned, the first of the nameservers listed for the domain would be given as primary name server, the NS records would be for those servers (and none for ns[12].box.mydomain.com).

But MiaB would still be running NSD as always. MiaB would still be updating zone files as always. MiaB would however not respond to queries or transfer requests except from the IPs given as xfr:IP in the secondary name server configuration. It would be up toe the administrator of the actual name servers to ensure that the notifications and transfers are alloweed to come from MiaB’s IP as MiaB only controls itself.

I chose to describe the effect as having External DNS with automatic updates. If it gets more buy-in to define the notion of keeing but hiding MiaB as the actual authoritative source for the zones it knows about, then by all means let’s go ahead and define that concept and get the buy in. A rose by any name is still a rose.

More specifically to your question of “How would that suddenly be automatic?”, if you don’t get it yet, is this: The additional name servers (whether they’re called primary, secondary or external) would be automatically updated directly from MiaB by the exact same zone transfer (IXFR/AXFR) mechanism that xfr:IP, secondary servers and the rest of the world’s DNS propagation runs on.

I noticed in the code only after I compiled that description that the code at the moment does a DNS lookup for names it enounters on the secondary name servers config setting. I’ve not yet fully wrapped my head around that but it’s probably OK to keep doing that. I (wrongly) presumed that since both the name and the IP is required in the zone file (name in the NS records, IP in the A record if the nameserver is a subdomain of the zone file’s origin) that both would have to be specified in order to define replacement nameservers. An IP alone isn’t enough (because the reverse lookup might fail or resolve to an unintended name and the practice some refer to as private or vanity nameservers) so in terms of using the current convention on the secondary server config it is probably OK. I have noticed though that the description says to type in the name not the IP for secondary name servers and doesn’t mention the xfr:IP syntax, while the manual does state the xfr:IP format. Because we need both the name and the IP (which we can look up) it would be OK to allow those two options: either a fully qualified name or xfr:IP.

If I don’t get buy-in from @JoshData this project is dead and I will stay on the course I am on at the moment, which is to have a cron job copy the mydomain.com.txt and otherdom.net.txt files accross to my hidden primary nameserver, make the required changes to the files using a custom python script (that imports from dnspython) and trigger a zone reload. It solves my problem but nobody else’s.

26

Ok, it’s now clear to me that it’s a question of definitions. I think it’s clearest if we stick with the names that are already in use with MiaB, so:

  • External DNS: admin has to manually transfer DNS records to the desired DNS provider
  • Secondary DNS: admin can configure outside DNS servers which will be automatically synced with the MiaB DNS server. This is optional (but recommended)

You want to give the Secondary DNS system implemented within MiaB another option: to not publish the ns1.box.domain.com as nameserver, i.e. the hidden primary option.

I think you’re right and this is relatively simple to implement, building on already present functionality. If the option to enable it is guarded properly (e.g. checking for 2 secondary servers) it should also be able to not mess up people’s installations.

27

Perfect.

Since many DNS providers actually work with 4 servers rather than the minimum of two, I would suggest the check ensures at least two nameservers are provided.

I’ve been pondering how to deal with private/vanity name servers. It can get tricky to bootstrap a zone using vanity name servers using the technique of looking up the IP for the given name servers using DNS. It might need a section in the manual or admin screen to explain to users how to deal with that. It would normally have fallen under External DNS but if we’re moving the hidden primary option under Custom DNS / Secondary Name Server it becomes something we might need to address.

More importantly, how do we go about taking this forward?

28

This seems simple enough – granted I have only read through things once –

Add yet another checkbox which appears if using hidden masters:

Use vanity name servers? Y/N. If yes, then present the fields for the hostname and IP addresses (IPv4 & IPv6), which will then be added as A/AAAA records in the zone.

Whether or not implementation of that is as simple as it seems, I don’t know as I really have not explored extensively under the hood, and leave the technical stuff to the project maintainers and all the other wonderful people who keep this thing going.

29

As an edge case, yes of course. However, I cannot imagine that the project maintainer will be convinced, since it is such an edge case.

I know that I personally have been promoting using Secondary DNS for years now, but still find that the majority of users are still running MiaB’s DNS as a single point of failure.

Fork the project, code it, and then submit a pull request. But first be aware that @JoshData accepts very few modifications as he maintains a tight control of the changes implemented to the project. Mainly due to the lack of volunteers assisting with the project, and his lack of time to devote to MiaB with his other undertakings and life in general.

30

I’ve declared myself willing to do that, on two conditions:
a) I’d be doing it for the benefit of more people than myself, and
b) there’s some indication from @JoshData in advance that such a feature would fall within his vision for Mail-in-a-Box or not.
It’s not a big enough deal to cause division in the MiaB community. I’ve written a servicable python3 script (using the same dnspython library MiaB uses) that takes a set of zone text files and alters them as required by my hidden primary setup. If I’ll be the only user for this it would be perfectly acceptable to me to simply continue using that script to address my unique requirement for myself and only myself. Why would I even consider forking and changing the MiaB code for exclusive use? But if others will benefit and the maintainers will accomodate it of course I’ll make the effort.

31

Probably not, unfortunately.

32

I think I’ve seen your old posts. I’d have commented on that as opposed to starting a new topic if it hasn’t been closed already.

However, I don’t fully agree with the single point of failure as the primary motive for what I proposed and use. Yes, MiaB is a single point of failure for name resolution when it is running in its default mode, and yes giving the same IP address two names because a minimum of two name servers are required is a cheap trick. But truth be told MiaB is not the only distro to use that trick and though it flies directly in the face of the rules defined for a stable global DNS network it is not the worst sin. Besides, DNS itself has a single point of failure built right into the core of its architecture. The SOA record for a zone names one and only one authoritative name server for the zone in question. By DNS principles that is the master and the only master. If it fails the zone will eventually stop resolving as the caching servers where there might be copies of the zone runs out of time to live. the need for additional name servers doesn’t protect the data integrity of the primary server but is aimed at lowering the operational impact of a server or network link were to experience a temporary failure by providing access to (slave/secondary) servers that have copies of the zone ready. It also provides a way to spread the load of recursive servers querying authoritative servers for fresh copies of the data over multiple machines initially in a round robin fashion but then based on whichever server answers first. Those are concerns for massive name servers deployed globally. The typical MiaB zone is tiny by comparison, hardly big enough to warrant load balancing and it being about mail mostly, an extra few hundred milliseconds to resolve the mx record for a mail to be sent will be hard to notice amidst the other delays caused by MTA queues.

As I tried explaining, the motive for using a blind master / hidden primary name server isn’t fault tolerance but ensuring that the tiny VMs living on consumer-grade links on which we deploy Mail-in-a-Box do not get exposed to the badlands of the internet. We go to great pains to ensure that when we open our server’s SMTP and POP/IMAP are opened at the firewall level that it resists getting abused by nefarious players by hardening the software we use and supplying it with sufficient rules (DMARC, SPF, greylisting, et. al.) by which to discriminate between legitimate and illegitimate traffic. A LOT of what makes MiaB a good package is that it engages every trick in the book to keep the mail services from being abused.

But DNS is an entirely different animal with nowhere near the same sofistication with regards to controlling access. The biggest weakness is that even the bit of access control we have comes into efffect too late. Byu the time a DNS server says “I don’t know that domain” it has already been tricked into sending out much more data that the tiny UDP packet that triggered it. If you havn’t heard of it, it is called DNS amplification and it is a god-sent in the toolbox of the D-DOS attacker.

It is not impossible to defend against D-DOS and DNS ampliification, but it requires constant atteention and maintenance of lists of servers suspected of bad behaviour. That’s not a game we wish to or are prepared to play on our MiaB servers. Well, not me anyway. I’ve seen and felt the ill-effects myself and I definitely prefer to leave that arms-race in the hands of the professionals.

Luckily the DNS architecture allows for a very simple solution, provided you have someone willing to put up with Scar and the badlands. It’s called a blind master or a hidden primary and works as follows. The SOA, NS and glue records at the registrar are all configured to point exclusively to name servers run by such professionals who are vigilant and prepared for all eventualities. But that service provider needs the correct zone file / dns records to serve, otherwise it’s pointless. That’s where the ball drops on the floot quite often. There are as many custom APIs and file transfer methods to send records to a DNS provider as there are DNS providers. to each their own, for whatever reasons of customer lock-in it may be. As a result, those software solutions that endeavour to cater for all the different DNS providers out there, such as the Acme certificate manager’s DNS1 verifier, it’s a massive undertaking requiring a huge amount of code and configuration options.

But there is another way, completely standardised and supported by all DNS players - zone transfers. Zone transfers used to be one of DNS’s most exploitable weaknesses, but that’s been brought under control since. It is now entirely possible to safely allow zone transfers by ACL at the name server level as well as by IP and PORT at the firewall level. this means that an application like MiaB can write zone files locally any way it wants to, and then serve that up as a DNS zone. Which it normally does, only, it normally does so in a way that puts the name sefrver running on the server MiaB is running on right out there on the badlands alongside its MTA counterparts, but with nowhere near the same protection against abuse. The solution then is to tell the DNS provider not to expect itself keep the master copy of the zone, but to get the latest and greatest from your MiaB server using specifically authorised zone transfers. to the rest of the workd your DNS provider’s server(s) appear to be the primary name server for your domain(s) but it’s all pretend. In fact your MiaB server (generates and) hold the actual master copies of the domains and sends them to your DNS provider in a highly controlled manner.

I hope that convinces you that the use case for my proposed blind master (a.k.a. hidden primary) differs significantly from the dangers of having MiaB as single point of failure for your domain’s naming service. There’s overlap, for sure, but the primary motive isn’t redundancy and the operational stability of the DNS network, but rather ensuring your MiaB server has full control over the master copy of your DNS records while taking the server itself right out of that operational global DNS network.

1 Like
33

That’s OK. Less work for both of us then.

1 Like
34

This topic was automatically closed after 61 days. New replies are no longer allowed.