The first time I deployed a website with a custom domain, I changed the DNS records, waited ten minutes, refreshed the page, and got nothing. I refreshed again. Still nothing. I started questioning every decision I had made. After 45 minutes of mild panic, a colleague told me: "DNS can take up to 48 hours to propagate. Go get lunch."
That was my introduction to DNS — not as an academic concept, but as a real constraint that would affect every project I deployed. Understanding DNS properly is one of those things that pays dividends every time you deploy an application, debug a network issue, or configure a new domain. It's also one of those concepts that sounds intimidating but makes complete sense once the model clicks.
What Is DNS and Why Does It Exist?
DNS stands for Domain Name System. Its job is to translate human-readable domain names (like techclario.com) into IP addresses (like 104.21.33.89) that computers use to find each other on the internet.
Computers communicate using IP addresses — numerical labels that identify every device and server connected to the internet. But humans are not good at remembering numbers. We remember names. DNS is the bridge between the names we remember and the numbers computers need.
Think of DNS as the internet's phone book. When you look up someone's name in a phone book, you get their number. When your browser looks up a domain name in DNS, it gets an IP address. The analogy isn't perfect — DNS is distributed, hierarchical, and automatically updated — but it captures the essential purpose.
How a DNS Lookup Actually Works
When you type techclario.com into your browser and press Enter, a lookup process begins that involves multiple servers in sequence. Understanding this sequence is what makes DNS behavior predictable.
Step 1: Local cache check. Your computer first checks its own DNS cache — a stored list of recent lookups. If you visited the same site recently, the answer is already stored locally. This is why DNS changes don't always take effect immediately even after propagation — your computer might be serving you a cached answer.
Step 2: Recursive resolver. If the answer isn't in your local cache, your computer contacts a DNS resolver — typically operated by your ISP or a public service like Google (8.8.8.8) or Cloudflare (1.1.1.1). The resolver is responsible for finding the answer on your behalf.
Step 3: Root name servers. If the resolver doesn't have a cached answer either, it contacts one of the 13 root name server clusters that know the authoritative servers for each top-level domain (.com, .org, .io, etc.).
Step 4: TLD name servers. The root server directs the resolver to the .com TLD server, which knows the authoritative name server for techclario.com.
Step 5: Authoritative name server. The authoritative server (configured by whoever registered the domain) holds the actual DNS records. It returns the IP address associated with techclario.com.
Step 6: Response returned. The resolver sends the IP address back to your browser, which then opens a connection to that server. The whole process typically completes in under 100ms — usually much faster.
DNS Record Types You Actually Need to Know
DNS doesn't just store IP addresses. It stores several types of records, each serving a different purpose.
A record maps a domain name to an IPv4 address. This is the fundamental record type — techclario.com → 104.21.33.89. When you're pointing a domain to your web server, you're setting an A record.
AAAA record is the same as an A record but for IPv6 addresses, which are longer (e.g., 2606:4700::6815:2159). As the internet transitions to IPv6, AAAA records become more important.
CNAME record (Canonical Name) maps a domain name to another domain name rather than an IP address. Used to point www.techclario.com to techclario.com, or to point a subdomain to a service provider's domain. When I set up Vercel for a project, they gave me a CNAME to point my domain to — my DNS then forwarded lookups to Vercel's infrastructure.
MX record (Mail Exchanger) tells email servers where to deliver email for a domain. Setting up Google Workspace or any email service for your domain means adding MX records.
TXT record stores arbitrary text data. Used for domain ownership verification (proving you own a domain to services like Google Search Console), SPF records (telling email servers which servers are allowed to send email from your domain), and DKIM keys (email authentication).
NS record (Name Server) specifies which DNS servers are authoritative for a domain. When you register a domain, you set NS records to point to your DNS provider — Cloudflare, Route 53, Namecheap, etc.
TTL: Why DNS Changes Take Time
Every DNS record has a TTL (Time To Live) — a number in seconds that tells caches how long to keep the record before checking for updates. A TTL of 3600 means "cache this for one hour." A TTL of 86400 means "cache this for one day."
This is why DNS propagation can take time. When you change an A record, every cache in the world that holds the old value will keep serving it until its TTL expires. A record with a 48-hour TTL can take up to 48 hours to fully propagate — not because the update is slow, but because old cached answers are still being served.
The practical lesson: before migrating a domain to a new server, lower the TTL to something like 300 (five minutes) a day or two before the migration. Then, when you make the change, it propagates quickly. After the migration is stable, raise the TTL back to normal. I learned this technique the hard way during a deployment that had more downtime than necessary because of a 24-hour TTL I hadn't thought to lower.
What Happens When DNS Breaks
DNS failures are surprisingly common and consistently confusing to debug. The symptoms are: your browser says "Server not found" or "This site can't be reached" — but other sites load fine, so it's not your internet connection.
Common causes: an A record pointing to an old IP address after migrating servers; a missing CNAME record for a subdomain; an expired domain registration (the nameserver records get cleared); a misconfigured NS record after changing DNS providers.
The diagnostic tool for DNS problems is nslookup (Windows) or dig (Mac/Linux). Running dig techclario.com shows you exactly what DNS is returning for a domain right now, from your location. Running dig @8.8.8.8 techclario.com checks Google's resolver specifically, letting you compare what different resolvers see.
When a colleague asks "why isn't my domain working?" — dig is almost always the first command you run.
DNS and Performance
DNS resolution adds latency to every new connection. If your DNS resolver is slow, your users notice. This is why using a fast public resolver (Cloudflare's 1.1.1.1 is consistently fastest in benchmarks) or configuring your own resolvers at the network level matters in performance-sensitive environments.
Content Delivery Networks (CDNs) use DNS-based load balancing to route users to the nearest server. When you look up techclario.com from Paris, you might get a different IP than someone looking it up from Singapore — each getting routed to the geographically closest CDN node.
Understanding DNS isn't just useful for debugging. It's foundational to understanding how the internet itself is organized and how performance is distributed globally.