What Is DNS? Explained Simply (2026)

Every time you open a website, DNS runs before anything else. Understanding it will help you debug half the networking issues you'll ever face.

The Simple Explanation

When you type google.com in your browser, your computer needs to find out which IP address that corresponds to. Computers talk to each other using IP addresses (like 142.250.80.46), not human-friendly names.

DNS (Domain Name System) is the system that converts google.com → 142.250.80.46.

It's like a phonebook — you look up a name, get a number.

How a DNS Lookup Actually Works

When you type devopsboys.com:

1. Your browser checks its cache — has it seen this recently? If yes, use cached IP.

2. Your OS checks its cache — same thing, slightly larger cache.

3. Your OS checks /etc/hosts (Linux/Mac) or C:\Windows\System32\drivers\etc\hosts (Windows) — static overrides.

4. Your resolver (DNS server) gets asked — usually your ISP's server, or 8.8.8.8 (Google), or 1.1.1.1 (Cloudflare). This is your recursive resolver.

5. Recursive resolver asks the Root servers — there are 13 root server groups worldwide. They know where to find .com nameservers.

6. Root server responds: "ask the .com TLD nameservers"

7. Recursive resolver asks the .com TLD nameservers — they know where devopsboys.com's nameservers are.

8. TLD nameserver responds: "ask ns1.vercel-dns.com" (the authoritative nameserver for devopsboys.com)

9. Recursive resolver asks the authoritative nameserver — this server has the actual records.

10. Authoritative nameserver responds with the IP address

11. Recursive resolver caches the result and returns it to your browser

12. Your browser connects to the IP

This entire process takes 20–200ms for uncached lookups, and milliseconds for cached ones.

DNS Record Types

A Record — maps a hostname to an IPv4 address

devopsboys.com  →  76.76.21.21

AAAA Record — maps a hostname to an IPv6 address

devopsboys.com  →  2606:4700::6810:1505

CNAME Record — maps a hostname to another hostname (alias)

www.devopsboys.com  →  devopsboys.com

Important: CNAMEs can't be used at the apex domain (devopsboys.com itself) — only subdomains.

MX Record — mail server for a domain

devopsboys.com  →  mail.google.com (priority 10)

TXT Record — arbitrary text, used for domain verification and SPF/DKIM email records

devopsboys.com  →  "v=spf1 include:_spf.google.com ~all"

NS Record — nameservers responsible for the domain

devopsboys.com  →  ns1.vercel-dns.com, ns2.vercel-dns.com

SOA Record — Start of Authority — metadata about the zone

TTL — Time to Live

Every DNS record has a TTL (in seconds). This tells resolvers how long to cache the answer.

devopsboys.com  300  IN  A  76.76.21.21

TTL = 300 means: cache this for 300 seconds (5 minutes).

Why TTL matters:

• Low TTL (60s): fast propagation when you change a record, but more DNS queries
• High TTL (86400s = 24h): fewer queries, but DNS changes take up to 24 hours to propagate worldwide

Before a major DNS change (domain migration, IP change), lower TTL to 60s first, wait for old TTL to expire, then make the change.

DNS in Kubernetes (CoreDNS)

Inside a Kubernetes cluster, DNS works differently. CoreDNS runs as a pod in kube-system and handles all in-cluster DNS.

Service discovery pattern:

# A service named "my-service" in namespace "my-namespace"
# is reachable at:
my-service.my-namespace.svc.cluster.local
 
# Short form (within same namespace):
my-service
 
# From a different namespace:
my-service.my-namespace

# Test DNS inside a pod
kubectl run dns-test --image=busybox --restart=Never -- \
  nslookup my-service.my-namespace.svc.cluster.local
 
# Check CoreDNS is running
kubectl get pods -n kube-system -l k8s-app=kube-dns
 
# Check CoreDNS config
kubectl get configmap -n kube-system coredns -o yaml

Useful DNS Commands

# Look up A record
nslookup devopsboys.com
dig devopsboys.com
 
# Check what DNS server you're using
nslookup devopsboys.com 8.8.8.8   # force query to Google DNS
dig @1.1.1.1 devopsboys.com        # force query to Cloudflare
 
# Check specific record types
dig devopsboys.com MX              # mail records
dig devopsboys.com TXT             # text records
dig devopsboys.com NS              # nameservers
 
# Trace full resolution path
dig +trace devopsboys.com
 
# Reverse DNS (IP to hostname)
dig -x 76.76.21.21
 
# Check TTL on a record
dig devopsboys.com | grep -i ttl

Common DNS Problems DevOps Engineers Face

"Site not loading after DNS change" → TTL hasn't expired. Wait for old TTL. Check propagation at dnschecker.org.

"Works on my machine, not in prod" → Different DNS servers. Your ISP may have stale cache. Use dig @8.8.8.8 to bypass local cache.

"Pod can't reach external service" → CoreDNS issue or egress DNS blocked. Run nslookup from inside the pod.

"DNS works for some pods, not others" → CoreDNS resource limits — it might be OOMKilling under high query load.

"Intermittent DNS failures" → ndots setting in Kubernetes. Kubernetes appends cluster suffixes before trying external domains, causing extra failed lookups.

DNS in One Sentence

DNS converts human-friendly hostnames into IP addresses through a hierarchical distributed system — and understanding it helps you debug half the networking problems you'll ever encounter.

If you can read dig output and understand TTL, you know enough DNS for most DevOps work.