Ssl – Fixing invalid DNS records for mail server with SSL certificate

cname-recorddomain-name-systememail-servermx-recordssl

Ok, so the question name is a bit weird but I wasn't quite sure how to word it. I have a machine with the hostname foo.example.com with an SSL certificate for the domain mail.example.com. I have also have the following DNS records for example.com:

A     foo.example.com  12.34.56.78
CNAME mail.example.com foo.example.com
MX    mail.example.com

Now I have recently learnt that the RFC 2181 (section 10.3) states that the value of an MX record "must not be an alias".

My first attempt to fixing this would be to change the value of the MX record to foo.example.com, however this would cause problems as the name on the certificate is mail.example.com and I can not presently afford the expense of purchasing a new certificate.

My second attempt would be to add an A record for mail.example.com to point to 12.34.56.78 but the problem here is that the hostname provided by the SMTP server (Postfix) would not match the domain in the MX record and this may cause problems with some mail clients. Also, the reverse DNS record would not match.

Unfortunately changing the hostname of the machine itself to mail.example.com isn't an option as it is used for other things that use the other hostname.

Is there any other solution to this that I haven't thought of? Oddly enough it seems to have worked quite fine for the past year or so but as my configuring is actually invalid I'd like to correct it in case it is causing issues somewhere.

Best Answer

Yes, an MX should not point to a CNAME. In this case simply make another A record for mail.example.com:

 A     foo.example.com  12.34.56.78
 A     mail.example.com 12.34.56.78
 MX    mail.example.com

Since the certificate is for mail.example.com it thus matches the name used for connection and thus the certificate can be successfully validated. The PTR record should point back to mail.example.com to play well with spam filters.

Related Topic