[CPANEL-33207] Transfer tool ignores external MX records and remote domains when using DNS templates
Hi - I was wondering if anyone else had noticed this behaviour...
We use a local MX record that we set up in the zone templates. We simply create an A record mx.domain with the IP of the server and point the domain's MX record to mx.domain. Instead of the default cpanel method of the MX record pointing directly to the domain name itself.
The mx.domain record already exists on all our servers for all our customers.
When an account is transferred from one server to another, the A record is correctly updated to the new server IP - but if a domain is using external MX records and their mail routing option is set to remote - this is ignored completely and the MX record is set according to the zone template when it did not exist before in the zone.
This is most definitely not the desired behaviour and I was hoping that someone might be able to offer a suggestion to resolve this issue?
I was of the impression that there was a process during the transfer that attempted to determine whether the routing was remote or local and took action (or not) accordingly.
Duplicate records are not created for the mx.domain or for the MX record if they already exist - so it is not blindly creating these records - but it is ignoring the fact that some clients have google's MX records and their domains set to remote and then creating the local MX record when it should not. I need to find a way to stop this happening.
-
I performed another server move last night and it seems the logic of the MX checking has changed dramatically since we last performed any mass server transfers. We have clients who have correctly set their mail routing to remote and are using MX records at google or outlook.com for example - yet when these accounts are transferred to a new server, in every case, they are overridden. In some cases the MX records are being completely removed - and in all cases, the MX record from the zone template is added. Surely, if a domain is set to remote and has no other MX records than remote ones - i.e the MX's don't point to the local domain or IP - it is clear that they should be left well alone. I'm sure in the past, if the domain was remote and the MX resolved outside the server, they were ignored. At least thats what I'm looking to acheive here. I really need to find a way around this. I've looked at the transfer tool documentation. It says.... [QUOTE] 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.
I'm struggling to make sense of the above. Why is it comparing zone templates of the two servers? That has no bearing on the existing zone file. In our case the zone templates are identical - but MX records can be modified and created long after the account is setup via the zone templates. The process is correctly changing the IP of the mx.domain record and where the mx is local, it is leaving it alone. Great - but for EVERY remote MX. the process is either deleting all the MX records or it is leaving them but adding the one from the zone template. It seems if the MX is set to a priority of 0 - it is deleted! But surely if it is not local to the server AND the domain is set to remote mail routing, it should be ignored? All we want to do is preserve the remote MX records - why isn't the transfer process doing this? There should be much more control over this behaviour. We've been forced to check /etc/remotedomains for any remote MX's after the transfer has completed - and then because the transfer process deleted them, we have to search the old DNS zones on the previous server to find what MX records were in place and copy paste the MX records out of the old server and into the zone editor on the new server. We had to do this 27 times for this account transfer. Not ideal! I'd appreciate any insights.0 -
Hi @4u123 This doesn't sound like the intended behavior, but I discussed this with one of our L3 analysts and we believe this needs a ticket, not only to replicate but to identify the issue occurring as well. Could you please open a ticket then provide me with the ticket ID so I can follow up with it? 0 -
Thanks Lauren, ticket no 93502500 0 -
Hi @4u123 I'm glad you opened the ticket as it does appear to have resulted in a case being opened CPANEL-33207. I'll update here with information on the case as soon as there is an update 0 -
Hello, This is just an update to let you know that this issue is marked as resolved in v90 of cPanel & WHM and can be referenced in our changelogs here: 90 Change Log | cPanel & WHM Documentation 0 -
Thanks Lauren, I wonder if you could find out the exact logic that has been introduced for me? I'm not sure the description provides an adequate explanation of what has now changed. 0 -
The notes in the case state the following [QUOTE] Prefer transferred MX records if local template uses a subdomain Case CPANEL-33207: We were preferring the transferred MX records only when the local dns template used "domain.com" or "mail.domain.com". Change to prefer the transferred MX record if the local template uses "domain.com" or any subdomain of "domain.com". This will work in the case where the local template uses "mx.domain.com". Changelog: When transferring an account, prefer transferred MX records if the local DNS template uses "domain.com" or any subdomain of "domain.com". Whostmgr/Transfers/Systems/ZoneFile.pm| 4 ++-- 1 file changed, 2 insertions, 2 deletions
If that's not enough information though I can contact the team that made the changes and see what information they can provide.0
Please sign in to leave a comment.
Comments
7 comments