Internet Beginner 06 🌐 DNS and How It Works
When you type a website address into your browser and press Enter, your computer knows the name but not the destination. It has no idea where example.com lives, which server holds its files, or which network path leads there. The Domain Name System is the global lookup service that answers that question. It translates the human-readable name you typed into the numerical IP address that routers need in order to deliver your request. Without DNS, every website visit would require memorizing a string of numbers, and every server move would break every link and bookmark in existence.
The remarkable thing about DNS is that it is not a single database, not a single server, and not under anyone’s central control. It is a hierarchy of authorities, each responsible for a narrow slice of the naming space, with resolvers that walk that hierarchy on your behalf. The design has survived decades of exponential growth because it delegates responsibility instead of centralizing it. When you understand how the delegation works, how a resolver traverses it, and how answers are cached, you understand why the internet’s addressing system is both resilient and occasionally slow to update.
This chapter explains the hierarchy from root to authoritative server, the step-by-step resolution process, the record types that store the actual mappings, the caching that makes the system practical, and the security extensions that protect it from spoofing. By the end, you will know not just what DNS does but why it is built the way it is.
Key point: DNS is a hierarchical, distributed database that translates domain names into IP addresses; a recursive resolver walks the hierarchy from the root servers down through the top-level domain servers to the authoritative server for the queried domain, caching each answer for the duration of its Time to Live.
Why DNS is designed this way
The memorability problem. Computers route packets using numbers. Humans remember words. This mismatch is the original reason DNS exists. An IP address like 192.0.2.1 is meaningful to a router but meaningless to a person. A domain name like example.com is the opposite. DNS is the translation layer that lets people use names while machines use numbers . The alternative—embedding IP addresses in every link, bookmark, and business card—would make the web unusable the first time a server moved.
The scale problem. A single database containing every domain name on the internet would be impossibly large and impossibly slow, and it would be a single point of failure for the entire network. DNS avoids this by distributing responsibility. No single computer holds all the data. The root servers know only where to find the servers for top-level domains. The .com servers know only where to find the authoritative servers for domains ending in .com. Each level delegates authority downward, and each server is responsible for only its own zone . This delegation is what allows the system to scale: adding a new domain does not require updating every server in the world, only the authoritative server for that domain and the delegation records in its parent zone.
The consistency trade-off. Because the database is distributed, changes must propagate. When a domain owner moves their server to a new IP address, the change is made on the authoritative server for that domain. The rest of the system learns about the change only when cached copies expire, according to a Time to Live value set by the zone administrator. This loose coherence is deliberate. Instant global consistency would require every resolver to check every authoritative server on every lookup, which would be catastrophically slow. The TTL balances freshness against performance: short TTLs mean changes propagate quickly but lookups are slower; long TTLs mean faster lookups but slower propagation.
The performance problem. Walking the full hierarchy for every lookup would add hundreds of milliseconds to every page load. Caching solves this. When a resolver gets an answer, it stores it for the duration of the TTL. The next lookup for the same name is served from the cache, avoiding the network round trips entirely. This is why the first visit to a website may feel slightly slower than subsequent visits, and why a server move may appear to work for some users and not others until their caches expire.
The redundancy problem. Every level of the hierarchy is replicated. There are thirteen root server identities, each with many physical instances distributed globally. Top-level domain servers are replicated. Most domains have at least two authoritative nameservers. A resolver can query any of them, and if one is unreachable, another can answer . This redundancy is what keeps DNS available even when individual servers fail, and it is why the system has never suffered a total outage.
The security problem. DNS was designed without authentication. A resolver cannot tell whether a response came from the legitimate authoritative server or from an attacker who intercepted the query. This weakness enables DNS spoofing and cache poisoning, where an attacker injects false records into a resolver’s cache to redirect traffic. DNSSEC was developed to address this by adding digital signatures to DNS records, allowing resolvers to verify that an answer is authentic and unmodified .
a. The hierarchy: root, TLD, and authoritative servers
DNS is organized as an inverted tree. At the top is the root, written as a single dot .. Below the root are the top-level domains: the generic domains like .com, .org, and .net, and the country-code domains like .uk, .jp, and .de. Below those are the second-level domains that individuals and organizations register, like example.com. Below those are subdomains like www.example.com or blog.example.com.
Each node in the tree is a domain. A fully qualified domain name includes every label from the specific host back to the root, separated by dots, with an implicit trailing dot for the root. The FQDN for www.example.com is technically www.example.com.—the trailing dot makes the root explicit and prevents the resolver from appending a search domain.
The hierarchy is divided into zones. A zone is a portion of the tree managed by a single administrative authority. The example.com zone might contain records for www.example.com, mail.example.com, and blog.example.com. If the owner of example.com delegates blog.example.com to a different server, that subdomain becomes its own zone. Delegation is how the hierarchy is maintained: the parent zone contains a record pointing to the child zone’s authoritative servers.
The root servers are the starting point. They are the only servers that must be found without any cached information, so resolvers ship with a pre-configured list of root server addresses. The root zone contains records for every top-level domain, telling resolvers which servers are authoritative for .com, .org, and so on. When you query a root server for www.example.com, it does not know the answer, but it knows which servers handle .com and returns a referral to them.
The top-level domain servers are the next level. The .com servers know which authoritative servers handle each domain registered under .com. When a resolver queries a .com server for www.example.com, the server does not know the IP address, but it knows which nameservers are authoritative for example.com and returns a referral to them.
The authoritative servers are the final level. These servers hold the actual records for the domain. When a resolver queries the example.com nameserver for www.example.com, the server returns the A record mapping the name to an IP address. This is the only level that actually knows the answer.
b. The resolution process step by step
When your computer needs to resolve a name, it asks a recursive resolver. The resolver is usually provided by your ISP or chosen from a public service like Cloudflare’s 1.1.1.1 or Google’s 8.8.8.8. The resolver performs the lookup on your behalf and returns the final answer. The distinction between a recursive resolver and an authoritative server matters: the resolver does the walking, the authoritative server holds the data.
The process begins with a cache check. If the resolver has the answer cached and the TTL has not expired, it returns the answer immediately. This is the fast path, and it handles the vast majority of lookups. If the answer is not cached, the resolver begins walking the hierarchy.
The first query goes to a root server. The resolver asks for the address of www.example.com. The root server does not know the answer, but it knows which servers are authoritative for .com. It returns a referral: a response pointing the resolver to the .com servers.
The resolver then queries the .com server. The .com server does not know the address of www.example.com either, but it knows which servers are authoritative for example.com. It returns another referral, pointing to the example.com nameservers.
The resolver queries the example.com nameserver. This server is authoritative for the domain. It holds the actual record mapping www.example.com to an IP address. It returns the answer to the resolver, which caches it according to the TTL and passes it back to your browser.
The browser then connects to that IP address. The entire resolution process—root, TLD, authoritative—happens in the background, usually in tens of milliseconds. Your browser never sees the intermediate steps. It only sees the final IP address and the page that loads from it.
There is a subtlety in the process: the resolver may not query each level in sequence for every lookup. Once it has learned the address of the .com servers, it caches that referral and uses it for subsequent lookups of other .com domains. This is why the first lookup for a new TLD is slower than subsequent lookups for other domains under the same TLD.
c. DNS record types and what they store
The data in DNS is stored in resource records. Each record has an owner (the domain name it belongs to), a type, a class (almost always IN for internet), a TTL, and data. The type determines what the data means and how it is used.
A records map a domain name to an IPv4 address. This is the most common record type and the one that makes a website work. When a resolver asks for example.com and gets an A record, it receives the IPv4 address of the server hosting the site.
AAAA records do the same for IPv6 addresses. The name is a play on the fact that IPv6 addresses are four times longer than IPv4 addresses. A domain can have both an A record and an AAAA record, allowing clients to choose IPv4 or IPv6 depending on their network capability.
CNAME records create an alias, pointing one domain name to another. If www.example.com is a CNAME pointing to example.com, then a query for www.example.com resolves to whatever address example.com resolves to. This is useful for subdomains that should follow the apex domain when it changes. CNAMEs cannot be used at the apex of a zone because the apex must also have NS and SOA records, and a CNAME cannot coexist with other record types.
MX records specify the mail servers for a domain. When someone sends email to user@example.com, the sending mail server looks up the MX record for example.com to know where to deliver the message. MX records have a priority value; lower numbers are preferred, and multiple records provide failover.
NS records specify the authoritative nameservers for a zone. They appear in both the parent zone and the child zone, creating the delegation link. The parent zone’s NS records tell resolvers which servers to query; the child zone’s NS records confirm that those servers are authoritative.
TXT records hold arbitrary text and are used for verification, security policies, and other metadata. SPF records (now deprecated in favor of TXT) specify which servers are allowed to send email for a domain. DKIM and DMARC records use TXT to provide email authentication. Domain ownership verification for services like Google Search Console also uses TXT records.
SOA records mark the start of a zone and contain administrative information: the primary nameserver, the responsible party’s email address, the zone serial number, and timing values for refresh, retry, expire, and minimum TTL. Every zone must have exactly one SOA record.
PTR records provide reverse DNS: mapping an IP address back to a domain name. They are stored in a special zone called in-addr.arpa for IPv4 and ip6.arpa for IPv6. PTR records are used for email server verification and logging.
Complete Example Session
The following session traces a complete lookup for www.example.com from an empty resolver cache through the full hierarchy, then shows a subsequent cached lookup and the effect of TTL expiration.
// ============================================
// PART 1: THE USER ACTION
// ============================================
// User types "www.example.com" into browser
// Browser needs an IP address to connect
// Browser checks its own cache: empty
// Browser asks the OS resolver: what is www.example.com?
// ============================================
// PART 2: THE RESOLVER CACHE CHECK
// ============================================
// OS resolver forwards to recursive resolver (e.g., 1.1.1.1)
// Resolver checks its cache for www.example.com
// Cache miss — the resolver has never seen this name
// ============================================
// PART 3: QUERY THE ROOT SERVER
// ============================================
// Resolver picks a root server from its pre-configured list
// Resolver → Root: "What is the address of www.example.com?"
// Root does not know the answer
// Root knows the .com TLD servers
// Root returns a referral:
// "I don't know, but ask the .com servers at 192.5.6.30"
// ============================================
// PART 4: QUERY THE .COM SERVER
// ============================================
// Resolver → .com server: "What is www.example.com?"
// .com server does not know the answer
// .com server knows the authoritative nameservers for example.com
// .com returns a referral:
// "I don't know, but ask ns1.example.com at 203.0.113.10"
// ============================================
// PART 5: QUERY THE AUTHORITATIVE SERVER
// ============================================
// Resolver → ns1.example.com: "What is www.example.com?"
// This server is authoritative for example.com
// It holds the record: www.example.com. 3600 IN A 192.0.2.1
// It returns the answer: "192.0.2.1, TTL 3600"
// ============================================
// PART 6: CACHE AND RESPOND
// ============================================
// Resolver caches the answer for 3600 seconds (1 hour)
// Resolver returns 192.0.2.1 to the OS resolver
// OS resolver caches it and returns to the browser
// Browser connects to 192.0.2.1 on port 443
// ============================================
// PART 7: THE CONNECTION
// ============================================
// TCP handshake with 192.0.2.1
// TLS handshake
// HTTP request sent
// HTTP response received
// Website displayed
// ============================================
// PART 8: SUBSEQUENT LOOKUP (WITHIN TTL)
// ============================================
// User visits www.example.com again 10 minutes later
// Browser asks resolver: what is www.example.com?
// Resolver checks cache: found 192.0.2.1, TTL remaining 3000s
// Returns immediately — no network queries
// Page loads faster because resolution was instant
// ============================================
// PART 9: AFTER TTL EXPIRATION
// ============================================
// User visits again 2 hours later
// Resolver checks cache: expired (TTL was 3600s)
// Resolver walks the hierarchy again
// But the root and .com referrals are still cached
// Resolver only queries the authoritative server
// Gets the answer (possibly a new IP if the domain moved)
// ============================================
// PART 10: THE FULL PICTURE
// ============================================
// Hierarchy: root → .com → example.com
// Resolver does the walking; browser never sees it
// Caching at every level reduces latency
// TTL controls freshness vs. performance
// DNSSEC (if configured) verifies authenticityThe ten parts trace the full resolution: user action, resolver cache miss, root referral, TLD referral, authoritative answer, caching, connection, a cached lookup, a post-expiration lookup, and the full picture. What the session demonstrates is that the hierarchy is walked only when the answer is not cached, and that caching at multiple levels makes the system practical despite its distributed nature.
Quick Reference
DNS Hierarchy
| Level | Example | Role |
|---|---|---|
| Root | . | Knows TLD servers |
| Top-level domain | .com, .org, .uk | Knows authoritative servers for registered domains |
| Second-level domain | example.com | Registered by owner; contains zone data |
| Subdomain | www.example.com | Created by owner; may be delegated |
Common Record Types
| Type | Purpose | Example |
|---|---|---|
| A | Maps name to IPv4 | example.com. 3600 IN A 192.0.2.1 |
| AAAA | Maps name to IPv6 | example.com. 3600 IN AAAA 2001:db8::1 |
| CNAME | Alias to another name | www.example.com. 3600 IN CNAME example.com. |
| MX | Mail server | example.com. 3600 IN MX 10 mail.example.com. |
| NS | Authoritative nameserver | example.com. 3600 IN NS ns1.example.com. |
| TXT | Arbitrary text | example.com. 3600 IN TXT "v=spf1 ..." |
| SOA | Start of zone | example.com. 3600 IN SOA ns1.example.com. admin.example.com. ... |
| PTR | Reverse DNS | 1.2.0.192.in-addr.arpa. 3600 IN PTR example.com. |
Resolution Steps
| Step | Action | Typical Response |
|---|---|---|
| 1 | Check local cache | Answer or cache miss |
| 2 | Query root server | Referral to TLD |
| 3 | Query TLD server | Referral to authoritative |
| 4 | Query authoritative server | Answer |
| 5 | Cache answer for TTL | — |
| 6 | Return to client | IP address |
Key Concepts
| Concept | Meaning |
|---|---|
| Recursive resolver | Client that walks the hierarchy |
| Authoritative server | Server that holds the actual records |
| Referral | Response pointing to another server |
| TTL | Time a record may be cached |
| Zone | Portion of tree managed by one authority |
| Delegation | Parent zone pointing to child zone’s servers |
| DNSSEC | Digital signatures for DNS records |
Best Practices
✅ Do This:
// Use a reliable resolver (ISP or public like 1.1.1.1)
// Set appropriate TTL values (lower for records that change)
// Use CNAME for aliases, A/AAAA for actual addresses
// Keep multiple authoritative nameservers
// Lower TTL before making changes to speed propagation
// Enable DNSSEC where supported❌ Don’t Do This:
// Hardcode IP addresses instead of using DNS
// Assume changes propagate instantly
// Set very high TTLs on records that change often
// Use CNAME for the root domain (apex)
// Run only one authoritative nameserver
// Ignore DNSSEC validationCommon Pitfalls
| Pitfall | Why It Happens | Fix |
|---|---|---|
| Website not loading after server move | Old record still cached | Wait for TTL to expire; lower TTL before change |
| “Server not found” | DNS resolution failed | Check resolver settings, network connectivity |
| Email not delivering | MX record wrong or missing | Verify MX records and priority |
| Subdomain not working | No record or delegation | Add A/CNAME record or NS delegation |
| Changes not propagating | High TTL on old record | Lower TTL before change; wait for old TTL to expire |
| CNAME at apex rejected | CNAME cannot coexist with NS/SOA | Use A/AAAA records at apex |
| DNSSEC validation failure | Signature mismatch or expired | Check DNSSEC configuration on authoritative server |
Real-World Examples
1. Website A record
example.com. 3600 IN A 192.0.2.12. IPv6 address
example.com. 3600 IN AAAA 2001:db8::13. Alias for www
www.example.com. 3600 IN CNAME example.com.4. Mail server with priority
example.com. 3600 IN MX 10 mail1.example.com.
example.com. 3600 IN MX 20 mail2.example.com.5. Nameserver delegation
example.com. 3600 IN NS ns1.example.com.
example.com. 3600 IN NS ns2.example.com.6. TXT verification
example.com. 3600 IN TXT "v=spf1 include:_spf.example.com ~all"7. Reverse DNS
1.2.0.192.in-addr.arpa. 3600 IN PTR example.com.8. Root referral
// Root returns: "Ask .com servers"9. TLD referral
// .com returns: "Ask example.com nameservers"10. Cached lookup
// Resolver returns cached answer within TTLVisual
The DNS Hierarchy
┌──────────────────────────────────────────────┐
│ ROOT (.) │
│ Knows: .com, .org, .uk, .jp servers │
│ │ │
│ ▼ │
│ .COM (TLD) │
│ Knows: example.com nameservers │
│ │ │
│ ▼ │
│ EXAMPLE.COM (authoritative) │
│ Holds: www → 192.0.2.1 │
│ │ │
│ ▼ │
│ WWW.EXAMPLE.COM │
│ Resolves to 192.0.2.1 │
└──────────────────────────────────────────────┘Resolution Flow
┌──────────────────────────────────────────────┐
│ BROWSER │
│ "www.example.com?" │
│ │ │
│ ▼ │
│ RESOLVER │
│ Cache miss │
│ │ │
│ ├──▶ ROOT: "Ask .com" │
│ │ │
│ ├──▶ .COM: "Ask example.com" │
│ │ │
│ ├──▶ EXAMPLE.COM: "192.0.2.1" │
│ │ │
│ ▼ │
│ Cache answer, return to browser │
└──────────────────────────────────────────────┘Record Types
┌──────────────────────────────────────────────┐
│ A → IPv4 address │
│ AAAA → IPv6 address │
│ CNAME → alias to another name │
│ MX → mail server │
│ NS → authoritative nameserver │
│ TXT → arbitrary text │
│ SOA → zone start │
│ PTR → reverse lookup │
└──────────────────────────────────────────────┘Caching and TTL
┌──────────────────────────────────────────────┐
│ First lookup: │
│ Resolver walks hierarchy (slow) │
│ Caches answer for TTL seconds │
│ │ │
│ ▼ │
│ Second lookup (within TTL): │
│ Resolver returns cached answer (fast) │
│ │ │
│ ▼ │
│ After TTL expires: │
│ Resolver walks hierarchy again │
│ (but parent referrals are still cached) │
└──────────────────────────────────────────────┘DNSSEC Verification
┌──────────────────────────────────────────────┐
│ Authoritative server signs record with │
│ private key │
│ │ │
│ ▼ │
│ Resolver receives record + signature │
│ │ │
│ ▼ │
│ Resolver verifies signature with │
│ public key (from DNSKEY record) │
│ │ │
│ ┌────┴────┐ │
│ │ │ │
│ valid invalid │
│ │ │ │
│ ▼ ▼ │
│ Accept Reject (SERVFAIL) │
└──────────────────────────────────────────────┘Summary
| Item | Value |
|---|---|
| DNS purpose | Translate names to IP addresses |
| Architecture | Hierarchical, distributed database |
| Root servers | Starting point for resolution |
| TLD servers | Know authoritative servers for domains |
| Authoritative servers | Hold the actual records |
| Resolver | Walks hierarchy, caches answers |
| TTL | Time a record may be cached |
| A record | Name → IPv4 |
| AAAA record | Name → IPv6 |
| CNAME | Alias |
| MX | Mail server |
| NS | Delegation |
| DNSSEC | Signature-based authenticity |
Key takeaways:
- DNS is a distributed hierarchy, not a central database. No single server holds all the data. Responsibility is delegated from the root down to individual domains, which is what allows the system to scale and survive failures.
- The resolver walks the hierarchy on your behalf. It queries root, then TLD, then authoritative servers, following referrals until it gets the answer. Your browser only sees the final IP address.
- Caching makes DNS practical. The TTL on each record determines how long resolvers may cache it. Most lookups are served from cache, which is why the first visit to a site is slower than subsequent visits.
- Record types serve different purposes. A and AAAA map names to addresses. CNAME creates aliases. MX routes email. NS delegates authority. TXT holds verification and policy data.
- Changes take time to propagate. When a record changes, the old value remains cached until its TTL expires. This is why server moves can appear to work for some users and not others.
- Redundancy keeps DNS available. Multiple root servers, multiple TLD servers, and multiple authoritative servers for each domain provide resilience.
- DNSSEC adds authenticity. Digital signatures allow resolvers to verify that a response came from the legitimate authoritative server and was not modified in transit.
Remember: DNS is the internet’s phonebook, but it is not a single book. It is a hierarchy of servers, each responsible for a portion of the namespace, with resolvers that walk the tree and cache the answers. When you visit a website, your browser asks a resolver, the resolver asks the root, the root points to the TLD, the TLD points to the authoritative server, and the authoritative server returns the address. The whole process is invisible, and it works because responsibility is distributed and answers are cached. The TTL is the mechanism that balances freshness against performance—short TTLs mean changes propagate quickly but lookups are slower; long TTLs mean faster lookups but slower propagation. Understanding this trade-off is the key to understanding why DNS behaves the way it does when something changes.
Stop using slow, ad-bloated tool sites! 🤮
🔎 Search “KandZ Tools” on Google to use many professional utilities for free.
KandZ.me is the ultimate minimalist hub for:
✅ Finance (Mortgage, Interest, Inflation)
✅ Tech (Base64, JSON, Dev Suite, IP)
✅ Health (BMI, BMR, TDEE)
✅ Productivity (Timer, Workspace, QR)
⚡️ Fast & Private
🔒 No data leaves your device
💎 100% Free
🔗 Use it now: https://tools.kandz.me
🔖 Bookmark it—you’ll need it later!