Point a domain to the server

A certificate is issued for a hostname, not an IP. So before HTTPS we need a name that resolves to the Droplet. Pick the exact hostname the app will use, for example notes.example.com, and use your own domain in its place throughout this lesson.

At your DNS provider, create an A record for that hostname with the Droplet’s public IPv4 address as its value. An A record is the simplest mapping there is: this name means this IPv4 address.

Hold off on the AAAA record, the IPv6 version. Add it only when the Droplet has public IPv6 enabled, Nginx listens on IPv6, UFW allows it, and you’ve tested the full IPv6 path. A broken AAAA record makes a perfectly healthy IPv4 site look flaky, because some clients try IPv6 first and time out.

Ask the authority, then the caches

DNS answers come from two kinds of servers. The authoritative nameservers hold the zone and always answer with the current record. Recursive resolvers (your ISP’s, 1.1.1.1, the one on your laptop) cache answers for the record’s TTL, the time-to-live in seconds. When you change a record, the authority updates at once and the caches catch up later.

Find your authoritative nameservers:

dig NS example.com +short

Ask one of them directly. If DigitalOcean hosts the zone, it looks like this:

dig @ns1.digitalocean.com A notes.example.com

Use a nameserver from your own NS answer if another provider hosts the zone. The ANSWER SECTION should contain the Droplet IP, with the TTL next to it.

Now compare a public resolver with the one your computer normally uses:

dig @1.1.1.1 A notes.example.com +short
dig A notes.example.com +short

If all three agree, you’re done. If the authority is right but a resolver is wrong, it’s serving a cached answer. Wait for the old TTL to run out. If the authority itself is wrong, fix the record at the DNS provider.

Whatever you do, don’t keep editing the record while caches converge. Every change adds another possible answer floating around, and diagnosis gets harder.

Prove it end to end

Once DNS resolves, check that Nginx receives the hostname:

curl -I http://notes.example.com

200 OK here proves resolution, the connection, both firewalls and Nginx in one shot. DNS alone proves only the first.

A note on migrations

When you move a site to a new server, keep the old one running until the old TTL expires. Clients that cached the old IP will keep hitting it. The rollback is the same in reverse: restore the old record and keep both servers alive for at least one TTL.

Record the authoritative answer, one public resolver answer, the TTL and the curl result. Don’t request a certificate until all four point at your Droplet. If DNS feels fuzzy, the DNS course covers records, TTLs and resolvers in depth.