A tree, not a flat list
DNS is structured like a global franchise business, not a single company you could look up in one place. The root level is like a headquarters: it doesn't know where "example.com" actually lives, but it knows exactly which regional office handles everything ending in .com. That regional office, a TLD (Top-Level Domain) server, doesn't know example.com's content either, but it knows which specific store location, the authoritative server for example.com, is licensed to answer for it. And that store can run its own departments, subdomains like www.example.com or mail.example.com, all still under the same license.
.com to. The .org branch is drawn the same way, it just isn't expanded here, since it delegates to just as many domains of its own.Record types: Different questions, different answers
A single name like example.com can have several different kinds of records, each answering a completely different question.
| Record | Full name | Answers |
|---|---|---|
| A | Address | Which IPv4 address does this name point to? |
| AAAA | Nicknamed "quad-A": four times the size of an A record | Which IPv6 address does this name point to? |
| CNAME | Canonical Name | What's the "real" name this is just an alias for? |
| MX | Mail Exchange | Which server handles email for this domain, and in what priority order? |
| NS | Name Server | Which servers are authoritative for this zone? |
| TXT | Text | Arbitrary text, commonly used for domain ownership verification, SPF/DKIM email policy |
| SOA | Start of Authority | The zone's master record: primary name server, admin contact, and cache refresh timers |
| PTR | Pointer | Reverse lookup: which name does this IP address belong to? |
| CAA | Certification Authority Authorization | Which CAs (Certificate Authorities) are even allowed to issue a certificate for this domain? |
The request and response, port by port
A DNS query isn't anything exotic: it's an ordinary UDP (User Datagram Protocol) datagram like any other, and it always targets the same destination port, 53. The client picks a random high-numbered source port for itself (see Ports & Sockets), sends its question to the server's port 53, and the server replies from its own port 53 back to whichever ephemeral port the client used. That's the entire exchange: one request, one response, over the socket mechanics already covered in the previous topic.
Most queries and their answers fit comfortably in a single UDP datagram, so this one round trip is the whole story. A response too large for that falls back to TCP on the same port 53, covered in UDP Header & Use Cases.
Why delegation matters
Nobody has to ask a single central server for every name on the internet, and nobody needs the root's permission every time a subdomain changes. The owner of example.com can add, change, or remove www.example.com and mail.example.com freely on their own authoritative server, since the root and the .com TLD only delegated authority for the zone, not control over what's inside it. That's what lets DNS scale to billions of names without a single bottleneck.
Every record carries its own TTL (Time to Live), how long a resolver is allowed to cache it before asking again. A short TTL means changes propagate fast but generates more lookup traffic; a long TTL means less load but slower failover if something changes. How resolvers actually use that cached answer is the next topic.