The Six Records You'll Actually Use
There are dozens of DNS record types; day-to-day operations involve about six. Each answers a different question: which IP does this name point to, is this name an alias for another, where should mail for this domain go, and who is authoritative for answering queries about it.
Confusing the types is the most common source of error, and the symptoms are rarely obvious — writing an A record where a CNAME belonged works perfectly until the other end changes IP, which might be months later.
| Type | Purpose | Common mistake |
|---|---|---|
| A | Points a name at an IPv4 address | Hard-coding an A record when the target IP moves |
| AAAA | Points a name at an IPv6 address | Setting only A, leaving IPv6 users unable to reach you |
| CNAME | Makes a name an alias for another name | Placing one at the apex — the protocol forbids it |
| MX | Names mail servers and their priority | Entering an IP instead of a hostname; inverting priority |
| TXT | Holds verification strings (SPF, DKIM, ACME) | Multiple SPF records, which breaks validation |
| NS | Names who is authoritative for the domain | Editing NS at both registrar and DNS host, conflicting |
The table lists all six with the mistake each most often invites. The third column is the one to read.
Why the Apex Can't Use CNAME
This is the constraint people hit most often, and it isn't a configuration problem — it's specified behaviour:
- A CNAME cannot coexist with other records The DNS specification requires that if a name has a CNAME, it can have no other record type at that same name. The rule itself is simple; the trouble is how it collides with what an apex domain necessarily contains.
- An apex necessarily has SOA and NS records Every domain's apex (`example.com` itself) must carry SOA and NS records — that's what makes it resolvable at all. Since the apex always has those, the previous rule means a CNAME can never be added there. The two cannot coexist.
- So pointing an apex at a name requires an alternative Most DNS providers offer ALIAS, ANAME, or "CNAME flattening": externally it looks like an A record, but the provider resolves the target name behind the scenes and returns its current IP. The effect approximates CNAME while staying compliant. Note this is **not a standardised feature** — names and behaviour differ per provider, so re-verify when switching.
TTL: Adjust It Before the Change
TTL (Time To Live) is how you tell every resolver in the world how long this record may be cached. Set 3600 and for the next hour, any resolver that already asked won't ask again — it serves the cached answer.
So when a change doesn't appear to take effect, the cause usually isn't "propagation takes time", it's that **the old record's TTL hasn't expired**. And crucially: lowering TTL now is too late, because the copy resolvers are holding carries the TTL that was in effect when they fetched it.
Operationally, records that rarely change (MX, NS) can carry longer TTLs, while records you may need to switch in a hurry (an A record pointing at origin) are worth keeping short. It's a trade-off between stability and agility, with no single right answer.
Two Practical Traps in TXT Records
TXT is the messiest type, because it's where all kinds of verification data ends up: domain ownership proofs, SPF, DKIM, DMARC, and the ACME DNS-01 challenge values used in certificate automation. Different formats, all sharing one name.
The first trap is that **SPF must be a single record**. Adding a second SPF entry for a new mail service doesn't mean both apply — validation simply fails. All sources belong merged into one record. The second is that **certificate validation TXT records change frequently**, so without a DNS provider API you can't automate it — and as certificate lifetimes shorten, that becomes manual work several times a year.
Three Practical Judgements
Settle these before configuring anything:
1. Will the target's IP change?
If it will, use a CNAME pointing at the provider's hostname and let them manage the IP; only use an A record when it won't. This matters most for CDNs and cloud load balancers, whose IPs are expected to move — hard-coding an A record there plants a fault that detonates at an unpredictable time.
2. How often will this record change?
That sets the TTL. Rarely-touched records take a longer value (3600+); anything you may need to switch urgently takes a shorter one (around 300). The point is **setting it short before you need it short**, not during the incident.
3. Who is authoritative for this domain?
NS records decide who answers queries. A common mess: NS edited once at the registrar and again in the DNS provider's panel, leaving the two inconsistent. What takes effect is the registry's copy — the one set at your registrar. This bites hardest when transferring a domain or switching DNS providers.
Three Things to Check Before Changing Anything
These three save considerable debugging time:
- Check the current TTL It sets your maximum wait. If it's 86400 (a day) and you didn't lower it in advance, prepare to wait a day — repeatedly refreshing the browser won't help.
- Confirm which layer you're editing Registrar, DNS host and CDN may each present a "DNS settings" panel. Check where NS points first; only that provider's settings take effect. Editing at a non-authoritative provider produces no result no matter how many times you try.
- Verify against the authoritative server `dig @authoritative-server name TYPE` queries the authoritative server directly, bypassing every cache, and confirms immediately whether the record itself is right. If the authoritative answer is correct but elsewhere is stale, you're simply waiting on TTL.
In Summary
Waiting for a DNS change isn't mysterious — the wait is the TTL you set. Once that's clear, the correct migration order follows: **lower the TTL, wait one old period, then make the change.** Adjusting TTL afterwards does nothing for the change you're making now.
The other thing worth retaining is that an apex can't take a CNAME. That's protocol-level; the ALIAS and flattening features providers offer are their own workarounds, not a standard. When choosing a DNS provider, both that feature and API availability — the prerequisite for certificate automation — are worth confirming.