How DNS Really Works
Every connection starts with a name lookup you never see and rarely question.
What you will learn
- -Trace a recursive lookup from stub resolver to authoritative server
- -Read the record types that carry real weight in an assessment
- -Explain why caching and TTLs shape both performance and attacks
Before your browser sends a single byte to a , it asks a question in the dark: "what is the address for this name?" It trusts whatever answer comes back. That blind trust is the reason matters to anyone doing security, and it is why understanding the plumbing pays off before you ever touch an attack.
DNS turns names people can remember into addresses machines can route. example.com becomes 93.184.216.34. The whole exists because nobody wants to memorize an address, and because the address behind a name can change without the name changing.
The lookup nobody watches
Say you type a hostname. Your machine's stub resolver, the tiny baked into the OS, does almost no work itself. It hands the question to a recursive resolver, usually your ISP's box or something like 1.1.1.1 or 8.8.8.8. That resolver does the legwork.
The recursive resolver walks the tree from the top. It asks a who handles .com. Root points it at the .com TLD servers. Those point it at the authoritative name server for example.com. The authoritative server is the source of truth, the one whose owner actually set the records. Its answer flows back up the chain to you.
$dig example.com A$dig +trace example.com$dig example.com NSRun dig +trace once and the abstract tree becomes concrete. You see the root referral, then the .com referral, then the final authoritative answer. That is the whole recursion, printed.
Records that actually matter
A zone is a bag of records, each a type. You do not need all of them, but a handful come up constantly.
- A and AAAA: the and IPv6 addresses a name points to. The payoff record.
- CNAME: an alias.
wwwis a CNAME to the real . Dangling CNAMEs pointing at deprovisioned cloud are a whole subdomain-takeover class. - MX: mail servers for the . Read these before any phishing or email-security work.
- TXT: free-form text. SPF, DKIM, and domain-verification live here, which makes TXT a quiet goldmine during recon.
- NS and SOA: who is authoritative, and the zone's serial and timers.
That 3600 is the TTL, in seconds. It tells every resolver how long it may cache this answer before asking again.
Caching is the point, and the problem
Nobody could run the internet if every lookup walked to the root. So resolvers cache. Once 1.1.1.1 learns example.com is 93.184.216.34, it holds that for the TTL and serves it to the next thousand people who ask.
Caching is why DNS is fast. It is also why DNS attacks pay off. Poison one cache entry on a busy resolver and you everyone behind it until the TTL expires. Hold that thought, because it is the core of the next lesson.
Passive lookups against public records are low , but heavy , zone-transfer attempts, and brute-forced subdomain floods are active recon that some forbid and some jurisdictions treat as unauthorized access. Point this at your own domains, a lab like the ones in a home range, or a target with written . Stay inside the engagement scope.
During a recursive lookup for www.example.com, which server holds the authoritative answer?
A record shows a TTL of 300. In one sentence, what does that let a recursive resolver do, and for how long?
Think about what the number is counting down, and who is doing the counting.