The problem DNS solves
Computers find each other using IP addresses, numeric labels like 142.250.80.46 for IPv4 or longer strings for IPv6. People are good at remembering names and bad at remembering numbers. DNS sits between the two worlds: you type a name, DNS hands back the address.
Without that translation layer you would need to memorize a numeric address for every site, mailbox, and service you ever touch. DNS removes that burden, which is why nearly every connection you make starts with a quiet DNS lookup you never notice.
The phone book analogy
Think of DNS as the contacts app on your phone. You know the person's name, you tap it, and the phone dials the number for you. You almost never type the raw number yourself.
Why this matters for troubleshooting
If you already knew the number, you could dial it without the contacts app at all. A computer is the same: it can still reach a host by its raw IP address even when DNS is completely down. DNS is a convenience, not a requirement. Hold onto that idea, because it is the foundation of every DNS diagnostic.
How a lookup actually works
When you enter example.com, a chain of questions fires off in the background. Most of it finishes in a few milliseconds.
Check the local cache
Your computer first looks at answers it already has. If it resolved example.com recently and the answer has not expired, it uses the cached address and stops here.
Check the hosts file
Before reaching the network, the system checks a local file you can edit by hand: /etc/hosts on Linux and macOS, C:\Windows\System32\drivers\etc\hosts on Windows. An entry here overrides DNS entirely.
Ask the recursive resolver
With no local answer, your computer sends the question to its configured DNS server. That is usually your router, your ISP's resolver, or a public resolver such as 8.8.8.8 (Google Public DNS).
Resolver asks a root server
The resolver starts at the top: "Who is responsible for .edu names?" A root server replies with the servers that handle the .edu top level domain.
Resolver asks the .edu TLD server
"Who is authoritative for example.com?" The TLD server replies with the names of the authoritative servers.
Resolver asks the authoritative server
"What is the address record for example.com?" This server holds the real answer and returns the IP address.
Resolver caches and replies
The resolver stores the answer for a set time, then hands it back to your computer. Your machine connects to that address and the page loads.
The walk from root to TLD to authoritative server is what makes DNS scalable. No single machine has to know every name on the internet. Each layer only knows who to ask next.
The DNS hierarchy
DNS is a tree. Reading it from the top down:
- The root zone, written as a single dot, sits at the very top and is served by the root name servers.
- Top level domains (TLDs) come next: .edu, .com, .org, .gov, and country codes like .uk or .ca.
- Second level domains are the names organizations register: example.com, google.com.
- Subdomains branch off from there: www.example.com, mail.google.com.
At each level, an authoritative server holds the official records for its slice of the tree. Delegation, one level pointing down to the next, is what lets the whole system stay distributed instead of living on one giant server.
Common record types
A DNS zone holds more than just addresses. These are the record types you will see most often.
A
Maps a name to an IPv4 address. The workhorse record.
AAAA
Maps a name to an IPv6 address. Spoken as "quad A."
CNAME
An alias. Points one name at another name rather than at an address.
MX
Mail exchange. Tells other servers where to deliver email for the domain.
NS
Name server. Lists the authoritative servers for the zone.
TXT
Free form text. Used for SPF, DKIM, and domain verification.
PTR
The reverse of an A record. Maps an IP address back to a name.
Those TXT records are where email authentication lives. The same DNS you use to reach a site is what mail servers query to check SPF and DKIM before trusting a message, which is why DNS shows up again in phishing and email forensics work.
Caching and TTL
Every record carries a TTL (time to live), a number of seconds that says how long the answer may be reused. Resolvers and your own computer cache answers until the TTL runs out.
Caching is why DNS feels instant most of the time and why authoritative servers are not buried under traffic. The tradeoff is propagation delay: when an address changes, the old answer can linger in caches until its TTL expires. You can clear your local cache on Windows with ipconfig /flushdns, and on Linux by restarting the resolver service.
DNS on the wire
DNS runs on port 53. Most lookups travel over UDP for speed, since a single question and answer fit in a small packet. TCP on the same port 53 takes over for larger exchanges, such as responses that exceed the UDP size limit or full zone transfers between servers.
- UDP 53: standard queries. Fast, connectionless, the common case.
- TCP 53: large responses and zone transfers between servers.
- DoH and DoT: DNS over HTTPS and DNS over TLS wrap queries in encryption so they cannot be read or tampered with in transit.
- DNSSEC: adds digital signatures so a resolver can verify an answer was not forged.
When DNS breaks
Because the network routes on IP addresses and DNS only supplies them, a DNS failure has a very specific signature: names stop resolving while raw IP addresses keep working. That asymmetry is not a nuisance, it is the clue. It lets you prove DNS is the culprit with two quick commands.
Troubleshooting DNS Issues →