I did mention that I set no A record for the domain, since I just want to test mail.
I tried with two different registrars, gandi and ovh. In both cases, the nameservers are replaced with those of the hetzner DNS service. I chose hetzner, because I like their Go API.
The ovh domains show something strange when I list the nameservers: 2 of the 3 nameservers have an Associated IP, which is the ip of the A record. The first nameserver has no IP. My Gandi domain has the same nameservers, but none of then show an IP.
The existence of A records is reported correctly in the admin page. I am confused by the nameserver/NS reporting. I am testing with subdomains, since I’m already using the main domains for other things.
I wrote a program that does all this automatically, so I’m confident that I do the same thing each time.
I add the _mta-sts TXT record with a more manual method, when it’s ready by MiaB. But since all the _mta-sts records seem to be the same in the same MiaB instance, I could add this earlier.
The MX record points to box.[primary-miab-domain]. All email-related records (autoconfig, autodiscover, mta-sts, have A and AAAA records that point to MIAB). The examples I mentioned are all secondary domains. The primary domain has all A records to make MiaB happy. My goal, as mentioned in the title, is to have the website for the domain somewhere else, so I point A/AAAA records elsewhere, or to nowhere at all.
I guess I’m confused about what you actually expect the subdomains to be doing here?
For the external DNS setup, you should have: example.com with an A record of whatever you want example.com to resolve to. box.example.com with an A record that points to the IP address of MIAB.
All the other A records for the MIAB specific subdomains.
MX records for example.com pointing to box.example.com
From my understanding this is what OP is aiming for – and is also the apparent source of his error in the status page.
I think you discovered the reason for the (seemingly) odd messages in a previous post:
After installing Mail-in-a-Box and trying it out, it is apparent that this project is miles ahead of it’s original scope (undoubtedly to the benefit and joy of most users!). Having said that, the Status Check page report could use some cleaning up for those who don’t require whole-domain (DNS!) management or superfluous webapp connectivity.
A separation of critical records – MX, SPF, MTA-STS, auto*. et al – and secondary results for add-ons like webmail, webcloud, static-page services would seem appropriate in a status report. Such separation would provide clarification on what is required to be correct for a functional mailserver versus what is additionally required for a more fully-fledged webmail+cloud storage application.
Considering the changes would be non-destructive (and, more importantly, not particularly vital) it might make a good issue candidate for a first-time pull request from an up and coming dev to take a crack at.
If you take a look at the status_checks.py script that generates the Status Checks, you’ll see almost everything you describe. For many of the checks, a result only shows up if there is an error.
I also added a workaround: The errors go away if I set the A record in Custom DNS. I’m using External DNS, therefore Custom DNS has no effect on DNS, but it fixes the status errors.
Regardless of the errors, my questions have been answered: The A/AAAA records for the secondary domain (@, and of course www) are not needed at all for mail functionality. There is no need for a TLS certificate on that domain either.
Are you saying you have external DNS doing all of the records EXCEPT for the A records of the secondary domain, and those A records are being handled by MIAB’s custom DNS?
All records are handled by external DNS. But this causes status page errors, unless I also set the A record at the Custom DNS. The custom DNS has no effect on the public DNS, since the domain nameservers do not point at it.
– but should I find time I will put it on my list.