DNS records are the routing table of the internet: small text entries that say where a name points, who handles its mail, and how strangers verify it owns itself. Six record types cover essentially everything a site owner touches.
The essential six #
$ dig +short aospix.com A # 104.21.5.10
$ dig +short aospix.com AAAA # 2606:4700:...
$ dig +short www.aospix.com CNAME # aospix.com.
$ dig +short MX aospix.com # 10 mx.zohomail.com.
$ dig +short TXT aospix.com # "v=spf1 include:..."
$ dig +short NS aospix.com # ns1.cloudflare.com.| Record | Maps a name to | Typical use |
|---|---|---|
| A | An IPv4 address | The site's home |
| AAAA | An IPv6 address | Same, modern |
| CNAME | Another name | www → apex, subdomains to services |
| MX | Mail servers (with priority) | Where email for the domain goes |
| TXT | Free-form text | SPF, DKIM, domain verification |
| NS | Authoritative servers | Who serves this zone |
Two quirks worth internalising: CNAMEs cannot exist at the apex (aospix.com itself needs A/AAAA or ALIAS support), and MX priorities are "lower wins first, numbers are not consecutive steps".
A working set, read as a story #
aospix.com. A 104.21.5.10
www CNAME aospix.com.
app A 203.0.113.7 <- self-hosted box
@ MX 10 mx1.provider.net
@ TXT "v=spf1 include:provider.net ~all"
_dmarc TXT "v=DMARC1; p=quarantine"The apex points at the site; www is an alias; app goes to a different machine — checked with dig +short app.aospix.com. Mail and its verification travel via MX and TXT. Nothing here is abstract: every line answers a question a visitor or mail server will actually ask.
TTL: how fast changes happen #
Every record carries a time-to-live — how long resolvers may cache it:
| TTL | Feel | Use |
|---|---|---|
| 300 (5 min) | Changes land fast | Cutover days, experimentation |
| 3600 (1 h) | Normal | Regular records |
| 86400 (1 d) | Slow to change | Stable records, fewer lookups |
The professional move before any IP migration: drop the TTL to 300 a day early, make the switch, raise it back. Waiting out a stale 86400 cache is the self-inflicted version of "the internet is broken".
The debugging view #
When a name misbehaves, the records themselves are the evidence — query the authority directly to bypass caching, and compare with what your resolver returns:
$ dig +short @ns1.cloudflare.com aospix.com # authoritative answer
$ dig +short aospix.com # what you're being toldA mismatch means propagation is still in flight — or that someone edited the wrong zone entirely.
Add the verification TXT records before you need them: providers from mail senders to CI ask for ownership proofs, and a zone with SPF and DMARC already in place stops both spam-forwarding and impersonation surprises.
Records feed everything upstream: the proxy, certificates, and hosting. The network series continues.