If you're on a Linux or Mac computer, then yes you can edit /etc/hosts locally to connect the hostname to a different IP address than DNS would dictate. On Windows you'd have to edit the hosts file in C:\Windows\system32\drivers\etc. This only applies locally, i.e. to the computer you're currently using. Don't edit the hosts file on the servers for this purpose.

An alias is just a short name for the domain, so instead of subdomain28379.example.com you could use, for example, "dev" as the hostname, the same way you can use localhost to connect to the local domain. The alias is optional, though.

123.45.67.89 subdomain.example.com

If I understand this right: your best bet is to add a new host to DNS just for testing - or a spare domain if you have one. Something like test.example.com with an appropriate IP and (presumably) apache config. You can then test the new site without upsetting the real-world site.

The test site can be on the same computer/IP as the original or on a new server with a different IP.

Reduce the TTL for the test subdomain. I tend to use a few minutes (sometimes just one minute) on test domains/subdomains for just this reason.

I also reduce TTL on production domains before server moves.

Well, this is a tiny offshoot of the same question...

The new VPS is all set up, and I THINK my main site is ready to go. I thought that I'd just change /etc/hosts on my old VPS to point the name to the new VPS, like so:

127.0.0.1 localhost.localdomain localhost

# old record
#123.45.67.89 servername.example.com servername

# new record
987.65.43.21 servername.example.com servername

# just changing the above didn't work, so I also plugged in a bunch of domains
987.65.43.21 foo.com
987.65.43.21 www.foo.com
987.65.43.21 bar.com
987.65.43.21 www.bar.com

I expected that to work immediately (no reboot or anything), but it's been about 10 minutes and it's still bringing up the old VPS.

What am I doing wrong?

What are you expecting to happen here? Changing the hosts file on the old VPS like this means that if the old VPS tries to connect to foo.com, it will connect to 987.65.43.21 without consulting DNS. It's a local substitute for DNS, as it were, with emphasis on local as this only affects connections made by the old VPS itself; it does not affect any other machines.

If I were to connect to foo.com, my browser would consult DNS for the IP address (your local hosts file does not affect me). If I were to copy those lines from your hosts file to the hosts file on my (Windows) computer, my browser would instead connect directly to 987.65.43.21. So if you ping foo.com from your old VPS, you'll probably find it's connecting to 987.65.43.21. Remove the line and it'll consult the domain nameservers first.

The hosts file is not a public substitute for DNS, nor is it a way to forward incoming traffic.

Blah, I kinda figured that out in my head while laying in bed last night, unable to sleep because I kept thinking about it. I was HOPING that it would redirect all incoming traffic to 987.65.43.21, but now I realize that it was just directing internal pings... not quite the same thing.

I found an alternative with CSF (ConfigServer Firewall), but I haven't tested it yet. In theory, I can modify /etc/csf/csf.redirect with:

# old VPS IP | * | new VPS IP | * | tcp/udp
123.45.67.89|*|987.65.43.21|*|tcp/udp

That shouldn't affect FTP or SSH, right? So (again, in theory) I should be able to change it then restart CSF, and the entire server will redirect. Then if there's an issue I can just remove the line restart CSF again, and go back to normal.

I've never used CSF, or tried to redirect web traffic in this way, but that line doesn't appear to be limiting the redirect to specific ports so I don't see how FTP or SSH would not be affected. Tread carefully :-)

If it's just web server traffic you're looking to redirect, I think I'd probably use a reverse proxy (mod_proxy).

Or just stick do DNS (with a temporarily lowered TTL).

After a little more digging, I think this would do it:

123.45.67.89|80|987.65.43.21|80|tcp/udp
123.45.67.89|443|987.65.43.21|443|tcp/udp

This assumes that port 80 is HTTP, and 443 is HTTPS.

But I'm still not 100% sure, so I lowered my TTL to 300 and I'll just use that. So I guess this is really just being posted for future readers.

Grrrr. So, this is why I freakin' hate dealing with DNS...

For reference, I use NS1.EXAMPLE.COM and NS2.EXAMPLE.COM for my nameservers. They point to 123.45.67.89, where I have example.com set up and the DNS has A records for both NS1 and NS2 that point to 123.45.67.89.

Yesterday at around 2pm, I changed the A records for example.com and my main domain (foo.com), changing all 14400 to 300. I left the NS records on both domains at 86400, because I didn't plan to change the nameservers for either of them.

At 1am, well after the TTL should have updated everywhere, I changed the A records for example.com to point to the new IP: 987.65.43.21. I thought that this would be all I'd have to do, because foo.com's nameserver is ns1/ns2.example.com and now ns1/ns2.example.com both point to the new IP.

At 1:30am I saw that example.com was pinging the new server, but foo.com was still pinging the old server. So I changed its A records to point to the new IP, too.

By 3am, foo.com was still pinging the old server! This is getting dangerous... I'm sleepy and need to go to bed, but I don't know if the new server will have errors (like the time I changed the PHP handler and suddenly the site was showing raw PHP code) so I can't just leave it like this. So I decide to change the A records for example.com back to the old server.

Well, I can't log in to WHM anymore, because server.example.com/whm redirects to the new server! So I FTP in and modify both /var/named/foo.com.db and /var/named/example.com.db to point everything back to the old IP, then reload using:

# rndc reload example.com

But by 4am, no change... example.com is pinging the new server, foo.com is pinging the old one.

I changed the A records on the new server for example.com to point everything back to the old IP, but that didn't seem to change anything. But everything seems to be working OK, so I go to bed and hope for the best.

I get up a few hours later, and nothing has changed.

Now it's 4:30pm (so 26 1/2 hours after I changed the TTL, and 15 1/2 hours since I originally changed the DNS records) and I see people are posting on foo.com so it appears to be working, but one regular user has sent me a message on Fakebook to complain that he can't get to foo.com! But he's not very computer literate, so he hasn't been able to give me any output from ping or anything like that.

So now I'm at a complete loss. I guess I could update the nameservers at the domain and hope for the best? Otherwise, changing the DNS records on the old and new server has caused nothing but problems and definitely don't change back quickly like I'd hoped.

There HAS to be a better way!

Oh, and changing /etc/csf/csf.redirect like I posted last night just made the whole site throw a 500 ISE, and never rerouted to the new VPS. So that was a total bust, too.

can you login to WHM using an IP address/port rather than the hostname?

Good thought, but I tried using 123.45.67.89/whm and 123.45.67.89:2087 and both it automatically redirected to server.example.com:2087 (which points to the new VPS).

The user that messaged me? After some back and forth I got him to ping the domain. He tried that, and it was pointing to the new VPS! No error, just a white screen. But I had him to go a simple HTML page through the domain and he still got a white screen, so it's not an issue of PHP not working.

While talking, suddenly the site came up for him! I had him ping again, and now he's pinging the old VPS. About 20 minutes later, though... white screen again, and now he's pinging the new VPS. I hadn't changed anything at all on my end, so it's just his internet provider flipping back and forth for some reason.

Well, I can't log in to WHM anymore, because server.example.com/whm redirects to the new server!

If this is because server.example.com now resolves to the IP address of the new server, that's a good example of what you could use your local hosts file for.

You should also use your hosts file to test if everything works as it should on the new server before you change the A records.

Keep in mind that since you host your own nameservers, you will need to register the new IP address with the domain registry (through your registrar) when you're ready to make that switch, otherwise the root servers will keep referring to your old IP address.

(I've been taking hosted DNS for granted, never have to deal with these things.)

Could the ping and http results you are seeing be due to local caching? When I change my A record IPs my browser pulls up the old site up to several days later if I continue to test it. I leave accessing updated-IP sites locally for a couple of days and do the first tests from a proxy or other server that has not visited the site for at least a few weeks.

There is also the problem of which DNS server is being used by the viewer's browser. Most DNS servers should follow the TTL of the master record but a few may not update that often. I assume you do not have a local caching DNS or query tool.

You should also use your hosts file to test if everything works as it should on the new server before you change the A records.

Dude, this is what I was trying to do! LOL But I couldn't figure it out.

Today it hit me what you were trying to say... not to modify the old VPSs /etc/hosts file, but to modify on MY computer:

C:\Windows\System32\drivers\etc\hosts

Then MY computer points the domains I assign to the new IP, but no one else.

Well, that would have been great to have realized about a week ago :-O Now it's all screwed up. I've had 30 emails from users that are having errors that I can't duplicate, and it HAS to be DNS related.

Could the ping and http results you are seeing be due to local caching?

I had originally hoped so! Here's the wild thing... intodns.com shows that my nameserver domain (for this thread, example.com) points to the old VPS. But digwebinterface.com shows that Google, Cloudflare, OpenDNS, etc are all pointing to the new VPS!