Incorrect SPF record after restoring backup on a different server

[Invader Zim]

Hi all.

For many years now when wanting to move a user to another server I've done so by creating a reseller-level backup of that user with all data, move the backup to the target server and then restore it on the new server where you tell DA to use a different ip address than can be found in the backup. Not only did that make sure that all the ip addresses of the old server get replaced by the new ip address in the zone file. This would also update the SPF record correctly. All occurences of the old server's ip addresses would get swapped out for the new server's.

These days however, it is not so easy. I noticed a "new" option at the restore. "Restore with SPF values from backup. (unchecked: Use local spf values)".


So when you set the check box the old spf record gets written, but unchecked it writes the (new) server's default SPF. Both these options are terrible. You are either dealing with an SPF record that is no longer actual or just plain wrong. People who use a different spf record suddenly get issues with their email.

I thought it was something I remembered incorrectly but I've heard this from others now too. And sure, correcting the spf record when the user in question has 1 or 2 domains is doable. But when you're migration 75 users with 1000+ domains, it's a real pain.

Can we please go back to the old situation? Or at least make that one available again?

 

[MediaMet]

Last time we moved server we had the same struggle, so an combine option will be nice

 

[Richard G]

What struggle? However to make life at little bit easier, doing things from the GUI maybe, I would like it too.

But when you're migration 75 users with 1000+ domains, it's a real pain.

What pain do you mean exactly?
You can do it as we did. At this moment we just choose the option to use the spf from backup and then afterwards use the perl -pi commands to replace the old ip's with the new ip's for all *.db files at once.
So it took 3 commands. One for the ipv4, one for the ipv6 and one to update all DNS records. Didn't even take 5 minutes.

Just an example:
perl -pi -e 's/10.0.0.174/192.168.10.3/ig' *.db
same for ipv6.
and the last command to rewrite all serials:
/usr/local/directadmin/directadmin taskq --run "action=rewrite&value=named" --debug 400
and you're done.

Ofcourse you do take care you have a backup before doing this.

Benefit by doing it this way is that you don't change any additional ip's or things the customer might have put in there or when external ip's are used, because they won't be overwritten.

So an option to replace the old ip's, should also contain an option to specificy the old ip's, to prevent external or added ip's to be overwritten.
I would like this to make life a little bit easier.

But if you want something like that, you have to put it in as a feature request and maybe it gets upvoted enough.

 

[Invader Zim]

Benefit by doing it this way is that you don't change any additional ip's or things the customer might have put in there or when external ip's are used, because they won't be overwritten.

So an option to replace the old ip's, should also contain an option to specificy the old ip's, to prevent external or added ip's to be overwritten.
I would like this to make life a little bit easier.

But if you want something like that, you have to put it in as a feature request and maybe it gets upvoted enough.

That's what I'm saying. It used to be like that, automatically. Move to new server, zone file gets updated where all instances of the old ip address (including the spf record) get changed. So it's not a feature request, but more of a revert-to-the-old-situation request.

 

[Richard G]

So it's not a feature request, but more of a revert-to-the-old-situation request.

Reverting a new feature is also a feature request. You can post it here as you did but I doubt it's looked at. If we would like to have an old feature back like old style custombuild, it's still change (even change back) of a feature. A request to change or add a feature is a feature request.
Anyway, I don't mind, maybe you will get lucky here, one never knows, but my guess is that they changed it for a reason.