Try memorizing this: 142.250.80.46. Now try memorizing that for every single website you visit. Your bank, your email, Netflix, GitHub, that weird recipe blog you found at 1 AM. Hundreds of IP addresses, all just strings of numbers.
Nobody does that. Instead, you type "google.com" and somehow your browser knows exactly which server on the planet to talk to. That translation, from a human-readable name to a machine-readable address, is DNS. The Domain Name System.
DNS is one of those things that's so fundamental, so deeply baked into how the internet works, that most developers never think about it. Until it breaks. And when DNS goes down, everything goes down. In October 2021, Facebook's DNS records disappeared from the internet for about six hours. Not just Facebook. Instagram, WhatsApp, Messenger, Oculus, all of it. Gone. Three billion users couldn't access any of it because of a DNS misconfiguration.
Here's the kicker: the engineers couldn't even get into the building to fix it because the badge readers relied on Facebook's internal DNS too. They literally had to send someone to the data center to physically fix the routers.
DNS is the invisible backbone of everything you do online. Let's understand how it actually works.
At its core, DNS answers one question: "What IP address does this domain name point to?"
When you type github.com into your browser, your computer doesn't know what to do with that string. Networking protocols need IP addresses, numerical addresses that identify machines on the internet. DNS is the system that looks up github.com and returns something like 140.82.121.4.
Think of it like a contact list on your phone. You don't memorize your friend's phone number, you tap their name and your phone translates it to the actual number. DNS does the same thing, but for the entire internet.
A few things worth knowing upfront:
DNS is hierarchical. It's not one giant database. It's a distributed system with multiple layers, each responsible for a piece of the puzzle. This is what makes it resilient, no single point of failure (well, mostly).
Once your computer learns that is , it remembers that for a while. So does your router. So does your ISP. This makes subsequent lookups nearly instant but also means changes take time to propagate.
github.com140.82.121.4DNS doesn't just store IP addresses. It can store mail server info (MX records), text verification strings (TXT records), aliases (CNAME records), and more. It's a surprisingly flexible key-value store for domain metadata.
| Record Type | What It Does | Example |
|---|---|---|
| A | Maps domain to IPv4 address | github.com -> 140.82.121.4 |
| AAAA | Maps domain to IPv6 address | github.com -> 2606:50c0:8000::154 |
| CNAME | Alias one domain to another | www.github.com -> github.com |
| MX | Mail server for the domain | gmail.com -> alt1.gmail-smtp-in.l.google.com |
| TXT | Arbitrary text (verification, SPF) | github.com -> "v=spf1 ..." |
| NS | Which name servers are authoritative | github.com -> dns1.p08.nsone.net |
The table above lists the major DNS record types, but seeing them side by side makes the differences click faster. Each record type answers a different question about a domain.
One domain can have dozens of records. GitHub, for example, has A records for the web servers, MX records for email routing, TXT records for SPF and domain verification, CNAME records for subdomains like docs.github.com, and NS records pointing to their authoritative name servers. When you run dig github.com ANY, you see the full picture.
When you type a URL and hit enter, your browser kicks off a chain of lookups. It's not a single hop, it's a multi-step treasure hunt across multiple servers. Walk through it step by step.
If every single DNS lookup had to go through all four steps, recursive resolver, root, TLD, authoritative, the internet would be painfully slow. Every page load would add 200-400ms just for DNS.
That's why exists at almost every layer.
Browser cache. Chrome, Firefox, Safari, they all maintain their own DNS cache. If you visited github.com five minutes ago, your browser already knows the IP. Zero network calls needed.
Operating system cache. Even if the browser doesn't have it, your OS maintains a DNS cache. On macOS you can inspect it with sudo dscacheutil -flushcache. On Windows it's ipconfig /displaydns.
Router cache. Your home router typically caches DNS responses too. Every device on your network benefits from this shared cache.
ISP resolver cache. Your ISP's recursive resolver handles millions of queries. If someone else on your ISP already looked up github.com recently, the resolver has it cached. You get the answer without it ever leaving your ISP's network.
Every DNS record comes with a (Time to Live), a number in seconds that says "cache this for this long." Common TTLs:
| TTL | When to Use |
|---|---|
| 300 (5 min) | Records that change frequently, during migrations |
| 3600 (1 hour) | Standard for most websites |
| 86400 (24 hours) | Stable records that rarely change |
Here's the gotcha: when you update a DNS record, you have to wait for every cache in the chain to expire before the change is fully visible worldwide. This is DNS propagation, and it's why "just change the DNS" is never actually instant. It can take anywhere from minutes to 48 hours depending on the TTL settings.
DNS is clean, but it has some sharp edges you need to know about.
Propagation delays. You change your A record to point to a new server. Some users hit the new one immediately. Others keep hitting the old one for hours because their ISP cached the old record with a long . During a migration, you can have users split across old and new servers. The fix: lower your TTL to 300 seconds before the migration, wait 24 hours for old caches to flush, make the change, then raise the TTL back up.
DNS as a single point of failure. If your authoritative DNS goes down, nobody can resolve your domain. New visitors can't reach you at all. Existing visitors work until their cache expires. This is why you always want at least two geographically separated name servers. Services like Cloudflare DNS, AWS Route 53, and Google Cloud DNS are built for this.
DNS spoofing and poisoning. An attacker injects a false DNS record into a resolver's cache, redirecting yourbank.com to their malicious server. DNSSEC was designed to prevent this by adding cryptographic signatures to DNS records, but adoption is still inconsistent across the internet.
DNS adds to every first request. The very first time you visit a domain, DNS resolution typically adds 20-120ms before anything else happens. For performance-critical applications, developers use dns-prefetch hints in HTML to resolve domains before the user clicks a link.
When to use DNS strategically:
When DNS is the wrong tool:
In October 2016, a massive DDoS attack hit Dyn, a major DNS provider. The attack flooded Dyn's servers with traffic from a botnet of compromised IoT devices, cameras, DVRs, routers, all running the Mirai malware. At its peak, the attack generated 1.2 Tbps of traffic.
The result: Twitter, Reddit, Netflix, Spotify, GitHub, and dozens of other major sites became unreachable for hours. Not because their servers were down, their DNS provider was down, so nobody could resolve their domain names. The sites were running fine; the internet just couldn't find them.
After this, many companies moved to multi-provider DNS setups. If one DNS provider goes down, the other still works.
For years, most people used their ISP's default DNS resolver, slow, unreliable, and often logging every domain you visited. In 2018, Cloudflare launched 1.1.1.1 as a free, privacy-focused DNS resolver. It's consistently one of the fastest resolvers in the world, averaging under 15ms response time globally.
Google's 8.8.8.8 is the other popular public resolver. Both are dramatically faster than most ISP resolvers, which is why developers often recommend switching to them.
When you request content from a like Cloudflare or AWS CloudFront, DNS is doing something clever behind the scenes. The authoritative DNS server doesn't return a fixed IP, it looks at where the query is coming from and returns the IP of the nearest edge server. A user in Tokyo gets pointed to a server in Tokyo. A user in London gets pointed to one in London. Same domain, different IPs. This is GeoDNS, and it's how CDNs deliver content with low latency worldwide.
4 questions - Score 80% to pass
Your browser needs to visit github.com for the first time. What does DNS do?
You update a DNS A record, but some users still see the old site hours later. What's the most likely cause?
In the 2016 Dyn DDoS attack, major sites like Twitter and Netflix went down. Why?
A CDN returns different IP addresses for the same domain depending on where the user is located. What DNS technique enables this?