Moving a server to a new location

Hello there.
I have an opensuse server which handles 5-8 sites, a mail server and a nameserver.

I will move it to a new location and I’ll have a different IP. Now, I didn’t configure the server myself, so I don’t know what to do so that the mail server, the sites and the nameserver to work in the new location with a new IP.

Does it suffice to change the IP of the nameserver from my domain registrar? What any other modification I’ll have to do in order for the mail and sites to work at the new location?
I searched tutorials on moving a server to a new location but I didn’t find any… :’(
Your help will be greatly appreciated

Yes, you have to change all the DNS records that point to the old server, at least the NS records, A records, and MX records.

But because DNS records have a lifetime, you should reduce the TTL to a low value ahead of time so that the switchover will complete faster when the record is changed. Then you can raise the TTL again.

During the period of the switchover you should expect that both servers will be accessed by the domain name and plan accordingly.

Thank you for the quick reply. Really great to know that I don’t have to modify too much on the server. The change for A records and MX records I’ll have to do it on my server, no? How will I do that? Trough yast2?
For example before the move, can I put a seconday MX record to go to the new IP? From where I’ll have to do that?

And the TTL? Also trough yast2?

I’m a total noob… :frowning:

You have to change the records at the nameserver that handles your domain. This may be at the registrar, or (tricky) your server.

Unfortunately this sort of task doesn’t have a ready made tutorial, it’s something you work out from knowledge of how DNS works, how to change DNS records, how to migrate services, etc.

To be blunt, if you don’t feel up to it, hire an expert sysadmin to do it. If that is not possible, then at least practice with a dummy server before you do the migration for real.

You are scarring me.
The registered nameserver is also on the same server of the mail and web server…
But I was thinking that chaning the IP of the nameserver from the registrar will solve the problem like this:
From the domain registrar the is configured to go to the old IP, so if i change the old IP to the new IP, after I change the A records, MX records and TTL will solve this problem.

Would’nt it be true?

You have to also consider what happens in the transition period, given that DNS records are cached and have TTLs. Eventually the results will settle down, but if you do it in the wrong sequence your outage will be longer than necessary.

All I can say is, if uptime is important to you, plan the migration well and practice beforehand if you can.

Yuck. Everything running on one machiine.

To ease your transition, I highly recommend planning on setting up a new Public Secondary DNS server at least a week ahead of time, register it and leave it running during the entire time of your tranition (at least a week after you actually move). This is because mailservers typically cache mail domains longer than the configured Public DNS TTL you configure.

Moving a mailserver can be complicated, be sure to review your method of anti-spam, some are based on domain name only, some are based on IP address.

I would even consider planning on possibly running duplicate mailservers in both locations (depends on the capabilities of your type of mailserver to support a farm), then consolidating the mail stores later.

Although mailserver transition can be tough and Public DNS can be tricky, review your other services also. Private DNS can actually be braindead simple because it can literally be forklifted to the new location without modification.


Strongly consider this transition as an opportunity to separate your network services onto different machines, this can be done virtually at low to no cost (only your time) using products like VMware, Xen, Virtualbox, etc.

The additional overhead on hardware is minimal, can greatly ease administration and improve fault tolerance (If one thing fails it won’t take everything down with it).