Point a Domain at a VPS Without Shooting Yourself in the Foot

Pointing a domain at a VPS is three records and a waiting period, not a wizard. The damage happens when you change the web name and accidentally take mail with it, when you CNAME the apex, or when you issue a certificate against an IP that is not yet the one browsers will hit. This post is a cutover checklist for a single Linux VPS: registrar nameservers, A and AAAA, www, mail, and the first HTTP-01 attempt.

The machine can be a fresh Ubuntu 24.04 box in Lucknow DC01 with Xeon Platinum cores and High-Speed SSD. None of that helps if the name still points at a previous host, or if you delete MX records because the DNS panel grouped them under the same domain editor.

Confirm who answers the zone

Before you edit anything, ask who is authoritative. A registrar login is not the same as the nameservers that currently serve the domain. If NS records still point at a previous host, edits in a new panel do nothing.

dig +short NS example.com
dig NS example.com @a.root-servers.net
whois example.com | sed -n "1,80p"

The NS set you get from a recursive resolver should match the NS set at the parent (the TLD). If they disagree, you are looking at a stale cache or an incomplete delegation. Fix delegation first. Do not issue certificates against a name that still has two stories.

Put A and AAAA on the VPS, not a CNAME at the apex

Copy the public IPv4 from the VPS panel. Create or update the apex A record. If IPv6 is assigned and reachable, add AAAA; otherwise skip it. For www, either duplicate the A record or CNAME www to the apex. Do not CNAME the apex to www, to a hosting brand name, or to a load-balancer hostname unless you have no MX, TXT, or CAA at the apex.

Lower the TTL on the records you will change, wait for the old TTL to expire, then change the IP. That sequence is the difference between a five-minute cutover and a six-hour "it works on my phone." If the old TTL was 86400, lowering it today does not help today's switch. Plan a day ahead, or accept that some resolvers will keep the old IP until that TTL dies.

Do not take mail down to launch a website

The DNS editor at most registrars shows every record on one screen. People delete MX because they want a clean zone, or they change the apex A and do not realize their mail provider was also using that A. MX should point at mail hostnames. Those hostnames have their own A records. Your web VPS IP should appear on example.com and www.example.com only, unless you really run SMTP there.

SPF is a TXT on the apex. If you send mail through a provider, keep the include: they gave you. Pointing the website at Netbay does not make the VPS a valid sender. Leave SPF and DKIM alone during a web cutover.

Prove the IP before you prove TLS

HTTP-01 (the usual certbot path with nginx) fetches http://example.com/.well-known/acme-challenge/... Let's Encrypt's validators use public DNS. If your laptop has the new A and the CA still sees the old one, issuance fails. Serve a dummy file on port 80 and fetch it from a second network before you run certbot.

mkdir -p /var/www/html/.well-known/acme-challenge
echo "cutover-ok" > /var/www/html/.well-known/acme-challenge/ping
ss -lntp | grep ":80 "
curl -4 -sS http://example.com/.well-known/acme-challenge/ping
dig +short A example.com @1.1.1.1
dig +short A example.com @8.8.8.8

If those two public resolvers disagree, wait. If they agree on the VPS IP and curl returns cutover-ok, certbot is safe to run. If curl hits the old host, you are about to issue a certificate for a machine you are leaving.

Glue, WWW, and the first request

If the nameservers themselves live under the domain (ns1.example.com), the parent zone needs glue A records. Changing the VPS IP does not update glue. Glue mistakes look like "the domain vanished" rather than "the website is old." For a typical VPS you should use the registrar's nameservers or a DNS host, not run BIND on the same box you are moving.

After the A record matches, open http://example.com/ and http://www.example.com/ separately. Redirect www to apex (or the reverse) in nginx only after both names resolve to this VPS. Redirecting a name that still points elsewhere sends users to the wrong place with a 301 they will cache.

The foot-guns are consistent: edit the nameservers that actually answer, change A and AAAA only, leave MX and SPF unless mail moves, wait until public resolvers agree, then issue the certificate. You can provision the target Ubuntu 24.04 VPS on Netbay in Lucknow (DC01) in under 60 seconds and rehearse this cutover on a spare name — netbayhosts.in.