You have a VPS with a public IP and a domain sitting at a registrar. Connecting the two trips up more people than it should. Here is the whole path.
1. The A record is the core of it
An A record maps a name to an IPv4 address. At your DNS provider, add:
Type Name Value
A @ 203.0.113.10
A www 203.0.113.10
@ is the bare domain (example.com), www is the subdomain. If you have IPv6, add AAAA records with the same names pointing at your v6 address.
2. Understand TTL and propagation
TTL is how long resolvers cache the record. Set it low (300 seconds) before a planned change so the switch is fast, then raise it again afterwards. "Propagation" is just caches expiring around the world; there is nothing to speed up except waiting out the TTL.
3. Check it from the outside, not your browser
dig +short example.com
dig +short www.example.com
Your browser caches and your OS caches, so trust dig against a public resolver over a page reload.
4. Add TLS once DNS resolves
Certbot with the HTTP challenge needs the domain to already point at the box and port 80 reachable:
apt install certbot python3-certbot-nginx
certbot --nginx -d example.com -d www.example.com
If you are behind a CDN or want wildcards, use the DNS-01 challenge instead, which proves control through a TXT record rather than a live web server.
5. A note on NAT-IPv4 hosts
On budget hosts your VPS may share an IPv4 and get specific forwarded ports rather than the whole IP. That is fine for most workloads, but it changes how you point a domain: you map the name to the shared IP and reach your service on its forwarded port, or you put a reverse proxy in front. Always check whether your plan gives you a dedicated IP or a NAT one before you design around it.
At overnight.host we are upfront about which plans are NAT-IPv4 and which give a dedicated IP, because finding out after you have wired DNS is nobody's idea of fun.
