Remote MX DNS entries auto-merged to local MX?

Benjamin D.

Well-Known Member
Jan 28, 2016
133
19
68
Canada
cPanel Access Level
Root Administrator
After using Transfer Tool from server-A to server-B, all remote MX DNS entries got "auto-merged" (converted) to local MX on server-B and the original line sits in a comment on the WHM Edit DNS Zone form. Now I have to manually adjust a ton of domain zones by hand and some customers might even have lost email because of this! Why is WHM 72.0 doing this?! I double checked that the MX was on REMOTE on server-A before transfering (not on automatic, because I had the feeling this could go wrong) and it really was/is on REMOTE, so there's no excuse for this happening. This looks like a (very important) bug to me.
 

Benjamin D.

Well-Known Member
Jan 28, 2016
133
19
68
Canada
cPanel Access Level
Root Administrator
Getting phone calls from unhappy customers, because their Google MX was nudged by WHM Transfer Tool! I hope there's a valid explanation to this very undesirable Transfer Tool behavior.
 

Benjamin D.

Well-Known Member
Jan 28, 2016
133
19
68
Canada
cPanel Access Level
Root Administrator
Yes, what am I supposed to understand from this? Especially this paragraph:

----------------------
  1. The system checks whether the template-generated zone file uses an MX preference of 0, and then performs the following actions:
    • If the zone file's MX preference is 0 and the zone file is $PRIMARY_DOMAIN or mail.$PRIMARY_DOMAIN, the system does not merge in the generated templates and does not update the MX preference from the remote server.

    • If the zone file's MX preference is 0 and the zone file is not $PRIMARY_DOMAIN or mail.$PRIMARY_DOMAIN (a non-standard mail configuration), the system merges the generated templates and comments out templates from the remote server.
    • For example, when the zone template's MX record defines an external mail service, the system prefers that entry over the record in the backup.
----------------------

The reality is: it did exactly the OPPOSITE of this. It imported the external MX as a COMMENTED OUT LINE and applied the local MX instead. It's totally the opposite of the sane transfer tool process description you linked (also FYI I'm on 72.0 not 74.0) and it did that for every single remote MX domain that was imported. Thank god there were only 17 to manually fix.

So what gives?

EDIT: ...wait. Am I to understand that cPanel sees the first MX on server-A as priority 1 instead of 0 and it thinks that because there's no priority 0 MX set, that it should COMMENT OUT that first MX and force local MX instead? Please don't tell me the Transfer Tool is that dumb.
 
Last edited:

cPanelLauren

Product Owner
Staff member
Nov 14, 2017
13,296
1,271
313
Houston
Hi @Benjamin D.

I've been trying to replicate the behavior you're seeing, by setting remote mail exchange on the source server for my domains then transferring them to another server. I'm not able to replicate an issue. Please see the following:

DNS Zone file from source:
Code:
[[email protected] named]# grep MX /var/named/cptest.tld.db
cptest.tld.    14400    IN    MX    0    mail.cptest.tld.
Code:
[[email protected] named]# cat /etc/localdomains
centos7.11-72-0-10.tld
reseller.tld
owned.tld
[[email protected] named]# cat /etc/remotedomains
cptest.tld
On destination server:
Code:
[[email protected] named]# grep MX /var/named/cptest.tld.db
cptest.tld.    14400    IN    MX    0    mail.cptest.tld.
Code:
[[email protected] named]# cat /etc/remotedomains
cptest.tld
[[email protected] named]# cat /etc/localdomains
install.narcissus.cpanel.net
host.172-16-0-124.com
v72.test.com
reseller.tld
owned.tld
I tried both the default transfer method as well as the express transfer method and was not able to replicate the issue with either method. Can you please let me know if there were steps I missed or if there are further details needed in order to replicate the issue?

Thanks!
 

cPanelLauren

Product Owner
Staff member
Nov 14, 2017
13,296
1,271
313
Houston
Hi @Benjamin D.

I'm going to give it another shot with the mx priority set to 1 though I'm not sure this would affect the issue. I'll let you know my findings as soon as it's complete.

Thanks!
 

cPanelLauren

Product Owner
Staff member
Nov 14, 2017
13,296
1,271
313
Houston
Hi @Benjamin D.

I'm trying the transfer again here is the source:

Code:
[[email protected] ~]# grep MX /var/named/cptest.tld.db
cptest.tld.    14400    IN    MX    1    mail.cptest.tld.
[[email protected] ~]# grep cptest.tld /etc/localdomains /etc/remotedomains
/etc/remotedomains:cptest.tld
here is the destination:

Code:
[[email protected] named]# grep MX /var/named/cptest.tld.db
cptest.tld.    14400    IN    MX    1    mail.cptest.tld.
[[email protected] named]# grep cptest.tld /etc/localdomains  /etc/remotedomains
/etc/remotedomains:cptest.tld
None of the configuration settings have been modified and the domain is set to remote as intended.
 

Benjamin D.

Well-Known Member
Jan 28, 2016
133
19
68
Canada
cPanel Access Level
Root Administrator
So it must be something else. This is definitely the lowest priority of all my issue threads tough, since as I've mentioned, I went through all the domain DNS sheets and manually reverted every single one's MX so the issue is not currently affecting any of my customers. Since you cannot replicate the issue, I guess this thread could be closed, but it definitely happened and it definitely was problematic for me and my customers as some might have lost a couple emails, albeit the sending mail servers should theorically retry every 24 hours, so in the end all emails should arrive at their destination, since this MX outage did not last more than 1-2 hours.

Thanks.
 

cPanelLauren

Product Owner
Staff member
Nov 14, 2017
13,296
1,271
313
Houston
Hi @Benjamin D.

I'm responding to them all in order I'll get to them all as soon as I can. I believe it happened to you, though I do wonder if some other setting or customization was involved in modifying the behavior. As we saw a simple transfer with cPanel defaults went through uneventfully.

Thank you