Transfer Tool DNS Zone Bug(?) ... bitten again

[indiemark]

I feel like this has existed for a while, and if it's not a bug let me know what I'm doing wrong, but it has been consistent and pops up every time I do a bunch of transfers to the point where now I'm exporting the zone files and comparing them after moves which is ridiculous and time consuming because it should just work properly.

How to reproduce: have a regular cpanel account, except the root domain is an A record pointing off to another WebHost (use case would be, client is only wanting email hosting). WWW CNAME points to the root domain. Pretty normal stuff, nothing exotic.

Now use Transfer tool and move that account to another server. The A record for the root domain gets reset to whatever the new server IP is. Should it not just "search and replace old IP with new IP"? If so, why is it replacing totally different IPs? But it only does this for the root, not for any subdomain A records, it seems to leave them alone and just does the search and replace as expected.

Bizarre and maddening. Sorry just had to vent. Forgot all about this the last time I migrated some hosts between servers a couple years ago.

 

[cPRex]

Hey there! Just to confirm your situation:

-the DNS is hosted locally on the cPanel server
-one domain has the main A record for the zone pointed to an IP that is *not* on the Source server
-you perform the transfer
-the main A record changes to a local IP on the Destination server

Is that the correct scenario?

 

[indiemark]

Hey there! Just to confirm your situation:

-the DNS is hosted locally on the cPanel server
-one domain has the main A record for the zone pointed to an IP that is *not* on the Source server
-you perform the transfer
-the main A record changes to a local IP on the Destination server

Is that the correct scenario?

DNS is hosted in a cPanel DNS cluster, yes.

All other points are correct. "Search and Replace" for old server to new server IP works for all subdomains (eg. crm.customerdomain.com if it's pointing to a different IP address/different host, it is not impacted, but no matter what customer.com main A record is always changed to that of the receiving cPanel server, which shouldn't happen (in my opinion) unless that A record is the same as the former server. Does that make sense? It should be easy to test on your end, this just happened this week transferring multiple domains on latest cPanel 108, and it happened a few years back the last time I did mass migrations but I didn't really take close notes that time.

 

[cPRex]

Thanks for the additional details. A cluster makes all the difference, and currently, we recommend that the cluster get disabled before a migration happens to avoid confusion on the cluster side.

 

[indiemark]

But why? Why not just patch the transfer code to leave the base domain A record alone if it doesn't match the origin server? That's really the only problem in play.

OR -- a tickbox that says "don't update zones" like how terminating an account has the option to leave the zones alone.

 

[cPRex]

I don't hate those ideas.

I've actually been meaning to do some extensive testing with the Transfer Tool, so I guess now is the time. I also did see your feature request that you submitted, but I'm going to decline it. If my testing confirms all these things, I'll be opening cases about the issues so no feature request will be needed.

 

[indiemark]

Awesome, thanks. I had pre-emptively submitted the feature request because I figured that would be the next step.

 

[ffeingol]

From memory (it's been a bit since we've done mass transfers) this happens whenever the web site is hosted elsewhere. When we do migrations we have a "spreadsheet" with each domain we're migrating and where web and mail point. If web is external (usually something like Wix or Shopify) the DNS records get pointed to the server and we have to correct post migration.

IMHO the process should be:

• Look up the domains IP via the Apache config
• Post migration replace any of the old IP (from the Apache config) with the newly assigned IP

My 2 cents

 

[xpy-xpy]

Just two weeks ago I have transferred a number of accounts with exactly the same setup as you described (root domain custom A record, DNS cluster), and the custom IPs were correctly preserved by the transfer script. No manual changes were needed, unlike we were used to with older Cpanel versions.

The only difference I see is our servers were on v106, and yours are 108.

What's interesting, similar behavior is occurring when trying to change the IP on the same server ("Change Site's IP Address"). A custom A record in the zone gets replaced with the server's IP. Even the output shows something like "Also changing IP...".

 

[cPRex]

I've been testing this through the day to make sure I catch different scenarios and I did three rounds of testing with this. Each test had the main A record of the domain being transferred on the Source server set to an IP that was not associated with any of the three servers, to see if it would be overwritten.

Round 1 - Source is part of a DNS cluster, Destination is not

I didn't see any odd behavior. The record was maintained with the custom IP.

Round 2 - Both Source and Destination are in a DNS Cluster - no Live Transfer

Same - everything worked well

Round 3 - Both Source and Destination are in a DNS Cluster - Live Transfer enabled

Same - everything worked well

At this point, I'm not able to replicate anything odd with the transfer replacing any custom records in the zone, whether it was the main A record for the zone or additonal records.

@indiemark - if you have a server (or cluster, or whatever your configuration is) and you're seeing this happening, we'd like to take a look. Also, before you submit a ticket, if you could enable the WHM >> Tweak Settings >> "Enable verbose logging of DNS zone syncing" option, that would be ideal as that will give us more data about what may be happening with that cluster status.

 

[indiemark]

Weird, I moved a couple more sites; and they are all members of a DNS cluster, and had the same behaviour again last night. Not sure what to say, but this happened a few years ago so it's not a recent thing. I am actually finally done moving sites as of last sites but I will remember this for next time and enable the verbose DNS zone syncing as you suggest next time I need to.