DNS Explained for Developers: Records, TTL and "Propagation"

Sooner or later every developer has to point a domain at a server, verify a domain for an email service, or figure out why a site works on their laptop but not their phone. All of that is DNS. It's less mysterious than it looks.

What DNS does

The Domain Name System is the internet's phone book. It maps names people can remember (example.com) to the information computers need, mostly IP addresses, but also mail servers, verification tokens and more.

Each domain's DNS data is managed by its authoritative nameservers, which you choose at your registrar. Everyone else asks resolvers, which cache answers. (The full request journey.)

The records you'll actually use

Record	Purpose	Example
A	Name → IPv4 address	example.com → 203.0.113.10
AAAA	Name → IPv6 address	example.com → 2001:db8::10
CNAME	Name → another name (an alias)	www → myapp.hosting.com
MX	Where email for the domain goes	10 mail.provider.com
TXT	Free text, used for verification and email security	v=spf1 include:... ~all
NS	Which nameservers are authoritative	ns1.provider.com
CAA	Which certificate authorities may issue certificates	0 issue "letsencrypt.org"

The CNAME rule that trips people up

A CNAME says "this name is an alias for that name," so it can't coexist with other records on the same name. The root of your domain (example.com, called the apex) always has other records like NS and usually MX, so a standard CNAME isn't allowed there.

That's why hosting platforms ask for an A record on the apex and a CNAME for www. Many DNS providers also offer a workaround called CNAME flattening, or ALIAS/ANAME records, that behaves like a CNAME at the apex.

TTL and the myth of propagation

Every record has a TTL, a number of seconds that resolvers may cache the answer. When you change a record, resolvers that cached the old value keep using it until their TTL expires.

That's all "DNS propagation" really is: caches expiring at different times around the world.

A practical trick for planned changes, like moving to a new server:

1. A day or so before, lower the TTL to something short, say 300 seconds.
2. Wait for the old, longer TTL to pass.
3. Make the change. Most of the world picks it up within minutes.
4. Afterwards, raise the TTL again.

Email records worth knowing

If your domain sends email, three TXT-based records decide whether it lands in the inbox:

• SPF lists the servers allowed to send mail for your domain.
• DKIM publishes a public key so receivers can verify message signatures.
• DMARC tells receivers what to do when SPF or DKIM checks fail, and where to send reports.

Without them, your password resets and receipts are likely to end up in spam. (Email deliverability guide.)

Troubleshooting commands

Don't guess. Ask DNS directly.

# What does DNS say right now?
dig example.com A +short
dig www.example.com CNAME +short
dig example.com MX +short
dig example.com TXT +short

# Ask a specific public resolver, bypassing your local cache
dig @1.1.1.1 example.com A +short

# Ask the authoritative nameserver directly (the source of truth)
dig example.com NS +short
dig @ns1.yourprovider.com example.com A +short

# Windows equivalent
nslookup example.com 1.1.1.1

If the authoritative server shows the new value but your machine shows the old one, it's caching. Wait it out, or flush your local DNS cache. Browser-based DNS checkers that query from many locations are also handy for seeing who has the new answer.

Common problems and fixes

• Site works on desktop but not phone (or vice versa). Different resolvers have different cached answers. Check with dig against a few public resolvers.
• "Domain not verified" on a hosting platform. Usually a typo in the record name. Many DNS dashboards automatically append your domain, so entering www.example.com creates www.example.com.example.com.
• Changed nameservers, nothing works. Records live at the new nameservers now. Recreate them there before switching.
• Emails stopped arriving after a migration. MX records didn't get copied over. Always export or screenshot DNS before moving providers.
• HTTPS certificate fails to issue. DNS doesn't point at the host yet, or a CAA record blocks that certificate authority.

FAQ

How long does DNS propagation take?

It depends on the TTL of the old records. With low TTLs, changes reach most users within minutes. With long TTLs (often an hour to a day), some users can see old values for that long.

Why can't I use a CNAME on my root domain?

A CNAME can't coexist with other records on the same name, and the root domain always has NS and SOA records. Use an A record, or your provider's ALIAS or CNAME-flattening feature.

What DNS records do I need for a website?

Usually an A record for the root domain (or ALIAS) and a CNAME for www, as specified by your host. If you send email, add MX, SPF, DKIM and DMARC records too.