Skip to main content

Remote MX DNS entries auto-merged to local MX?

Benjamin D.
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.

Comments

10 comments

Date Votes
  • Benjamin D.
    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.
    0
  • Infopro
    Have you seen the docs regarding the Transfer Tool? Transfer Tool - Version 74 Documentation - cPanel Documentation
    0
  • Benjamin D.
    Yes, what am I supposed to understand from this? Especially this paragraph: ----------------------
    • 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.
    0
  • cPanelLauren
    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: [root@stablecent named]# grep MX /var/named/cptest.tld.db cptest.tld. 14400 IN MX 0 mail.cptest.tld.
    [root@stablecent named]# cat /etc/localdomains centos7.11-72-0-10.tld reseller.tld owned.tld [root@stablecent named]# cat /etc/remotedomains cptest.tld
    On destination server: [root@v72 named]# grep MX /var/named/cptest.tld.db cptest.tld. 14400 IN MX 0 mail.cptest.tld.
    [root@v72 named]# cat /etc/remotedomains cptest.tld [root@v72 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!
    0
  • Benjamin D.
    @cPanelLauren Yes, you missed the last paragraph. The source MX should be set to 1 not 0. Not sure it will help you replicate it, but that's one thing I see that is different from my setup and your replication setup.
    0
  • cPanelLauren
    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!
    0
  • Benjamin D.
    I really doubt it, myself. If it does make a difference, then the Transfer Tool is really, really dumb.
    0
  • cPanelLauren
    Hi @Benjamin D. I'm trying the transfer again here is the source: [root@centos7 ~]# grep MX /var/named/cptest.tld.db cptest.tld. 14400 IN MX 1 mail.cptest.tld. [root@centos7 ~]# grep cptest.tld /etc/localdomains /etc/remotedomains /etc/remotedomains:cptest.tld
    here is the destination: [root@v72 named]# grep MX /var/named/cptest.tld.db cptest.tld. 14400 IN MX 1 mail.cptest.tld. [root@v72 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.
    0
  • Benjamin D.
    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.
    0
  • cPanelLauren
    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
    0

Please sign in to leave a comment.

Didn't find what you were looking for?

New post