DNS for developers: records, TTLs and propagation
DNS maps names to the records that applications and infrastructure need. For most developers the work comes down to three things: choosing the right record type, setting a sensibl…
DNS maps names to the records that applications and infrastructure need. For most developers the work comes down to three things: choosing the right record type, setting a sensible TTL, and understanding why a change does not appear everywhere at the same instant.
DNS is a distributed database
A resolver starts with a name and asks the DNS hierarchy for the answer. The final answer normally comes from the authoritative name servers for the zone that holds the record.
Applications rarely query authoritative servers directly. They ask a recursive resolver, which performs the lookup on their behalf and caches the answer for reuse. Almost everything that feels confusing about DNS comes back to that caching layer.
Zones and authoritative servers
A zone is an administrative slice of the DNS namespace. Authoritative name servers hold the records for that zone. When a domain is delegated, records in the parent zone point resolvers towards the authoritative name servers for the child zone.
For day to day work the important question is which provider is authoritative for the domain or subdomain you are editing. Changing records in the wrong provider has no effect on the answers users actually receive.
Common record types
A records map a name to an IPv4 address. AAAA records map a name to an IPv6 address. CNAME records make one name an alias of another name. MX records identify mail exchangers. TXT records hold text values and are commonly used for domain verification and email authentication.
CNAME records need care. If a CNAME record is present at a name, no other data should be present at that same name. The record is an alias, so it cannot sit alongside A, MX or TXT records on the same owner name. Many providers offer CNAME-like convenience at the zone apex, but those are provider features rather than plain CNAME records.
TTL controls cache lifetime
TTL means time to live. It is a value in seconds that tells resolvers how long they may cache a DNS answer. A TTL of 300 allows caching for five minutes. A TTL of 86400 allows caching for 24 hours.
The TTL is a ceiling, not a promise. A resolver may discard an answer sooner, but it should not keep serving the cached answer once the TTL has elapsed. Lower TTLs let planned changes take effect sooner once caches refresh. Higher TTLs reduce lookup volume and can improve resilience when authoritative DNS is briefly unreachable.
Propagation is mostly caching
People say DNS is propagating, but most of the waiting is resolver cache expiry. After an authoritative record changes, resolvers that already cached the old answer can keep returning it until the old TTL expires.
Some resolvers cap or floor the TTL values they honour. Negative answers, such as a name that does not exist, can also be cached for a period controlled by the zone. That is why two users can see different answers during a change window.
Plan changes before you make them
For a planned migration, lower the TTL well before the cutover. Wait at least as long as the previous TTL so that caches have had time to pick up the lower value. Then make the record change. After the new target is stable, raise the TTL again if a longer value suits the record.
This does not make a change instant, but it caps the time that well behaved caches should keep the old answer.
Apex records need provider awareness
The zone apex is the bare domain, such as example.com. A plain CNAME is not valid at the apex, because the apex must carry the records that describe the zone, and a CNAME cannot coexist with other data at the same name. Many providers support ALIAS, ANAME, CNAME flattening or similar features to point an apex at another name.
These features are provider specific. Read the provider documentation and confirm what records are actually returned to resolvers.
DNS is not health checking by default
A normal A or AAAA record does not know whether the target service is healthy. It points to the configured address until the record changes and caches expire.
Some managed DNS providers offer health checked or load balanced records. Those are service features layered on top of DNS, and they still interact with TTLs and resolver caching.
Debugging DNS
Start by querying the authoritative name servers. That tells you what the source of truth currently says. Then query a public recursive resolver and the resolver used by the affected environment, and compare answers, TTLs and record types.
Check delegation too. If the parent zone points to different name servers than the ones you are editing, your changes will not be visible to normal resolvers.
Use exact names. A missing trailing dot in a provider UI, an unexpected subdomain, or editing www when the application uses the apex can all make a correct record look broken.
Conclusion
DNS changes are reliable when you know the authoritative provider, use the right record type and plan around TTLs. Treat propagation as cache expiry rather than magic. For migrations, lower the TTL in advance, verify the authoritative answer, and test from the resolvers your users actually use.