Point a domain at a service

DNS changes are easy to make and slow to notice you got wrong. The two failures this avoids are editing the wrong record because two look alike, and reporting success from a change that propagated nowhere.

Steps

1. List the zone's existing records first and read the ones that already answer for this name. If a record exists for the hostname you were asked to add, you are changing something, not adding something, and the old value goes in your notes before you overwrite it.
2. Check what the target actually is. A platform hostname, not an IP, wherever the platform offers one — an IP written by hand today is an outage the day that platform moves it.
3. Write the record with a short TTL, one minute or five, for the first change. Raise it once the change is proven. Leave proxying as the zone's convention for sibling records rather than deciding it fresh.
4. Verify resolution from outside your own cache: resolve the name against a public resolver, not the local one, and confirm the answer matches what you wrote.
5. Verify it serves. Request the URL over HTTPS and read the status and the certificate's subject. A record that resolves to a service with no certificate for that name is a browser warning, not a working site.
6. Raise the TTL to the zone's normal value and say in one line which record changed, from what, to what.

Never, without asking

• Delete or edit a record you were not asked about, including one that "looks unused". MX, TXT and CNAME records carrying mail authentication or a domain verification look unused right up to the day mail stops.
• Change nameservers, or move a zone between accounts.
• Purge cache for a whole zone as a first response to "it looks stale" — purge the file.