MiaB as BLIND DNS Master

Improvements
1

If you allow MiaB to be your domain’s authoritative server (NSD only does authoritative) then v67 does a brilliant job setting up all the necessary DNS entries (except for _smtp._tls :slight_smile:) for all the domains you’re serving. You can even declare a secondary DNS server which can be hosted anywhere or you (as the documentation puts it) ignore MiaB’s DNS completely and use a completely external DNS solution.

I’m new to MiaB but I’ve run most of its underlying services for many years and paid my dues with regards to setting up self-hosted authoritative DNS in a safe and performant manner.

I accept that it would be completely out of scope for MiaB to get involved in setting up external DNS servers. Yet it strikes me that a relatively minor change would allow the best of both worlds.

Let me explain.

At the moment, when you use external DNS, you’re presented with zone records (on the page as well as in zone file formal). If you declare one or more secondary DNS servers, those are included in the zone files and the nds configuration is updated to do the zone transfers provided uou have the secondaries set up to accept transfers. The assumption in both cases is that box.yourdomain.tld hosts the authoritative DNS records as ns1.box.yourdomain.tld.

The arrangement I am after and have found for many years to work really well, involves what the DNS providers and documentation calls a blind master. That is where the machine/software that sets up the appropriate DNS records uch as MiaB does is invivible to the public. There is no NS record for it in the zone file and the SOA does not point to it. Instead, the SOA and NS records point to a set of nameservers, typically hosted as secondary servers at a DNS provider (I prefer ClouDNS but it’s a common service) for which you declare the master server(s) by IP to be your self-hosted authoritative domain.

It idea would be to have MiaB do it’s good work keeping a tight reign on the DNS records required for safe email operations, but keep the actual server away from the treacherous public DNS territory. If you have to allow anyone on the internet to access your DNS server you also allow those who seek to disrupt you or others access to your server, and believe me, I’ve seen how the attempts to cause havoc skyrockets in the space of a month if your DNS server is accessible.

To do this, in my opinion, might be really simple. I suspect all MiaB needs is a way to set a flag telling the DNS generating code to exclude ns1.box.yourdomain.tld and ns2.box.yourdomain.tld from the DNS zone files completely and only use the servers provided as secondary servers without the xfr: prefix as the nameservers. This can be verified against what the registrar has configured for the domain.

I’ve not familiar with the code (yet) but I would not be surprised to find some pretty firm assumptions being made about box.yourdomain.tld and ns1.box.yourdomain.tld that might make the change I suggest a tough one.

If I have some indication that I’m not doing this for myself only, I could fork the project, make the changes and offer a pull request when it’s done.

For clarity the fork/PR would be to define a set of secondary DNS servers which replace ns1.box… and ns2.box… in nsd configuration and the DNS records generated. The result would be that MiaB stays “in control” of DNS but the server itself becomes a blind master so that only the secondaries (at an external provider) faces the public.

Is there interest in such an option?

2

I could be wrong, but I don’t think what you are proposing is possible, and even if it were possible, why would anyone want to hide their primary name server?

If you think it’s insecure to run the primary DNS server of your domains on your mail server, you should use external DNS and use MiaB purely as a mail server, as you would do with any other mail server solution. And yes, if you do so you have to manage all mail-relevant DNS records yourself, but they don’t usually change that often.

The only realistic way I can think of to avoid or simplify manual management of external DNS records would be to add API controls for external DNS providers to MiaB. However, this would limit the scope of the integrated DNS controls to DNS providers that offer such an API, and it would probably be far too much effort to integrate this for every possible provider out there, as these APIs are not standardised.

Or you could host your own authoritative nameservers, for example with PowerDNS, which provides an API for adding/removing DNS records. However, as with the external DNS providers, you would need an extension for Mail in a Box that can interact with the PowerDNS API.

3

Just for the fun of it and to see if I could get it to work I implemented this some time ago. See my fork at mailinabox/management/dns_update.py at master · kiekerjan/mailinabox · GitHub and look for hidden master. I got this to work and ran it for a while but I’m not using it anymore, so maybe it has broken :smile:
You will first need to setup the secondary dns servers. Then set the ns records at your domain registrar to include only the secondary dns servers. Then enable hidden master dns on your box.

One more advantage of a hidden master is that you don’t need to specify glue records for your box.

It would be interesting to get this to work, but I wonder if you could get it fool proof enough to make it available for everyone using mail in a box. I imagine lots of failure edge cases lurk in this area. I would therefore say that my implementation is proof of concept only, but definitely not ready for the masses.

1 Like
4

Ok, I have to admit that I was wrong :wink: I googled around a bit and learnt that “Hidden Master” or “Hidden Primary” is definitely a thing.

Again, I could be wrong… :wink:

…but if I understand everything I’ve read correctly, you just need to make sure that the secondary servers are able to update the zone information before the TTL in the SOA record expires, which could be easily solved with a cronjob that runs nsd-notify once a day and pushes the zone information to the secondaries? Or am I missing something?

5

Yes, exposing your server on port 53 to thw world increases its attack surface and because DNS is full of smal requests which generate large responses even when rejecting the request, a server (having to) respond to TCP/UDP on port 53 becomes part of DNS aplification attacks which forms part of DDOS schemes.

Also yes, the solution as you suggest is to use external DNS. I’ve already acknowledged that and it is what I am alrady doing, twice over, in production.

The trouble icomes into that part where you also say " if you do so you have to manage all mail-relevant DNS records yourself". Technically you’re right, but what I am suggesting avoids exactly that. Managing the DNS records yourself is cumbersome especially because they don’t change that often. Soon enough you forget the details of the changes reuired between what your fancy DNS record generator produces and what is in your zone files, or you get used to it being not that different, and before you know it important changes like keys and serials are no longer getting pushed out to the external DNS and all the good work done by MiaB goes to waste.

It being all you can think of doesn’t make it all that can be done. There’s no need for API’s or additional procedural work. All the known DNS servers based on the published and accepted standards already does exactly all we need. Promise. We only need to inject the right configuration and whichever servers the secondary DNS servers are using will get the job done very elegantly.

Again, no API required regardless of how/where you host your secondary DNS server. The stock standard DNS propagation logic is more than enough.

Of course it is possible, and desirable. It’s not about hiding your primary name server but about ensuring the primary name servers the world sees are seriously hardened by people who look after that 24/7 while you (with the help of MiaB) diretly controls your actual authoritative name server as accurately, reliably and quickly as possible.

1 Like
6

Yes, in the meantime I have learned that this is indeed possible.

However, I am still not sure if I would prefer this to using external DNS, as it would make Mail-in-a-Box a single point of failure for your DNS zone(s) again. So, unless you are constantly adding and removing mail domains to and from your box, I’m not sure that’s worth it. I can see the (rather small?) security benefits from not having to expose port 53 on your box when letting MiaB manage your DNS though.

7

I saw it. I’d be surprised if it kept working without the unintended consequences users call bugs. :slight_smile:

It’s an advantage yes, but also a burden because by first looks at the code it looks like a lot of the MiaB DNS code is built with pretty hard assumptions regarding not only glue records (that needs setting up and checking) but also around managing the “PRIMARY_HOSTNAME”'s DNS records are then assumed to be ns1.‘PRIMARY_HOSTNAME’ and ns2.‘PRIMARY_HOSTNAME’. When the server is placed in ‘blind master’ or ‘hidden primary’ mode it should ideally not even generate zone files for the PRIMARY_HOSTNAME itself as the host’s name will just be an A record in the primary domain. But that’s perhaps too tall an order. The PRIMARY_HOSTNAME zone doesn’t really hurt anyone and doesn’t really need to go to any secondary DNS server anyway, so I’ll not object if it’s sticks around even when MiaB is in blind master / hidden primary mode. The important part is to prevent ns1. PRIMARY_HOSTNAME from being the name server nominated in the SOA and to prevent that NS record from being included in any zone file destined for public consumption.

Foolproof enough for the masses, that is indeed the challenge. (Given the addage that no system is foolproof to a sufficiently ingenious fool.) I cannot guarantee it, obviously, but I suspect that with the cooperation of the people who designed and wrote the existing MiaB DNS management code we can initiate the required changes at the correct level, design the conditionals and options by which to set and check the options (i.e. a little more explicit and manable than 'os.path.exists(“/etc/usehiddenmasterdns”) with all due respect) it need not be any more demanding on users than appointing a secondary server. It’s just a flag, as far as they are concerned, in the user interface, saying “Include ns1.box.mydomain.tld” in zone file or not?" and the rest we can do in code. It will be helpful if we also write some additional text that explains that a) setting up secondary servers has always and will always been an advanced topic requiring work MiaB cannot do for you and b) explaining that many cloud based DNS providers will sell you a secondary dns service you can merely point to using the addresses they provide when you’ve signed up.

All in all I think if this is a project it can go one of two ways - either an impossible project because we’re fighting the project’s original designers all the way or a really simple and effective change because we we able to engage with the projects maintainers and contributors at the right level. I haven’t been here long enough to guess which way it’s going to go.

8

I’ve thought about this some more and I think the advantage of a hidden DNS primary only really comes into play if you separate everything completely, i.e. if you run the mail server, public DNS secondaries and hidden primary on completely different servers and the hidden primary is not exposed to the internet at all. And even then, the secondaries could still be disrupted by DDOS attacks, but your keys for DNSSEC and the administrative access to your DNS zones would be protected.

But if you go that far, you could also use a local control pane that manages the public DNS servers via an API. In this case, it would no longer matter which one of your public name servers is the primary one.

9

I’m sorry to burst you bubble, but the DNS architecture, just like everywhere else involving a ‘master’ has single point of failure built right into their DNA. The alternative is genuinely complex and not worth the effort, so until the entire structure of the Internet and its naming service changes, we’re going to have the situation where there is a single authoritataive source for the records in a zone. But luckily that is not the end of the story. Luckily we can designate a master or authoritative source that nobidy can get to except you and if you choose to a service provider you have a contract with. How you arrange for that server to be come up with the goods is your problem, and MiaB is a a fair choice for mail-centric domains. You can run MiaB on multiple machines and keep multiple copies of the data and all the cliud and physical backups you want, but in the end it will be, for a particular domain, one machine on which the domain in DNS terms has the mode “master” and from which all the other servers will get the records for that domain.

The risks of having your MiaB open to the public on port 53 are not small by any stretch of the imagination so the benefits of not doing that isn’t as small as you say. But it’s completely besides the point because what I am suggesting is an elegant mixture of still having MiaB manage your DNS and keeping your MiaB hidden from all but your secondary server(s) wherever they may be hosted. Yes, your firewall will need to have TCP/UDP port 53 open for specific source addresses, but there is a world of difference between opening up for specific trusted addresses and opening up for the entire internet which is what you need to do if you need your MiaB server act as primary name server for your domain.

About constantly adding and removing mail domains from your box, that’s actually less of a problem than only doing a small change every few months. When we do something often we remember the gotchas and tricks we need to do, but when many months down the track you need to or want to make a change, or you’re doing a routine software upgrade and the upgrade script prints out “updated DNS: OpenDKIM configuration” you a) have no choice but to go through all the zone files with a fine toothed comb to check where the changes have been applied so you can transfer those changes to the external DNS, or you don’t do it because you couldn’t be bothered or you can’t remember the details and slowly over time your email server leaks reputation because your DKIM records are not up to date or something like that.

I think we should consider this change on merit (i.e. without the usual blanket resistance to change)

10

Well, maybe. I think there are bigger attack vectors than a DDOS on port 53 on a MiaB instance, and if you’re really that concerened about it, you probably shouldn’t self-host DNS at all. But that’s just my opinion :wink:

But you don’t have to convince me either, I’m always in favour of options, however I’m not the one who has to implement and maintain them, so not my decission to be made…

11

That is exactly what it means and what I’ve said it means all along.

This I have acknowleged as well. The point is that there are people who does DNS hosting as their entuire business. It’s not a great idea to get locked into any one such service as the master source of your records, but as the public facing servers it’s brilliant. You maintain full control locally over your DNS zone(s) but they deal with the attacks and rampant bad behaviour on the internet on your behalf.

That would be a massive step backwards. Two steps actually. Apart from the odd Custom DNS entry MiaB essentially uses your meta-data to compile the appropriate set of DNS records for each zone. Even for A records you add it remembers to prevent those from being used as email sources. As far as email is concerned, that is perfect. You set up the metadata (essentially mailbox names and their domains, secondary server addresses and official name servers) in MiaB once because it makes sense there else it doesn;t work at all. To have the generated records go from MiaB straight to your set of public facing secondary servers is ideal. What you’re suggesting in that statement means taking the records MiaB calculates for you, visually comparing to what is in this other (possible external) DNS control panel and going through the motions to change them as required. It’s hard enough doing this by comparing files and remembering which differences are as they should be and which indicate a change you should propagate. Why on earth turn the only bit a computer can help you do into something you need to do visually yourself? Makes no sense.

12

Of course there are bigger issues. DNS when done right disappears into the forrest of issues one faces when running a live commercial website. And that’s almost exactly the point. You can’t afford to get yourself distracted by something as menial as manually keeping the DNS records of mail-centric domains 100% accurate. That’s a job an algorithm can do better and far more cheaply. MiaB runs such an algorithm brilliantly, but it all goes to waste because of the assumption MiaB makes about having itself as publicly accessible DNS primary or if that don’t work for you it’s your problem to get the right records into an external DNS. I understand why that had been the approach, but now I’m saying that there is a really simple way to have the best of both worlds - miaB controlling the records and keeeping them in perfect shape and enjoying the protection of having the public facing DNS servers as someone else’s problem.

13

If it will be of any help to someone, preferably one of the maintainers that’s already familiar with the dns generating code, I can produce two sets of files - one as MiaB generates today and one as they should be for MiaB to serve as blind master feeding an external DNS service. They’re small changes and could be extremely useful.

14

At the same time, I think it will be great if the MiaB admin interface offers an option to explicitly declare a server as using external DNS. Similar to " Using a secondary nameserver" but it can offer explicit options such as:

Mail-in-a-Box always generates the DNS records required for safe email operation. You can choose what it does with those records. Your options are:

  • Serve them directly to the public as your domains’ public primary name server
  • Serve them directly to the public and send them to secondary servers
  • Send them to secondary servers to be served to the public as if they are primary nameservers
  • Present them to you as administrator so you can implement them on an external name server yourself.

In the above suggestion, the third option is the new one, the others already exist.

The difference though if such an explicit option is set on the admin interface, it would allow the Status Checks to be far more definitive and accurate. There’d be no need for “If you have set up External DNS, this may be OK.” statements because the status check code would know for a fact which option you’re set up for and can further improve what the checks are checking for. For example, if the choice was made for an external name server or the new blind master option, then the glue records can be checked not against the mail-in-a-box convention of two name servers named ns1.PRIMARY_SERVER and ns2.PRIMARY_SERVER but rather compare the configured nameservers against what is published for the domain at the registrar.

15

Then I assume that you don’t expose the Mail-in-a-Box admin interface to the Internet either. If so, then your suggestion might make sense. But that’s not the way a MiaB instance is typically used.

My point was, if you really care that much about security, then you shouldn’t probably use an all-in-one solution like Mail-in-a-Box at all.

I mean, if there is a bug in the admin interface or someone gets your admin password, a DDOS on port 53 will be the least of your worries. So when I said that your hidden primary nameserver should not be exposed to the Internet, I meant that nothing on that server should be exposed to the Internet, and certainly not the admin interface that controls your DNS.

…but again, you don’t have to convince me, and I’m certainly not opposed to more options. :wink:

16

I recently made a network change where my ISP accidently left port 53 to my firewall open to all instead of the set of 6 addresses of my secondary servers. My firewall is also a (recursive) DNS server duly configured to only allow those 6 servers to reach the two (authoritative) DNS servers in my DMZ and deny other traffic. Here’s what happened. On day one all seemed to be OK. Traffic volumes normal. Two weeks later I noticed outgoing traffic on the graphs I wasn’t expecting and it disn’t seem to come from my servers. By day 26, when we finally found the issue to be servers from many places like China and Russia hitting my firewall with DNS queries designed to fail but each failure resulted in orders of magnitude more bytes going out than coming in. When we looked at the logs we found that it started on the day of the move with about 512kB going out but by day 26 it grew to 250Gb per day and doubling every few days. The list of addresses from which these requests came grew beyond the 2billion mark the monitoring software was prepared to report on. All because my firewall was responding negatively to queries it assumed it would never get because the ISPs firewall was previously configured to black-hole those. So the solution was simple enough - black-hold DNS traffic not from the select few sources in the ACL. But if I wasn’t running blind masters I’d have been forced to keep not only my firewall but also my DNS servers open to the whole internet and the solution would not have been so simple to implement.

That’s the reality out there. I’m not making this up or seeing ghosts where there are none. My ClouDNS provider is equipped to deal with this far better than I am, and if they are not, they still are in a better position to get better at dealing with it than I have time, energy or money to become.

The bottom line is that exposing your box’s port 53 is no small theoretical risk. There are people out there with either nothing bettter to do or some serious motive and major hardware that will find holes to exploit such as a DNS server that anwers all requests with NXDOMAIN errors or more. They start publishing the IPs of those servers as authoritative servers of rogue domains, dig around for some names and start watching how the world’s DNS infrastructure starts hunting for answers by querying lame servers including yours. Whatever their motives, they are succeeding and their impact isn’t negligible.

17

Well but the main point of Mail-in-a-Box is to provide an all-in-one-solution, and host the hole thing on a cloud VPS, not just the public DNS part. Becuause most home users or very small SMBs, have dynamic IPs and/or CGNAT, and can’t host a mail server at home or on-prem. So your usecase is a niche in a niche, and therfore probably out of the scope of the project. But again…

1 Like
18

I’m sure you realise, or soon will, that it makes no difference to the use-case I propose whether you self-host on your own network at home or in a VPS at a cloud computing provider. You’ll still end up paying for the traffic and all the other issues your box is facing because you must have it open to the world. The box itself, it’s management interface, API, SSH, IPAM, SMTP and Nextcloud all those you can easily limit to being accessible only from limited places such as your home network and your phone (which would proably be doing that via a VPN). But if your box is the public primary DNS for any domain it has to be open to anyone that might want to send you email which means look up your domain’s MX record which means having their recursive DNS servers contact your authoritative DNS server for that information. You cannot predict which server will want to do the lookup so you have no option but the allow the entire internet. You have a similar issue with port used for delivering email to your domain and just look how much effort and configuration it requires to get that under control so it doesn’t get exploited. Only the DNS thing is a bigger issue because for email you have to send more bytes than gets returned when you use that port whereas for DNS you can a) send a small UDP packet and get many times that back in a negative response and b) it’s rather simple to get all the DNS infrastructure in the word to help you execute your DDNS attack.

And if you’re in a VPS changes are better than ever that you’d want to use the External DNS option, which means you’re having to manually detect and make all the DNS changes yourself. The Cloud VPS case actually emphasises the need for the change I propose, not negate it.

19

Exactly, and of all the things that are exposed, DNS is the smallest threat imho.

I mean you have an admin interface that also controls your DNS, including API access via HTTP requests, you have a webmail client, you have Active sync, IMAP, SMTP, you have SSH, you have Nextcloud, and of all things, the primary DNS server is supposed to be the thing that has to be closed down. I have a hard time believing that this alone greatly increases the overall security of your box, or your DNS zones.

20

Well at least Port 25 has to be open to the world. And no I don’t use a VPN to access SMTP/IMAP or the webmail, because that would be far more inconvenient, than occasionally managing some DNS records manually. But that is probably a matter of opinion. :wink:

Matter of fact I used Mail-in-a-Box for many years and never had any issues with internal DNS, and as far as I know my server was never involved in a DNS amlification attack. :wink: