Issue [12.5.30] Plesk Panel migrator incorrectly replaces IP address in the DNS zone

[burnley]

Plesk 12.5.30 on both src and target, Panel Migrator 2.7.9.
Here's another one: we've just had a client reporting DNS zone corruption, one of their previously configured A record got changed during the migration in the following fashion:
1. src server:
remote.domain.com A 1.2.3.4
2. target server:
remote.domain.com A 5.6.7.8
Where:
1.2.3.4 is an external public IP address, not allocated to any of our Plesk servers
5.6.7.8 is the shared public IP of the target server.
The corresponding debug.log entry is:
D|MT|core.converter.dns|domain.com||Replaced IP in DnsRecord(rec_type=A src='remote.domain.com.' dst='1.2.3.4' opt='') with 5.6.7.8

Any ideas?

 

[IgorG]

Any ideas?

Try to use IP mapping file for manual mapping - IP Mapping

 

[burnley]

Thanks Igor. I was already using the IP mapping, I always am mapping the src->target IPs. The problem in this case is, 1.2.3.4 is *external*, i.e. not configured as local IP on neither source, nor target server, therefore the record should be migrated *as is*. It's always been like this, wasn't it? Has the behaviour changed recently and I missed it?

 

[IgorG]

Has the behaviour changed recently and I missed it?

Nothing was changed. Your expectations are correct. Are you sure that there are no any mentions of 1.2.3.4 in database of source server?

 

[burnley]

Igor, of course there are DB entries for 1.2.3.4 on the source server in the psa.dns_recs table. But, since 1.2.3.4 is an external IP, Plesk should migrate it as is, has nothing to do with the IP mapping. According to IP Mapping the IP mapping is only used to map the source IP addresses to target IP addresses. External IPs have nothing to do with this.

 

[Alina Dmi]

Hello, burnley!
Could you please give us dns zone of domain on source?

 

[burnley]

Alina, is this what you're after?

mysql> select type, displayHost, displayVal from dns_recs where dns_zone_id in (select id from dns_zone where name in ('domain.com'));
+-------+---------------------------------------+------------------------------------+
| type | displayHost | displayVal |
+-------+---------------------------------------+------------------------------------+
| A | domain.com. | src.ip.ad.dr |
| MX | domain.com. | filter1.domcom-1.mailguard.com.au. |
| A | mail.domain.com. | src.ip.ad.dr |
| CNAME | ftp.domain.com. | domain.com. |
| A | lists.domain.com. | src.ip,ad.dr |
| CNAME | *.webmail.domain.com. | domain.com. |
| CNAME | www.domain.com. | domain.com. |
| A | remote.domain.com. | 1.2.3.4 |
| NS | domain.com. | dns1.host.com. |
| NS | domain.com. | dns2.host.com. |
| NS | domain.com. | dns3.host.com. |
| NS | domain.com. | dns4.host.com. |
| MX | domain.com. | filter2.domcom-1.mailguard.com.au. |
| CNAME | webmail.domain.com. | autodiscover.host.com. |
| MX | domain.com. | filter3.domcom-1.mailguard.com.au. |
+-------+---------------------------------------+------------------------------------+
15 rows in set (0.06 sec)

A lot of obfuscated stuff in the output above, here it goes:
domain.com - the affected domain
src.ip.ad.dr - the shared IP address of the source server. For migration, it maps to 5.6.7.8 which is the target shared IP as per my initial post.
1.2.3.4 - the external IP.
dns{1,2,3,4}.host.com - the NS records.

Given this output, I would have expected to see this DB entries on the target server:
+-------+---------------------------------------+------------------------------------+
| type | displayHost | displayVal |
+-------+---------------------------------------+------------------------------------+
| A | domain.com. | 5.6.7.8 |
| MX | domain.com. | filter1.domcom-1.mailguard.com.au. |
| A | mail.domain.com. | 5.6.7.8 |
| CNAME | ftp.domain.com. | domain.com. |
| A | lists.domain.com. | 5.6.7.8 |
| CNAME | *.webmail.domain.com. | domain.com. |
| CNAME | www.domain.com. | domain.com. |
| A | remote.domain.com. | 1.2.3.4 |
| NS | domain.com. | dns1.host.com. |
| NS | domain.com. | dns2.host.com. |
| NS | domain.com. | dns3.host.com. |
| NS | domain.com. | dns4.host.com. |
| MX | domain.com. | filter2.domcom-1.mailguard.com.au. |
| CNAME | webmail.domain.com. | autodiscover.host.com. |
| MX | domain.com. | filter3.domcom-1.mailguard.com.au. |
+-------+---------------------------------------+------------------------------------+
15 rows in set (0.06 sec)

 

[Alina Dmi]

Yes, it is. Thank you!
Can`t see any problem records, it`s just ordinary zone, hm.
Please, make sure that your database does not contain external ip address by grep on mysqldump of psa database. Also, in this post you`ve said that you`ve customized migrator. Please, make sure, that your customization does not break ip mapping(maybe you have an opportunity to perform test migration by not modified migrator).

 

[burnley]

Thanks Alina. For the external IP, I wouldn't have thought it would cause any issue, we have many other subscriptions with external IPs which are migrated properly. As long as the IP is external, that is, unallocated to any of the 2 nodes, source and target, shouldn't really matter, should it?
As for the customizations we're using, they're not breaking any IP mapping, since the changes put in place are related to file copy operations.

 

[Alina Dmi]

I see.
Is the migration session with problem still available on your server?

 

[burnley]

Alina, will let you know if I'll see the issue again.

 

[Alina Dmi]

Ok, thank you!