DNS Setup for Cloud Servers: Records, TTLs and Propagation

Registrar, Nameserver, Zone: Three Jobs People Confuse

Almost every confusing DNS problem starts with one mix-up. The company you bought the domain from, the service answering queries for it, and the file listing your records are three separate things, and they do not have to live together.

The registrar holds the registration and, critically, holds the list of nameservers published to the top level domain. The nameserver operator answers the actual queries. The zone is the set of records that operator serves.

So when you point a domain at a cloud server, you are really making two decisions. Which nameservers does the registrar advertise, and what does the zone hosted there contain. Change the first and nothing takes effect until the registry updates the delegation; change the second and the answer changes as soon as caches expire.

A quick way to see the current state is to ask the authoritative servers directly rather than your local resolver:

dig +trace example.com

That walks the chain from the root down and shows you exactly which nameservers the registry hands out, which is usually where a stale delegation reveals itself.

The Records a Cloud Server Actually Needs

You need far fewer record types than the specification defines. For a typical application server the list is short.

One rule trips people constantly: a CNAME cannot coexist with other records at the same name, which means the apex of a domain cannot be a CNAME, because the apex always carries NS and SOA records. Managed DNS providers solve this with a synthetic record type, variously called ALIAS, ANAME or an alias record, that resolves the target and returns addresses instead. If your provider offers it, use it for the apex rather than pinning an address by hand.

If the server sends mail, the TXT records matter more than everything else combined, and the outbound path itself has provider restrictions covered in the port 25 article.

TTL Is a Promise You Have to Keep

Every record carries a time to live, the number of seconds a resolver may cache the answer. It is not a suggestion and it is not a refresh interval. It is the maximum time the old answer can still be served after you change it.

The practical consequence is that TTL must be lowered before a change, not during it. If a record sits at a long TTL and you edit it, resolvers that cached it keep the stale value for the remainder of that window, and no amount of clearing your own cache affects them.

The workflow that always works:

1. Lower the TTL on the records you plan to change, to something short like 300 seconds.
2. Wait for the old, longer TTL to fully elapse. This is the step people skip.
3. Make the change and verify it.
4. Once traffic has settled, raise the TTL back to an hour or more.

Longer TTLs are genuinely better in steady state. They reduce query volume, they make resolution faster for users, and they keep your site resolving if your DNS provider has a bad hour. Reserve short values for records you are actively moving, such as during a deployment cutover.

Propagation Is Mostly a Myth

The phrase suggests your record slowly spreads across the internet. It does not. Authoritative servers receive the change in seconds, and every resolver that had nothing cached gets the new answer immediately.

What you are actually waiting for is caches expiring, on a schedule you set yourself with the TTL. Two other things masquerade as propagation and are worth ruling out separately.

The first is a delegation change. Swapping nameservers at the registrar updates records in the top level domain zone, and those carry TTLs set by the registry rather than by you, often measured in days. Keep the old zone serving correct answers until that window has passed.

The second is a resolver that ignores TTLs. Some consumer routers and corporate resolvers cache far beyond the advertised value. You cannot fix those, which is another argument for making cutovers survivable rather than instant: keep the old address serving traffic, or redirecting, until logs show it has gone quiet.

Verify against the source rather than against your laptop:

dig @ns1.example-provider.com www.example.com A +noall +answer

Choosing Where the Zone Lives

Most cloud providers will host your zone at no extra charge, and for a single application that is usually the right answer. DigitalOcean, Vultr, Linode, Hetzner and Scaleway all include DNS hosting in the control panel and expose it through their APIs, so records can be created by the same automation that creates the server. The DigitalOcean DNS documentation is a good reference for how that model works in practice.

The hyperscalers treat DNS as a product with more behind it. Amazon Route 53 adds health checks, weighted and latency based routing, and alias records that point at load balancers without an address; the Route 53 developer guide describes the routing policies. Azure DNS and Cloud DNS offer comparable capabilities inside their own ecosystems.

Two arguments favour keeping DNS separate from the servers it points at. If the provider has an outage that takes both down, you lose the ability to redirect traffic elsewhere at exactly the moment you need it. And a domain whose zone lives outside the compute account is easier to move when you change providers.

Whichever you pick, manage the zone as code. Both a DigitalOcean account and a Vultr account expose record management through their CLI and API, which fits naturally into whatever provisioning workflow already creates the instance. Their control panels differ in more than DNS, as the DigitalOcean and Vultr comparison sets out. Hand edited zones drift, and nobody remembers why a record exists.

A Short Debugging Sequence

When a name does not resolve the way you expect, work outward in this order rather than guessing.

• Confirm the delegation with dig NS example.com and compare it to what the registrar shows.
• Query an authoritative server directly to see the true record, bypassing every cache between you and it.
• Query a public resolver such as dig @1.1.1.1 example.com to see what the wider internet currently has cached.
• Check the TTL on the answer. A large remaining value tells you how long the stale record still has to live.
• If a certificate fails to issue, check the CAA record before anything else, as covered in the TLS certificates guide.

The record formats themselves are defined in RFC 1035, which is more readable than its age suggests and settles most arguments about what is legal in a zone.

Common DNS Questions