DNS Records for Developers — A, CNAME, MX, TXT, and the TTL That Made You Wait 48 Hours

You bought a domain, pointed it somewhere, and now you’re staring at a browser that still shows the old site. Or you misconfigured your MX records and discovered that when emails start bouncing. DNS is one of those things developers mostly ignore until it bites them — and when it does, the feedback loop is slow and painful.

This isn’t a tutorial for people who’ve never heard of DNS. It’s a reference for developers who know what a domain is but reach for Stack Overflow every time they need to add a record type they haven’t touched in six months.

How DNS actually works (the 30-second version)

When a browser resolves example.com, it asks a recursive resolver (usually your ISP or 8.8.8.8). The resolver checks its cache. If there’s a cache hit, it returns the cached answer. If not, it walks up the DNS tree — root nameservers → TLD nameservers (.com) → your domain’s authoritative nameserver — and caches the result for however long the TTL says.

Every DNS record has a type, a name, a value, and a TTL. That’s it. The complexity comes from knowing which type does what and where records interact in non-obvious ways.

The record types you’ll actually use

A Record — IP address for a hostname

Maps a hostname to an IPv4 address. This is the most common record you’ll touch.

example.com.     300   IN  A   93.184.216.34
www.example.com. 300   IN  A   93.184.216.34

The gotcha: you can have multiple A records for the same hostname. DNS will return all of them, and the client picks one (usually round-robin). This is a common poor-man’s load balancing setup — but if one of those IPs goes down, DNS has no health checks. It’ll keep serving the broken IP until the TTL expires and you remove it.

For IPv6, the equivalent is an AAAA record. Same concept, 128-bit address instead of 32-bit.

CNAME Record — Alias to another hostname

Points one hostname at another hostname (not an IP). The resolver follows the chain until it hits an A record.

www.example.com.    300  IN  CNAME  example.com.
blog.example.com.   300  IN  CNAME  mysite.netlify.app.

CNAME vs A — when to use which: If you’re pointing to a service that gives you a hostname (Netlify, Vercel, GitHub Pages, Heroku, most CDNs), use a CNAME. If you have a static IP, use an A record. Simple.

The hard rule: you cannot put a CNAME on your zone apex (the bare domain — example.comXML没有数字类型——所有内容都是文本。你的价格字段将是 www.example.com). RFC 1034 prohibits it because the apex has to hold SOA and NS records, and a CNAME at the same name would conflict. When Netlify or Vercel tell you to add a CNAME for your root domain, what they actually mean is to use their DNS provider which supports ANAME or ALIAS records — a proprietary extension that behaves like CNAME but resolves to A records at the zone level.

Also: never CNAME to a CNAME if you can avoid it. Technically legal but each hop in the chain is an extra DNS lookup. More importantly, if the intermediate CNAME breaks, your record breaks too.

MX Record — Mail routing

Tells other mail servers where to deliver email for your domain. MX records have a priority number — lower number = higher priority.

example.com.  3600  IN  MX  10  mail1.example.com.
example.com.  3600  IN  MX  20  mail2.example.com.

If mail1 is unavailable, sending servers will try mail2. This is proper fallback, not load balancing — you’re not splitting traffic, you’re specifying a preference order.

The mistake developers make: pointing MX at an IP address or a CNAME. MX values must point to A records (hostnames), not IPs or CNAMEs. Some DNS providers will let you save this misconfiguration without warning, and then your email silently fails.

If you’re setting up Google Workspace or Microsoft 365, they’ll give you a set of MX records. Don’t modify the priority numbers thinking you’re being clever — the mail routing logic depends on them being exact.

TXT Record — Arbitrary text, mostly for verification and email auth

TXT records hold free-form text strings. In practice, they’re used for three things:

• Domain verification — Google Search Console, Stripe, GitHub, and a hundred other services will ask you to add a TXT record to prove you own the domain
• SPF (Sender Policy Framework) — specifies which mail servers are allowed to send email as your domain
• DKIM and DMARC — email authentication records that prevent spoofing

An SPF record looks like this:

example.com.  3600  IN  TXT  "v=spf1 include:_spf.google.com include:sendgrid.net ~all"

This says: Google and SendGrid are allowed to send email for this domain; anything else should be treated with suspicion (~all = soft fail, -all = hard fail).

A DMARC record lives at _dmarc.example.com:

_dmarc.example.com.  3600  IN  TXT  "v=DMARC1; p=quarantine; rua=mailto:dmarc@example.com"

The important thing: you can only have one SPF TXT record per domain. If you add a second one (because a new service told you to), both records will exist, mail servers will see conflicting policies, and email authentication will break. Merge them instead: v=spf1 include:_spf.google.com include:sendgrid.net ~all.

NS Record — Nameserver delegation

Specifies which nameservers are authoritative for your domain. You typically set these at your domain registrar, not in your DNS zone directly. When you migrate from one DNS provider to another (say, from GoDaddy’s nameservers to Cloudflare), you’re updating NS records at the registrar level.

NS record propagation is why domain migrations are slow. NS TTLs are often 24–48 hours, and registrar changes have their own propagation delay on top of that.

TTL — the number that made you wait 48 hours

TTL (Time To Live) is a number in seconds. It tells caching resolvers how long to remember an answer before asking again. A TTL of 300 means five minutes. A TTL of 172800 means 48 hours.

When you change a DNS record, the old answer is still cached everywhere for up to the old TTL. If your A record had a 48-hour TTL and you just changed the IP, some users will hit the old server for up to two days — and there’s nothing you can do about it once the change is made.

The fix is to lower the TTL before you make a change. Standard practice for planned migrations:

1. Lower TTL to 300 (5 minutes) at least 48 hours before the migration — you have to wait for the old high TTL to expire first
2. Make the DNS change
3. Wait 5–10 minutes for propagation
4. Raise TTL back to something reasonable (3600–86400) once you’ve confirmed the new config works

If you forget step 1 and go straight to step 2 with a high TTL, you’re stuck. You can lower the TTL now, but that only shortens the wait for resolvers that haven’t cached it yet. Anything that already cached the record has to wait out the original TTL.

Quick reference

Record	Points to	常用	Gotcha
A	IPv4 address	Hostname → server IP	No health checks — broken IPs stay in rotation until TTL expires
AAAA	IPv6 address	Hostname → IPv6 server	Easy to forget to add alongside A record for dual-stack support
CNAME	Another hostname	Aliases, CDN/PaaS routing	Cannot use at zone apex; MX/NS cannot point at a CNAME
MX	Hostname (A record)	Email delivery routing	Value must be a hostname, not an IP; priority numbers matter
TXT	Free-form text	SPF, DKIM, DMARC, domain verification	Only one SPF record allowed per domain — merge, don’t add
NS	Nameserver hostname	DNS delegation	Changes go through the registrar and propagate slowly
CAA	CA domain	Which CAs can issue SSL certs for your domain	Easy to lock yourself out of cert renewal by misconfiguring

Things that will save you time

使用 dig directly, not a web tool. dig @8.8.8.8 example.com A bypasses your local resolver and shows exactly what Google’s DNS sees. Add +short for just the answer. Add +trace to walk the full resolution chain.

# Check what Google sees right now
dig @8.8.8.8 example.com A +short

# Check MX records
dig @8.8.8.8 example.com MX

# Check TXT (SPF, DMARC, verification tokens)
dig @8.8.8.8 example.com TXT
dig @8.8.8.8 _dmarc.example.com TXT

# Full resolution trace
dig @8.8.8.8 example.com A +trace

Check TTL before any migration. Run dig example.com A and look at the number in the third column of the answer section. That’s how long (in seconds) you might be waiting if you change the record right now without lowering the TTL first.

Cloudflare’s proxied records don’t expose your real IP. When you enable Cloudflare’s orange cloud on a record, the A record exposed to the world is Cloudflare’s IP, not yours. This is usually what you want for DDoS protection — but it means dig won’t show your server’s actual IP, and tools that probe your IP directly won’t work as expected.

你可能也会喜欢