Domain A/AAAA records pointing elsewhere

melato · May 4, 2021, 8:35am

Using Mail-in-a-Box v0.53.

If a domain’s website (A record) and mailinabox (MX record) are at different IPs, using external DNS, then mailinabox shows several errors in the status page:
- Nameservers incorrect
- MTA-STS policy is missing: STSFetchResult.NONE
- Domain not resolving to box’s ipv4 address
- www. (what does www have to do with mail?)

It also omits the _mta_sts record from the zone file and does not include the domain in the TLS certificate(s) that it offers to provision. Mailinabox may still be able to process mail for that domain, but the plethora of red errors is disconcerting for someone who does not know the details about mailinabox and mta-sts and how exactly email works.

How do you get over this hurdle?

I thought that having a website and mailinabox for the same domain on different machines is a standard use case, because mailinabox should be used only for email, therefore the website for the same domain should be somewhere else. Then why does mailinabox want the ips for domain D and www.D to point to itself?

Probably mailinabox needs the A record in order to provision a TLS certificate for the email domain, and I’ve found out that without the TLS certificate, it does not enable MTA-STS. See Support MTA Strict Transport Security (MTA-STS) · Issue #1388 · mail-in-a-box/mailinabox · GitHub and management/dns_update.py (mta_sts_records).

But Let’s Encrypt just needs to access a verification file in http:///.well-known/acme-challenge/ , so if I use a reverse HTTP proxy to send those urls to to mailinabox, mailinabox would be able to provision a TLS certificate for the domain automatically, without needing the A record to point to itself. Mailinabox can verify http access to /.well-known/acme-challenge the same way that Let’s Encrypt does. It can put a file with a random name in /home/user-data/ssl/lets_encrypt/webroot/.well-known/acme-challenge/ and then try to access it with http, using the domain name with IPv4. I just tested this. The request goes out to my reverse http proxy and comes back to mailinabox. I suggest that mailinabox checks access to /.well-known/acme-challenge this way and does not require that A/AAAA of the domain and www to point to itself. I also tested that it works for the case that A points to mailinabox and for the case where mailinabox is the domain nameserver.

alento · May 4, 2021, 1:08pm

One has to look back at the history of the project to understand the thinking involved.

Originally, MiaB was created to be a simple, all-in-one solution for running a private email server. At the time, the thinking was ‘why not include the ability to host a static web page as well, since the box serves HTTPS anyways’. If you host your website elsewhere it is as simple as adding an A/AAAA record to point elsewhere.

The project has retained this functionality even though it has grown from what it was initially intended to be.

openletter · May 4, 2021, 1:33pm

What is everything, including not errors, for your domains?

This is what I see for a domain I have that is using Cloudflare:

example.com

This domain’s DNSSEC DS record is incorrect. The chain of trust is broken between the public DNS system and this machine’s DNS server. It may take several hours for public DNS to update after a change. If you did not recently make a change, you must resolve this immediately by following the instructions provided by your domain name registrar and provide to them this information:
show more

The nameservers set on this domain are incorrect. They are currently dell.ns.cloudflare.com; marek.ns.cloudflare.com. Use your domain name registrar’s control panel to set the nameservers to ns1.box.example.net; ns2.box.example.net.

✓ Domain’s email is directed to this domain. [example ↦ 10 box.example.net]

✓ MTA-STS policy is present.

✓ Domain is not blacklisted by dbl.spamhaus.org.

This domain should resolve to your box’s IP address (A 198.51.100.42) if you would like the box to serve webmail or a website on this domain. The domain currently resolves to 104.21.94.157 in public DNS. It may take several hours for public DNS to update after a change. This problem may result from other issues listed here.

www.example.com: This domain should resolve to your box’s IP address (A 198.51.100.42) if you would like the box to serve webmail or a website on this domain. The domain currently resolves to 104.21.94.157 in public DNS. It may take several hours for public DNS to update after a change. This problem may result from other issues listed here.

✓ autoconfig.example.com: Domain resolves to this box’s IP address. [autoconfig.example.com ↦ 198.51.100.42; 2001:db8::::::ba48]

✓ autoconfig.example.com: TLS (SSL) certificate is signed & valid. The certificate expires in 88 days on 2021-07-31.

✓ autodiscover.example.com Domain resolves to this box’s IP address. [autodiscover.example.com ↦ 198.51.100.42; 2001:db8::::::ba48]

✓ autodiscover.example.com: TLS (SSL) certificate is signed & valid. The certificate expires in 88 days on 2021-07-31.

melato:

But Let’s Encrypt just needs to access a verification file in http:///.well-known/acme-challenge/ , so if I use a reverse HTTP proxy to send those urls to to mailinabox, mailinabox would be able to provision a TLS certificate for the domain automatically, without needing the A record to point to itself. Mailinabox can verify http access to /.well-known/acme-challenge the same way that Let’s Encrypt does. It can put a file with a random name in /home/user-data/ssl/lets_encrypt/webroot/.well-known/acme-challenge/ and then try to access it with http, using the domain name with IPv4. I just tested this. The request goes out to my reverse http proxy and comes back to mailinabox. I suggest that mailinabox checks access to /.well-known/acme-challenge this way and does not require that A/AAAA of the domain and www to point to itself. I also tested that it works for the case that A points to mailinabox and for the case where mailinabox is the domain nameserver.

Maybe I’m just getting old, but I have diffifculty parsing long paragraphs of administrative configuration and actions.

The MiaB project is designed for a narrow band of usage. We regularly get advanced users who want MiaB to support every configuration under the sun, but this is imposssible. If it doesn’t suit your configuration, then you need to uninstall MiaB and configure your own mail server. I’m not saying this as a talk to the hand, it’s just the reality of mail servers. Take a look at postfix.org and dovecot.org and you can see there are infinite configuration options, and MiaB cannot support all of them.

blinkingline · May 4, 2021, 1:40pm

When I look at my status page, I interpret it this way:
Green = Oh, good, that’s what I expect to see.
Yellow = Read this message, do I know why the box is showing me this in yellow? If so, don’t worry about it. (Normally due to external DNS). If I don’t know why it is yellow, I figure out why it is yellow and take corrective action where needed.
Red = This is something wrong. I should fix it.

So, for the errors you meantion:

Nameservers incorrect - Note the error message says: “If you are using External DNS, this may be OK.” If everything is working and set up correctly, this yellow message is OK to ignore.
MTA-STS policy is missing: STSFetchResult.NONE - If you are using external DNS, you need to make sure that you have the appropriate DNS records configured to support the MTA-STS policy. Check the propagation of the text record for _mta-sts.domain.tld to start. You can find how that record should be set by looking at the External DNS page.
Domain not resolving to box’s ipv4 address. This check should only be done on the box.domain.tld subdomain. Even using external DNS, this should almost always be green. If it’s not, there’s probably a misconfiguration somewhere.
Alento covered this well already, so I won’t rehash it.

melato · May 4, 2021, 4:53pm

I mentioned only red errors. I append the whole status report for the secondary domain, replacing domain names and ip addresses with example ones:

	t3.example.net
	The nameservers set on this domain are incorrect. They are currently [Not Set]. Use your domain
—	—
✓	Domain’s email is directed to this domain. [t3.example.net ↦ 10 box.example.com]
	MTA-STS policy is missing: STSFetchResult.NONE
✓	Postmaster contact address exists as a mail alias. [postmaster@t3.example.net ↦ administrator@box.example.com]
✓	Domain is not blacklisted by dbl.spamhaus.org.
	This domain should resolve to your box’s IP address (A 203.0.113.1) if you would like the box to serve webmail or a website on this domain. The domain currently resolves to 203.0.113.2 in public DNS. It may take several hours for public DNS to update after a change. This problem may result from other issues listed here.
?	This domain’s DNSSEC DS record is not set. The DS record is optional. The DS record activates DNSSEC. To set a DS record, you must follow the instructions provided by your domain name registrar and provide to them this information:
	www.t3.example.net: This domain should resolve to your box’s IP address (A 203.0.113.1) if you would like the box to serve webmail or a website on this domain. The domain currently resolves to [Not Set] in public DNS. It may take several hours for public DNS to update after a change. This problem may result from other issues listed here.
✓	autoconfig.t3.example.net: Domain resolves to this box’s IP address. [autoconfig.t3.example.net ↦ 203.0.113.1; 2001:DB8::1]
✓	autoconfig.t3.example.net: TLS (SSL) certificate is signed & valid. The certificate expires in 89 days on 2021-08-01.
✓	autodiscover.t3.example.net: Domain resolves to this box’s IP address. [autodiscover.t3.example.net ↦ 203.0.113.1; 2001:DB8::1]
✓	autodiscover.t3.example.net: TLS (SSL) certificate is signed & valid. The certificate expires in 89 days on 2021-08-01.

openletter · May 4, 2021, 4:57pm

On the ‘External DNS’ page, does it print a TXT record for _mta-sts.example.net?

melato · May 4, 2021, 5:07pm

Yes, it does have a record for _mta-sts.t3.example.net, and I had just noticed that I had not set it. Now that I set it, the MTA-STS error went away:

✓ MTA-STS policy is present.

I have edited this reply accordingly.

So I only have 3 red errors left, which should probably be warnings or not there at all:
The nameservers set on this domain are incorrect. They are currently [Not Set].
This domain should resolve to your box’s IP address
www.t3.example.net: This domain should resolve to your box’s IP address

Also, here’s the relevant section from the TLS Certificates page:

t3.example.net No certificate installed. The domain name does not resolve to this machine: 203.0.113.2 (A), 2001:DB8::2 (AAAA).
autoconfig.t3.example.net Signed & valid. The certificate expires in 89 days on 2021-08-01.
autodiscover.t3.example.net Signed & valid. The certificate expires in 89 days on 2021-08-01.
mta-sts.t3.example.net Signed & valid. The certificate expires in 89 days on 2021-08-01.
www.t3.example.net No certificate installed. The domain name does not resolve to this machine: [Not Set] (A), [Not Set] (AAAA).

It seems that all mail-related errors are fixed, without provisioning a certificate for t3.example.net, so I take back the suggestion I made about about provisioning TLS certificates differently without checking the A record. Still, I would prefer if I wasn’t shown errors that are unrelated to MiaB operation.

openletter · May 4, 2021, 5:15pm

Okay, so I just realized you’re configuring the subdomain t3.example.net.

You have configured the _mta-sts.t3.example.net TXT record, and you are still receiving the error? You’ve verified the record resolves correctly?

melato · May 4, 2021, 5:23pm

All the mail-related errors were fixed once I set the _mta-sts.t3.example.net TXT record. I edited my previous reply to reflect this.

openletter · May 4, 2021, 5:31pm

Is this truncated? Seems like the name servers should be set and MiaB is finding them?

melato · May 4, 2021, 5:39pm

Yes, the nameservers error was truncated. The full text is:
The nameservers set on this domain are incorrect. They are currently [Not Set]. Use your domain name registrar’s control panel to set the nameservers to ns1.box.example.com; ns2.box.example.com.

I have also configured t2.example.net, where I set all A/AAAA records to MiaB, and it has no errors at all.

The t2.example.net warning says:
The nameservers set on this domain at your domain name registrar should be ns1.box.example.com; ns2.box.example.com. They are currently [Not Set]. If you are using External DNS, this may be OK.

melato · May 4, 2021, 5:44pm

This looks like feature creep. I wish you’d follow the instructions and use MiaB only for email, not for custom static web pages . I don’t use it for my domain’s website, that’s why I ran into problems that you may not see.

openletter · May 4, 2021, 6:05pm

This seems odd. Mine always report the current ns records.

blinkingline · May 4, 2021, 6:34pm

This normally indicates a problem at your registrar.

Something looks very wonky here in what you are trying to do. Normally this error applies to the domain for the box itself. I suspect something is not set up correctly in your DNS configuration, perhaps you are trying to alias the box and have that set up incorrectly.

Until you get the DNS issues resolved, it’s not worth looking at the TLS issues, since the certificate provisioning relies on the DNS to be set up correctly.

Shayne · May 4, 2021, 7:10pm

Assuming that the endpoint resolves via http request using the domain name, then any “problem” would appear to be with the inquisitor logic rather than with a registrar or authoritative nameserver.

blinkingline · May 4, 2021, 7:21pm

 # Check that the ns1/ns2 hostnames resolve to A records. This information probably
 # comes from the TLD since the information is set at the registrar as glue records.
 # We're probably not actually checking that here but instead checking that we, as
 # the nameserver, are reporting the right info --- but if the glue is incorrect this
 # will probably fail.

Hence the “normally” in my response. While there are certainly other things that could cause this to happen, the registrar information is a good place to start.

Shayne · May 4, 2021, 7:28pm

This error(?) reads as if the inquisitor logic not only expects a ‘===’ result to it’s own expectation, but didn’t actually find a result at all. Perhaps the error message needs improvement?

EDIT: Although I could see sane logic reflecting a response like this before global propagation has occurred.

blinkingline · May 4, 2021, 7:32pm

That error shows that no A record returned at all when querying the domain.

If the query comes back with something different than expected you would see an error like this one:

The nameservers set on this domain at your domain name registrar should be ns1.box.example.com;  
ns2.box.example.com. They are currently ns1.domain.tld; ns2.domain.tld; ns3.domain.tld. If you are 
using External DNS, this may be OK.

Shayne · May 4, 2021, 7:39pm

Assuming that a regular DNS lookup worked (e.g. access to /admin) then it stands that an A record was returned correctly for the user. I suppose some race condition might be met by an over-enthusiastic admin expecting results within a few minutes, however this thread is a few hours old.

blinkingline · May 4, 2021, 7:40pm

You’re making an assumption that the domain reporting the error in question is also the domain of the box. That’s highly unlikely to be the case, for the reason you describe.