Introduction to DNS: The Unsung Hero of the Internet

You only think about DNS when it breaks. And when it breaks, everything breaks.

That's the thing about foundational infrastructure — it's invisible until it isn't. DNS translates human-readable names into IP addresses, and it does this billions of times per second, silently, reliably, for the entire internet. Until it doesn't.

Before DNS: The HOSTS.TXT Era

In the early days of ARPANET, name resolution was simple: one file, maintained by the Stanford Research Institute Network Information Center, downloaded periodically to every host on the network. HOSTS.TXT. A flat list of hostnames and addresses, manually updated, manually distributed.

By the early 1980s, this was becoming untenable. The network was growing fast. Every new host required a manual update to the central file. Version conflicts proliferated. Name collisions became common. Network traffic just to keep the file current was measurable.

In 1983, Paul Mockapetris at USC's Information Sciences Institute started working on a replacement. RFC 882 and RFC 883 came out in November 1983, describing a distributed, hierarchical naming system. These were superseded in 1987 by RFC 1034 and RFC 1035 — the core DNS specifications still in use today.

Worth re-reading that: the internet's naming system is built on specs written in 1987. Your iPhone uses the same fundamental protocol as a VAX running BSD 4.3.

The Phone Book Analogy (and Why It Falls Short)

Everyone explains DNS as a phone book. You look up a name, you get a number. It's a reasonable starting point.

But it misses several things that matter:

It's distributed. No single entity holds the complete directory. The system is partitioned across thousands of authoritative servers, with a hierarchy that delegates responsibility downward. The root knows about TLDs. TLDs know about second-level domains. Each zone manages its own piece.

It caches aggressively. When your resolver looks up api.github.com, it caches the answer for a configurable duration (the TTL). The next query for the same name returns the cached answer without contacting any authoritative server. A phone book doesn't do this. A phone book also doesn't expire after 300 seconds.

It's eventually consistent. DNS changes don't propagate instantly. When you update an A record, the old value lives on in caches around the world until their TTLs expire. This is the source of more support tickets than I care to count.

It carries operational metadata. Beyond simple name-to-address mappings, DNS carries mail routing (MX), service discovery (SRV), TLS certificate authorization (CAA), arbitrary text data (TXT), and more. It's closer to a distributed key-value store with a hierarchical namespace than a phone book.

The analogy isn't wrong. It's just incomplete.

What Happens When DNS Fails

Two incidents that illustrate how central DNS is to everything:

Dyn, October 2016

On the morning of October 21, 2016, Dyn — a major DNS provider — came under a sustained DDoS attack. The attack used compromised IoT devices (the Mirai botnet) to flood Dyn's infrastructure with DNS query traffic. At peak, the attack was generating roughly 1.2 Tbps.

The result: Twitter, Reddit, GitHub, Spotify, Netflix, PayPal, and dozens of other major services became unreachable for users across the US East Coast and parts of Europe. Not because those services were down — they were fine. Because their DNS provider was unreachable, so their domains couldn't resolve.

The interesting lesson here isn't about DDoS. It's about single points of failure. Many of those affected services used Dyn as their sole DNS provider. A single provider going down took them with it. The fix isn't particularly complex — run your authoritative DNS on multiple independent providers — but it requires understanding how DNS works to know you need to do it.

Cloudflare, July 2020

On July 17, 2020, Cloudflare had an outage that took down roughly 15 minutes of internet. The root cause: a network engineer's misconfiguration during maintenance work in Atlanta. A bad routing change caused traffic to be dropped across a significant portion of Cloudflare's network.

Cloudflare runs 1.1.1.1, one of the largest public DNS resolvers in the world. When it went down, millions of users found their internet effectively broken — not because their ISP was down, but because their configured DNS resolver was unreachable.

Fifteen minutes. But the incident reports, postmortems, and "is the internet down" Twitter threads were spectacular.

The lesson: DNS isn't just authoritative servers. The resolvers matter too. And when a resolver used by millions of clients fails, the impact is massive and immediate.

Why You Should Actually Understand This

Here's the honest case: DNS problems account for a disproportionate share of production incidents, and most of them are avoidable once you understand what's actually happening.

Misconfigured TTLs that make migrations painful. CNAME loops that take down email. SPF records that don't cover all sending IPs. CAA records that block certificate renewal at the worst possible moment. Delegation issues that make a subdomain invisible. Zone transfers exposed to the public internet.

None of these are exotic. All of them show up in real production systems. All of them are immediately obvious to someone who understands DNS and invisible to someone who doesn't.

This course will make DNS visible. Not so you can pass a certification exam, but so you can read a zone file without squinting, debug a resolution failure in under five minutes, and make infrastructure decisions with the right mental model.

That's what Anouar built EuroDNS on. That's what we're going to cover.

Key Takeaways

DNS was designed in 1983-1987 to replace a manually-maintained HOSTS.TXT file. The core specs (RFC 1034, RFC 1035) are still in use.
The phone book analogy is useful but misleading — DNS is distributed, cached, eventually consistent, and carries much more than name-to-address mappings.
DNS failures are infrastructure failures. The Dyn 2016 attack and Cloudflare 2020 outage both illustrate how dependent the internet is on this single layer.
Understanding DNS prevents a specific class of production incidents that are common, painful, and mostly avoidable.

Up Next

Now that you know what DNS is and why it matters, let's look at how it's structured: the hierarchy that makes a global distributed naming system actually work.