SSL cert conflict on WebMail

#1

Hi, I set up a mail service for my own domain last week and things are great!

Today I am migrating a client who just signed up for the $50 plan. The two domains are tdwellness.com and onesmallbite.net.

I set up everything correctly with DNS and I have validated the SPF and DKIM and DMARC records for both domains. I can send and receive from a Mal client no problem.

As with my own domains, I am running DNS at my own server (in this case, a virtual server).

I installed the SSL cert for mail.onesmallbite.net and webmail.onesmallbite.net using the control panel here at MXRoute.

Yet, when I try to access the webmail “https://webmail.onesmallbite.net” the browser complains about the SSL cert conflict. I’ve either missed something or I’ve missed something??

DNS MX entries for OneSmallBite.net

							IN	MX	10	mail.onesmallbite.net.	
webmail						IN	A	116.202.222.109	
mail						IN	A	116.202.222.109

DNS MX entries for TDWellness.com

							IN	MX	10	mail.tdwellness.com.	
webmail						IN	A	116.202.222.109	
mail						IN	A	116.202.222.109

Here is a screen shot

Screen Shot 2020-03-22 at 1.23.43 PM

Screen Shot 2020-03-22 at 1.26.41 PM

#2

Thank you very much for bringing it to my attention. I fixed it. Here’s what happened:

On some of the first DA-based servers we’re seeing some intermittent overloading of Apache on webmail. The new server “echo” was to contain a new deployment that would resolve this, featuring Nginx performing a reverse proxy to Apache with caching to reduce Apache load. What I failed to take into account was that my custom hostname configurations were Apache-specific, so I’ve rolled this back now and will take it back to the drawing board. Significant oversight on my part.

#4

You are aware that by setting your own A records pointing to the IP address, you will get in trouble if Jarland migrates to a new IP at some point?
AFAIK it’s recommended to just use CNAME for mail and webmail for this very reason. :slight_smile:

#5

Thanks for the comment flips. I have been running DNS for my own systems since 2004. Not an expert, but very familiar. In my experience, if an IP changes, not only are you pretty quickly aware of it, but changing it is straight forward and easy. Bottom line, yes, if they change IP addresses, it can cause a problem. But there are SO MANY reasons why Jarland and any other admin would be very reluctant to do that. The goal of safeguarding the reputation of the IP address is specifically to avoid changing it. Also because in this case the CNAME would point to an MXroute domain it is not in the same domain as my record and results in additional lookups (AFAIK).

#7

Well, then I well make a change.

#8

So, Jarland, I found the original email for these domains:

DNS MX RECORDS:
echo.mxrouting.net (Priority 10)
echo-relay.mxrouting.net (Priority 20)
(These above are both record type "MX" and should have the name value set to either @ or blank, not a subdomain)

IMAP Server: echo.mxrouting.net
SMTP Server: echo.mxrouting.net

And my question is, which do you want used for the “mail” and “webmail” subdomians? I checked the guide and I’m not too clear on which in this case. My other MXRecord account used one server, not two.

So…?

webmail						IN	CNAME	echo.mxrouting.net	
mail						IN	CNAME	echo.mxrouting.net

or…

webmail						IN	CNAME	echo-relay.mxrouting.net	
mail						IN	CNAME	echo-relay.mxrouting.net

My assumption is the first one (echo.mxrouting.net) based on priority. Just want to be sure before changing.

#9

Jarland, one more question, you say you do it every few years. But do you provide a warning? If it’s a planned migration, I would assume that you warn people.

#12

RE:

but my deployments on this front have historically introduced problems in practice while only solving theoretical problems,

Yeah. I get where you are coming from. That’s why I used the IP instead of CNAME. If a service is stable, then the migrations are planned and admins can update IP’s. I also get not having to do that at all and using a CNAME. In code I’ve come to learn that 95% of queries written with the idea of being reused are never actually used more than once. Yet you balance that with some unified structure so that other devs can understand what’s going on. I just always felt that changing an IP in a DNS zone file and updating tithe serial was a very small price to pay for reduced DNS traffic. And in a time when the net is creaking under it’s own weight…

In any case, it’s pedantic on my part. I can make the change.

#14

OK, so I made the change from A record to CNAME. All of my DNS servers updated and I waited some time after they confirmed the record update. Yet, when checking with intodns.com, the “mail.domain.com” lookup failed. I have reverted to IP until I can get some info on how to resolve.

This works:

							IN	MX	10	mail.onesmallbite.net.	

webmail						IN	A	116.202.222.109	
mail						IN	A	116.202.222.109

This does not:

							IN	MX	10	mail.onesmallbite.net.	

webmail						IN	CNAME	echo.mxrouting.net	
mail						IN	CNAME	echo.mxrouting.net
#15

Looks like DNS is reverted to the A records as before now, and webmail works … Sounds like there was some DNS cache/browser cache issue, but hard to verify now. (I suggest joining the chat support next time, to get a quicker response.) :slight_smile:

#16

As of this moment I’m getting nothing returned from the NS for that:

 [root@gateway] ~ # dig CNAME webmail.tdwellness.com @8.8.8.8 +short
 [root@gateway] ~ #

I’d say just basic DNS troubleshooting at that stage.

#3

Thanks Jarland! I saw that it was working about an hour ago! It was one of those things where I was thinking, “OK. I know DNS is working and the cert is active, WTF?” And then assumed that maybe there had to be some other propagation around the net to make it work. Thanks for fixing it!

#6

Actually I usually do it every few years. Hardware upgrades involve the least downtime if the server is just replaced and both are online for a time on different IPs. I highly recommend using CNAMEs.

#11

Kind of but not really. I won’t bother you with it and go out of my way to make sure you see it, but it’ll be on status pages. I also generally won’t provide the IP beforehand or anything like that. There’s always other possibilities for an IP change like filtering a DDOS that wasn’t tanked by usual infrastructure, etc.

#13

OK, so after all the discussion about CNAME vs A record, I changed to CNAME.

webmail						IN	CNAME	echo.mxrouting.net	
mail						IN	CNAME	echo.mxrouting.net

And here is what is happening:

Screen Shot 2020-03-22 at 9.58.45 PM

#17

So, where is the chat support? Also, DNS isn’t reverting, I changed it back to the A record because the client needs it to work this morning. (U.S. East coast). So I changed it back last night before going to bed. I used the CNAME record for several hours with no luck. While I am not an expert on DNS (clearly). I am very confident in the zone files I server (90+) and have been serving for years. My updates usually take about 5 to 15 minutes max to propagate. So, I’m still confused about why the CNAME didn’t work. I can try with another non-essential domain but would love to use chat support to test it.

#10

Correct. The echo-relay record is a placeholder in case I ever deploy a backup relay.

Generally a valid question after that is “Why is there not a backup relay” so I want to toss the answer down for any future reader that lands in this thread. All MTAs have a built-in retry time where if they cannot reach a recipient’s server, they retry delivery later. This means that a backup for an outage is already inherent in SMTP infrastructure. Eventually I’d like to rely less on that in case standards ever shift, but my deployments on this front have historically introduced problems in practice while only solving theoretical problems, thus why I do not currently deploy backup relays.