You ship a site. SSL fails. Someone says "check the A record." You nod, open a tab, and type the same search you've typed a dozen times: A vs CNAME vs MX.
You fix it. Two months later a TXT record for email auth shows up and your brain is empty again. TTL? Glue? Why does dig show two answers and nslookup shows one? Same dance.
DNS is not hard once it's loaded. The problem is it unloads the second you stop touching it.
Pick a mental model, not a bookmark pile
Most people start with a table of record types. Tables are fine for lookup. They are terrible for memory. You need one picture you can redraw on a whiteboard without notes.
Mine is boring and it works: a name asks a question, a record is the answer, and a resolver is the messenger that fetches that answer (and may cache it).
- An A record answers "what IPv4 address?" for
example.com. - An AAAA answers the same for IPv6.
- A CNAME answers "this name is an alias of that other name," then you resolve the target.
- An MX answers "which hosts handle mail, and in what priority order?"
- A TXT answers with plain text, which is why SPF, DKIM, and verification strings live there.
TTL is how long a resolver may trust a cached answer before asking again. Short TTL means changes propagate faster. Long TTL means fewer lookups and a longer wait when you fat-finger a record.
Recursion is the resolver doing the scavenger hunt: root → TLD → authoritative. Iterative is you walking that chain yourself. Day to day you use a recursive resolver and only dig into the chain when something breaks.
Write that model in five lines. If you can't, you're still collecting tabs instead of learning.
Practice on real domains with dig
Flashcards without a terminal are half a skill. Open a shell and hit domains you already know.
dig example.com A +short
dig example.com NS
dig example.com MX
dig google.com TXT +short
Read the answer section first. Then add flags on purpose:
dig @1.1.1.1 example.com A
dig example.com A +trace
+trace walks the recursion path so you see root hints, TLD servers, then the authoritative answer. Do this once on a domain you control and once on a public one. The next time a CNAME looks stuck, that output stops looking like hieroglyphs.
nslookup is fine in a pinch. dig is clearer when you want the raw record story. Pick one default for a month so the flags stick.
Concrete drill: for three domains you care about, write down expected A/AAAA, whether www is a CNAME, and who the MX points at. Then dig and check yourself. Wrong guesses are the point.
Tiny questions beat another 40-minute video
After one good explainer (Cloudflare's DNS docs, or a single walkthrough you trust), stop collecting more. Turn the gaps into short questions:
- What does a CNAME forbid at the zone apex that an A record does not?
- If MX priority is 10 and 20, which host is tried first?
- You change an A record. TTL was 3600. Roughly how long can old resolvers keep the previous IP?
- What's the difference between a recursive resolver and an authoritative nameserver?
- When would you reach for TXT instead of inventing a new record type?
Answer from memory the next day. Mark the ones you blanked on. Re-read only those sections. A week later, run the same five without notes. Spaced repetition here is a calendar reminder and honesty. Rewatching feels familiar; retrieval tells you what stuck.
Keep the questions next to the source. A loose dns-quiz.md beside a dead bookmark helps nobody.
Where the "I'll remember this" lie shows up
The Watch Later graveyard is full of DNS explainers. So is the bookmark folder named Infra. You save the video the day SSL breaks, feel responsible, and never open it again. Next outage, new search, new save.
When something finally clicks, say the moment +trace makes recursion obvious, capture the source and three lines in your own words. Not a transcript. Something like: "CNAME is an alias, then resolve the target," "MX lower number = higher preference," "TTL is cache permission, not a promise the world updates instantly."
That short note is what you reopen six weeks later. The video is the receipt. You should not need to scrub to minute 18 to remember what an SOA serial is for.
How I keep DNS from leaking out again
I got tired of re-Googling the same five record types. Now when I find a solid DNS write-up or video, I save it into Recl. It's a memory app: drop in links, YouTube, articles, or notes; get a TL;DR and key takeaways; land them under library topics; then get spaced-repetition recall nudges and short quizzes so the material comes back before the next outage.
For DNS that means one trusted explainer and my dig cheat-sheet live together. The summary surfaces A/CNAME/MX/TXT points so I can skim before a deploy. I still add my own three-line note so the "why" stays in my words. Months later, when a TXT verification ticket lands, I can ask the library and get an answer with sources instead of starting a fresh spiral.
There's a share sheet on mobile and a Chrome extension (Ctrl/Cmd+Shift+S) when you're already in the browser. Tagline that fits: save what matters, recall it forever.
You don't need an app to learn DNS. A dated note and a reminder beat another abandoned bookmark. The habit is the product: capture the bits that evaporate, then retrieve them on purpose.
Try this before your next DNS ticket
Before you open a new tutorial, write what you still remember about A vs CNAME vs MX. Dig three real domains. Write five tiny questions. Quiz tomorrow and again next week.
If record types feel brand new every quarter, treat the gap between learning and recall as the real bug. Close it on purpose, and the next SSL or email-auth ticket starts at "check TTL and authority" instead of "what was an AAAA again?"
Asutosh Pattanayak built Recl — a memory / second-brain app for saving links, articles, videos, and notes, then actually remembering them.
Top comments (0)