DNS changes feel random until you remember resolvers cache answers.
| Record | Purpose |
|---|---|
| A / AAAA | IPv4 / IPv6 address |
| CNAME | Alias one name to another |
| MX | Mail destination |
| TXT | Verification and email policy |
The workflow that avoids surprises: set the record your provider requests, confirm the authoritative answer with dig, and plan changes around TTL—not around your browser cache.
A CNAME cannot coexist with other records at the same name in standard DNS. Use provider-specific alias features knowingly.
DNS is a distributed cache with a naming protocol. Debug it from authoritative records outward.
Records that look similar but are not
An A record maps a name to IPv4; AAAA does the same for IPv6. A CNAME aliases one name to another and cannot normally share that exact owner name with MX, TXT, or other records. MX values point to hostnames, not IP addresses, and their lower numeric preference wins. TXT is intentionally generic: domain verification, SPF, DKIM, and DMARC all use it with different syntax.
dig +short A api.example.com
dig +short TXT example.com
dig @ns1.provider.example example.com SOA
Test against an authoritative nameserver when a change is new, then a public resolver when diagnosing cached behaviour. A local
diganswer only tells you what that resolver knows right now.
Treat TTL as a rollout constraint
Lower a high TTL before a planned move, wait for the old value to age out, then change the target. Do not set an ultra-low TTL permanently: it increases authoritative query traffic without making every client cache disappear on command.
Cover photo by Stanislav Kondratiev on Pexels.