In a nutshell DNS (the Domain Name System) is the service that translates human-friendly site names into the numeric IP addresses computers actually use to find each other. It's "the phone book of the internet": you remember the name, and the system fills in the number.
Why DNS exists at all
Every device on a network has an IP address — a number like 142.250.185.78. Computers only talk over these addresses. But a human can't memorise a numeric address for every site — whereas google.com, youtube.com, tryhackme.com are easy.
DNS bridges that gap: you type a name, and it finds the matching address on the fly. And it isn't one server with a giant list (that couldn't take the load of the whole world and would be a single point of failure) but a distributed system of millions of servers, where responsibility is split across levels.
Analogy: the contacts in your phone. You tap "Mum," the phone fills in the number and dials. You don't need to remember the digits — just the name. DNS does the same for the whole internet.
What a domain name is made of
A name is read right to left — from the most general to the most specific. Take blog.example.com:
blog . example . com .
subdomain second-level TLD root
domain (top) (the dot, usually
not written)
- Root — the invisible "dot" at the very end (
example.com.). Every lookup starts from it. There are only 13 groups of root servers in the world. - TLD (Top-Level Domain) —
.com. They come as:- generic (gTLD):
.com,.org,.net,.info; - country-code (ccTLD):
.ru,.de,.uk— tied to a country.
- generic (gTLD):
- Second-level domain —
example. This is what a company buys from a registrar.example.comas a whole is "the domain." - Subdomain —
blog. The domain owner creates as many subdomains as they like:blog.,shop.,mail.,api.. Each can point to its own server.
Recon Subdomains are a frequent recon target. A company might have set up
dev.example.comoradmin.example.comand forgotten to lock it down. Hunting forgotten subdomains (subdomain enumeration) is a topic of its own in web pentesting.
Types of DNS record
A single domain stores not one value but a whole set of records of different types. Each answers its own question:
A — IPv4 address
The most common. Says which IPv4 address a name has.
dig example.com A +short # → 93.184.216.34
AAAA — IPv6 address
The same, but for the new address format (IPv6, of which there are far more than IPv4). Read as "quad-A".
dig example.com AAAA +short
CNAME — alias (canonical name)
Says "this name is really an alias of another." For example, www.example.com is often a CNAME to example.com. On getting a CNAME, the browser goes and asks for the A record of that other name.
Analogy: "Ivan Petrov — see also under the alias Ivan Ivanov." You're redirected to the real record.
MX — mail servers (Mail eXchange)
Where to deliver mail for this domain. A record has a priority (a number): the lower it is, the more primary the server; the rest are backups.
dig example.com MX +short # → 10 mail.example.com.
Recon: the MX records show which mail a target uses (their own server? Google Workspace? Yandex?).
TXT — arbitrary text
A free text field. In practice it's almost always service data:
- SPF/DKIM/DMARC — records that protect a domain from forged mail (they say which servers may send mail in its name).
- Ownership verification — Google and other services ask you to add a TXT record to prove the domain is yours.
dig example.com TXT +short
NS — name servers
Points to which DNS servers authoritatively answer for this domain. If they are, say, Cloudflare's servers, then Cloudflare holds the domain's DNS.
dig example.com NS +short
| Record | Answers the question |
|---|---|
| A | which IPv4? |
| AAAA | which IPv6? |
| CNAME | this is an alias of what? |
| MX | where do I send mail? |
| TXT | what service text is stored? |
| NS | who answers authoritatively for the domain? |
How a DNS query travels (step by step)
What happens from "typed the address" to "the site opened":
- Cache on your computer. Asked recently? Take it from memory, go no further.
- Recursive resolver. The "middleman" that takes the whole lookup on itself. Usually your ISP's DNS or a public one — Google
8.8.8.8, Cloudflare1.1.1.1. It has its own cache. - Root server. The resolver doesn't know — it goes to the root. The root doesn't know the site's IP but hints: "the
.comzone is handled by these TLD servers." - TLD server (
.com). Also doesn't know the exact IP, but says: "example.comis handled by these NS servers." - Authoritative server. The finale: the server that really holds the records for
example.comreturns the needed A record with the IP.
The answer travels back along the chain, is cached at each step, and the browser heads for the IP it got.
The whole analogy: you're looking for a person's number in a huge country. Directory assistance (the resolver) doesn't know, but points you by region: country → region (root → TLD) → city (NS) → and in the city they finally give you the number (authoritative). Directory assistance writes the answer down so it doesn't have to run around next time (the cache).
TTL — why changes "don't take effect at once"
Every record has a TTL (Time To Live) — how many seconds it may be kept in cache before being asked for again. So when a domain "moves" to a new IP, part of the world still sees the old one for a while — until the cache expires. This also explains why, after you change DNS settings, the changes "spread" gradually.
Why DNS matters in security
- Recon (passive): A/AAAA give the IP, MX the mail, NS the DNS provider, subdomains the forgotten services. All of it — before touching the server itself.
- Attacks on DNS: DNS spoofing / cache poisoning (feed the victim a false answer and steer them to a fake site), DNS tunnelling (hide data inside DNS queries to slip past filters).
- Hiding infrastructure: services like Cloudflare hide a server's real IP behind their own addresses — the A record shows only Cloudflare, not the origin.