When restoring a full cpmove file, dns zone keeps old SOA... why?

[fenixer]

Hello.....

When I restore an account from a full cpmove file stored in /home, by example, I have a pretty problem with final DNS zone at (destination) server:

During the restore proccess, I guess:

Restoring Dns Zones

Bind reloading on murcia using rndc zone: [elfuegodetuculo.com]
Changed all instances of [213.x.x.x] -> [85.x.x.x] in blablabla.com.db

But if I simply have a look at dns zone, I can see (for my surprise) the original SOA record not affected by the transfer......

The restore proccess also show this:

Account Creation Status: ok (Account Creation Ok)

Forced Dns is enabled.
+===================================+
| New Account Info | +===================================+

It seems like the package file contains a folder named "dnszones" with current db file inside, and the restore proccess is just importing that zone only replacing the old IP by the new one of the current server...... but SOA will be stilll the same, and I guess that is pretty bad for my bussiness.

It is great cpanel now package the dns information too, so manual changes wont be lost at transfers..... but I guess not only the IPs for the A records need to be changed, so SOA have to be updated too!

I see no option for this at tweak settings neither restore backup interface.......

any sollution? People have the same problem?

Thanks in advance.

 

[fenixer]

anyone experienced this???

I think I´ll post in bugzilla, since it is not good cpanel imports dns zone without modifying the SOA record into the current one of the destiny server...

 

[Infopro]

Not sure this is your problem, but do you have this checked in Tweak Settings?

When adding a new domain, if the domain is already registered, ignore the configured nameservers, and set the NS line to the authoritative (registered) ones.

Uncheck that if so.

 

[fenixer]

Not sure this is your problem, but do you have this checked in Tweak Settings?

When adding a new domain, if the domain is already registered, ignore the configured nameservers, and set the NS line to the authoritative (registered) ones.

Uncheck that if so.

It is already unchecked....

And the problem is not with NS registries, but only for SOA registry in the DNS zone.

Anyone? Nobody can test?

 

[fenixer]

I guess people thinks this is not important...... but I think it is....

Bugzilla:
http://bugzilla.cpanel.net/show_bug.cgi?id=5779

If I move an account from one server to another, I guess all the DNS records need to be updated..... WHM now does good with current A and NS records, but IT DOES NOT UPDATE the old SOA record........ the Authority of the DNS zone is quite important, and need to be renamed to the new destination server....

Thanks.

 

[fenixer]

Ok..... my bugzilla report is duplicated of:

Bugzilla
http://bugzilla.cpanel.net/show_bug.cgi?id=5694

(my fault.... i am sorry)

At bugzilla, they ask user reporting bug to write a support ticket....... what is the purpose of bugzilla then? (bit confused)

 

[cPanelKenneth]

Ok..... my bugzilla report is duplicated of:

Bugzilla
http://bugzilla.cpanel.net/show_bug.cgi?id=5694

(my fault.... i am sorry)

At bugzilla, they ask user reporting bug to write a support ticket....... what is the purpose of bugzilla then? (bit confused)

Sometimes there is not enough information, or we cannot reproduce the particulars in our testing environment. Hence we will ask a reporter to open a support ticket so we can see the full picture.

 

[Solokron]

This is ABSOLUTELY an issue. We see this all the time. Once an account is transfered to another server we must edit the dns record and save it (no changes made) for the SOA to be updated properly.

 

[fenixer]

thanks....... I am happy to listen someone giving me some reason... I thought nobody cares about it.
:D

 

[Azraell]

overhere too

I too get this error of the SOA not being overwritten.

Fucksome, seems like I'll have to upgrade, from the bugZilla entry:

"""
Fixed in builds 17307 and higher.
"""

 

[cPanelKenneth]

The errors we were able to identify have been fixed in builds 17780 and higher. If anyone running this build or newer still encounters this issue, please post the SOA of the failed Zone portion for examination. Thank you.