This object is in archive!
Move restore of DNS zones to last in Transfer Account function
Needs Feedback
Current transfer account / restore account function restores DNS Zones before restoring MySQL, PostgreSQL etc.
This can sometimes leave a site non-functional for some time since zones can have low TTL.
It would be better if the restore of DNS zones was the last thing executed.
I like this idea 
cPanel, WebHost Manager and WHM are registered trademarks of cPanel, L.L.C. for providing its computer software that facilitates the management and configuration of Internet web servers.
I am a bit confused on how you are running into this situation. When using the "Express Transfer" feature (which updates DNS on the source machine to point to the destination machine), the action of making those DNS record changes *does* occur last.
If you are not using Express Transfer and are simply referring to the actual creation of the DNS zones, I am unsure how any nameservers/TTL/etc are involved. If the nameservers are already pointed to the location where the account is being restored, then I imagine it's effectively "down" anyway until the DNS zones are restored.
In short, I do not believe I am understanding your use case here. Could you please elaborate in detail how you are experiencing this problem via an example?
I am a bit confused on how you are running into this situation. When using the "Express Transfer" feature (which updates DNS on the source machine to point to the destination machine), the action of making those DNS record changes *does* occur last.
If you are not using Express Transfer and are simply referring to the actual creation of the DNS zones, I am unsure how any nameservers/TTL/etc are involved. If the nameservers are already pointed to the location where the account is being restored, then I imagine it's effectively "down" anyway until the DNS zones are restored.
In short, I do not believe I am understanding your use case here. Could you please elaborate in detail how you are experiencing this problem via an example?
I am a bit confused on how you are running into this situation. When using the "Express Transfer" feature (which updates DNS on the source machine to point to the destination machine), the action of making those DNS record changes *does* occur last.
If you are not using Express Transfer and are simply referring to the actual creation of the DNS zones, I am unsure how any nameservers/TTL/etc are involved. If the nameservers are already pointed to the location where the account is being restored, then I imagine it's effectively "down" anyway until the DNS zones are restored.
In short, I do not believe I am understanding your use case here. Could you please elaborate in detail how you are experiencing this problem via an example?
I am a bit confused on how you are running into this situation. When using the "Express Transfer" feature (which updates DNS on the source machine to point to the destination machine), the action of making those DNS record changes *does* occur last.
If you are not using Express Transfer and are simply referring to the actual creation of the DNS zones, I am unsure how any nameservers/TTL/etc are involved. If the nameservers are already pointed to the location where the account is being restored, then I imagine it's effectively "down" anyway until the DNS zones are restored.
In short, I do not believe I am understanding your use case here. Could you please elaborate in detail how you are experiencing this problem via an example?
Based on my understanding of a recent report of this issue, the biggest concern is likely when DNS clusters are involved, and an account is being transferred between two servers within the same cluster. Prior to the transfer, the TTLs on the zone are set very low. The transfer then kicks off. During the restoration phase, we first inject a default zone with default TTL settings, then splice in and/or replace records from the account's backup data.
This results in the cluster having default zones for the domain(s) for a period of time which, while short, may be undesirable for some.
Based on my understanding of a recent report of this issue, the biggest concern is likely when DNS clusters are involved, and an account is being transferred between two servers within the same cluster. Prior to the transfer, the TTLs on the zone are set very low. The transfer then kicks off. During the restoration phase, we first inject a default zone with default TTL settings, then splice in and/or replace records from the account's backup data.
This results in the cluster having default zones for the domain(s) for a period of time which, while short, may be undesirable for some.
Replies have been locked on this page!