Point a domain to the server

Choose the exact hostname that will serve the application, for example notes.example.com. At the authoritative DNS provider, create an A record whose value is the Droplet’s public IPv4 address.

Add an AAAA record only when the Droplet has public IPv6 enabled, Nginx listens on IPv6, UFW permits it, and you have tested the complete IPv6 path. A broken AAAA record can make a healthy IPv4 service appear unreliable.

Verify authority and caches

Find the authoritative nameservers:

dig NS example.com +short

Ask one of those nameservers directly. For a zone hosted by DigitalOcean, one query can look like this:

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

Use a nameserver returned by your own NS query when another provider hosts the zone.

The answer should contain the Droplet address. Then compare a public recursive resolver and your normal local resolver:

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

This tells you where a disagreement lives. If authority is wrong, fix the DNS zone. If authority is correct but a recursive resolver is old, wait for its cached answer to expire according to the previous TTL.

Do not keep changing the record while caches are converging. Each change creates another possible answer and makes diagnosis harder.

Once DNS resolves correctly, verify that Nginx receives the intended hostname:

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

An HTTP response proves more than DNS alone. It checks resolution, the connection, firewall, and Nginx.

For a migration, keep the previous server working while old cached answers remain valid. The rollback is to restore the old record value and keep both endpoints available for at least the old TTL. DNS rollback is not instant for clients that already cached the new answer.

Your action is to record the authoritative answer, one public-resolver answer, the TTL, and the HTTP result. Do not request a certificate until all four point to the intended server.