What is DNS — Simple Explanation with Examples

DNS (Domain Name System) translates human-readable domain names into IP addresses, enabling browsers to load internet resources without memorizing numeric addresses.

In this guide, you’ll understand how DNS works behind the scenes, how to troubleshoot DNS issues, and how to configure DNS records for your own domains. This knowledge is essential for web developers, system administrators, and anyone who manages websites.

Why DNS Exists — The Problem It Solves

Computers communicate using IP addresses — numbers like 142.250.190.46. Humans are terrible at remembering numbers. We remember names like “google.com.”

DNS bridges this gap. When you type a domain name into a browser, DNS finds the corresponding IP address so your computer can connect to the right server. Without DNS, you’d need to memorize an IP address for every website you visit.

The Scaling Problem

In the early days of the internet (1980s), a single file called HOSTS.TXT mapped all domain names to IP addresses. As the internet grew, this became impossible to maintain. DNS was created in 1983 as a distributed, hierarchical system that could scale to millions of domains.

The Analogy — Phone Book

DNS is like a phone book for the internet. You look up a person’s name (domain) to find their phone number (IP address).

But it’s more like a distributed phone book system:

1. You first check your personal contacts (local cache).
2. If not there, you ask a directory assistance operator (your ISP’s resolver).
3. They check their regional directory (root/TLD servers).
4. Eventually, they find the specific listing (authoritative nameserver).

DNS Hierarchy

DNS is organized as a tree-like hierarchy:

Root (.)
  ├── .com (TLD)
  │   ├── example.com (authoritative)
  │   └── google.com (authoritative)
  ├── .org (TLD)
  │   └── wikipedia.org (authoritative)
  └── .io (TLD)
      └── github.io (authoritative)

Root Servers

13 logical root server clusters (hundreds of physical machines) that know where all TLD nameservers are. They don’t answer domain lookups directly — they redirect to the right TLD server.

TLD Servers

Top-Level Domain servers handle .com, .org, .net, .io, country codes like .uk, .jp, and new TLDs like .dev, .app.

Authoritative Nameservers

The final authority for a domain. They hold the actual DNS records (A, CNAME, MX, etc.) and return the IP address for the requested domain.

How DNS Resolution Works (Step by Step)

When you type example.com in your browser:

Browser
  │ 1. Checks local DNS cache
  │ 2. Asks recursive resolver (ISP or 8.8.8.8)
  ▼
Recursive Resolver
  │ 3. Asks root server: "Who handles .com?"
  ◄── Root: "Ask the .com TLD server at 192.0.34.162"
  │ 4. Asks .com TLD: "Who handles example.com?"
  ◄── .com TLD: "Ask ns1.example.com"
  │ 5. Asks ns1.example.com: "What is the IP of example.com?"
  ◄── ns1.example.com: "93.184.216.34"
  │ 6. Returns IP to browser
  ▼
Browser connects to 93.184.216.34:80

Total time: typically 10–100ms for a cold lookup. Subsequent lookups are faster due to caching.

DNS Record Types

Using dig and nslookup

# Basic A record lookup
dig example.com

# Short output
dig example.com +short
# Output: 93.184.216.34

# Lookup specific record type
dig example.com MX +short
# Output: 0 .  (no MX records)

# Trace the full resolution path
dig example.com +trace

# Using nslookup (simpler)
nslookup google.com
# Output:
# Server:   192.168.1.1
# Address:  192.168.1.1#53
# Non-authoritative answer:
# Name:     google.com
# Address:  142.250.190.46

TTL and DNS Propagation

TTL (Time To Live) tells DNS resolvers how long to cache a record before checking for updates.

# Check TTL of a record
dig example.com | grep "IN A"
# Output: example.com. 86400 IN A 93.184.216.34
# TTL is 86400 seconds = 24 hours

When you change a DNS record, propagation time depends on the TTL:

• Short TTL (300s): Changes propagate in 5 minutes. Good for dynamic setups.
• Long TTL (86400s): Changes take 24 hours. Good for stable records.

Pro tip: Lower the TTL before making changes, then raise it after propagation.

Security — DNSSEC

DNSSEC (DNS Security Extensions) adds cryptographic signatures to DNS records so resolvers can verify they haven’t been tampered with.

# Check if a domain has DNSSEC
dig example.com +dnssec

# Look for the "ad" flag (authenticated data)
dig com SOA +multi

Without DNSSEC, attackers can perform DNS spoofing or cache poisoning — redirecting users to fake websites even when they type the correct domain.

Common Use Cases

1. Website hosting

Point example.com to your web server’s IP with an A record. Create a CNAME for www to redirect to the root domain.

2. Email delivery

MX records tell the internet where to deliver email for your domain. SPF and DKIM (TXT records) prevent spoofing.

3. Load balancing with DNS round-robin

Multiple A records for the same domain distribute traffic across servers:

example.com → 203.0.113.1
example.com → 203.0.113.2
example.com → 203.0.113.3

4. CDN routing

CDNs use DNS to direct users to the nearest edge server. A single domain may resolve to different IPs depending on the user’s location.

5. Internal network services

Private DNS zones map internal hostnames (db.internal.company.com) to private IPs that aren’t accessible from the internet.

FAQ

Related Terms

HTTPS, CDN, Load Balancing, TLS/SSL, Caching