Muhammad Hamid Raza

Posted on May 5

Why DNS Was Introduced and How It Replaced Raw IP Addresses

#webdev #beginners #networking #devops

Have you ever wondered what actually happens when you type google.com into your browser and press Enter? 🤔

Behind the scenes, a quiet but brilliant system kicks into action — one that most people use thousands of times a day without ever thinking about it. That system is DNS, the Domain Name System.

Before DNS existed, accessing a website meant memorizing long strings of numbers. We're talking things like 192.168.1.1 but for every single website on the internet. Sounds exhausting, right?

This post explains why DNS was introduced, how it replaced raw IP addresses, and why understanding it makes you a sharper developer, a better debugger, and honestly just a more informed person on the internet.

What Is an IP Address?

Before we can appreciate DNS, we need to understand what it replaced.

Every device connected to the internet — your laptop, your phone, the server hosting your favorite website — has an IP address. Think of it like a home address. If you want to send a letter, you need to know where the house is. If your browser wants to load a website, it needs to know the server's address.

An IPv4 address looks like this: 142.250.190.78
An IPv6 address looks like this: 2607:f8b0:4004:c09::64

These numbers are how machines identify and talk to each other. Accurate? Yes. Human-friendly? Absolutely not.

What Is DNS?

DNS stands for Domain Name System.

It is essentially the internet's phonebook. Instead of memorizing a number, you remember a name — like google.com or github.com — and DNS quietly translates that name into the correct IP address behind the scenes.

Here is a simple analogy. Imagine you want to call your friend Ayesha. You don't memorize her phone number. You just search "Ayesha" in your contacts and your phone finds the number for you. DNS does exactly that — but for websites.

You type a human-friendly name → DNS finds the IP address → your browser connects to the right server.

Simple. Elegant. And completely invisible when it works correctly.

Why Was DNS Introduced? The Real Story

DNS did not appear out of nowhere. It was born out of a very real and growing problem.

The Early Internet and the HOSTS.TXT File

In the early days of the internet (the ARPANET era, late 1960s to early 1980s), the network was tiny. There were only a few hundred computers connected to it — mostly at universities and research labs.

Back then, every computer had a file called HOSTS.TXT. This plain text file listed every hostname and its matching IP address on the entire network.

It looked something like this:

192.0.0.1    stanford
192.0.0.2    mit
192.0.0.3    ucla

When you wanted to connect to another machine, your computer looked up the name in this file and got the IP. Simple enough — when the internet was small.

There was one central copy of HOSTS.TXT maintained by Stanford Research Institute. Every network connected to ARPANET would download this file periodically to stay updated.

The Problem That Made HOSTS.TXT Impossible to Scale

As the internet grew through the late 1970s and early 1980s, this system started to break down fast. Here is why:

The file grew too large. With hundreds and then thousands of machines, HOSTS.TXT became huge and slow to process.
Updates were too slow. It took days for changes to spread across the network. New hostnames would not appear immediately everywhere.
Name conflicts were a nightmare. Two organizations might register the same hostname because there was no central authority to prevent it.
Bandwidth was being wasted. Every machine had to download the full file constantly to stay current.
Human memory still had limits. Even with the file doing the lookup, administrators had to manage it manually.

The internet was growing, and HOSTS.TXT simply could not keep up.

Enter Paul Mockapetris

In 1983, computer scientist Paul Mockapetris designed and published the DNS specification in RFC 882 and RFC 883. His solution was both smart and scalable.

Instead of one giant file maintained in one place, DNS would be a distributed, hierarchical database spread across thousands of servers around the world. No single server would know everything. But together, they would be able to answer any hostname query on the planet.

This was the turning point. DNS replaced HOSTS.TXT, and it has been running the internet ever since.

Why This Matters for Developers

You might be thinking, "Okay, interesting history — but why should I care as a developer?"

Fair question. Here is why DNS knowledge is actually useful day-to-day:

1. Debugging Network Issues

When your app cannot connect to an external API or your domain is not loading, DNS is often the first thing to check. Understanding how DNS works helps you debug faster instead of staring blankly at a timeout error.

2. Deploying Apps and Configuring Domains

When you deploy a Next.js app to Vercel or a server on DigitalOcean, you always have to update DNS records — A records, CNAME records, TXT records. Knowing what these mean saves you hours of confusion.

3. Setting Up Email

Configuring a custom email domain requires DNS records like MX and SPF. Without understanding DNS basics, this feels like dark magic.

4. Performance and Caching

DNS responses are cached for a period defined by TTL (Time to Live). If you update a DNS record and it does not take effect immediately, that is TTL doing its job. Knowing this prevents unnecessary panic.

5. Security

DNS-based attacks like DNS spoofing and DNS hijacking are real threats. Developers and sysadmins who understand DNS are better equipped to protect their infrastructure.

How DNS Actually Works: A Step-by-Step Breakdown

Let's trace what happens when you type hamidrazadev.com into your browser.

Step 1 — Check the local cache
Your browser first checks if it has recently resolved this domain. If yes, it uses the cached IP and skips the rest.

Step 2 — Ask the Recursive Resolver
If not cached, your device contacts a recursive resolver — usually provided by your ISP or a public DNS service like 8.8.8.8 (Google) or 1.1.1.1 (Cloudflare).

Step 3 — Ask the Root Name Server
The resolver asks a Root Name Server where to find information about .com domains. There are 13 root server clusters around the world (operated by organizations like ICANN, NASA, and Verisign).

Step 4 — Ask the TLD Name Server
The root server points the resolver to the TLD (Top-Level Domain) Name Server responsible for .com.

Step 5 — Ask the Authoritative Name Server
The TLD server points to the Authoritative Name Server for hamidrazadev.com specifically — this is the server that actually knows the IP address.

Step 6 — Get the IP address
The authoritative server returns the IP address. The resolver caches it and sends it to your browser.

Step 7 — Your browser connects
Your browser now has the IP address and makes a request to the server. The website loads. 🚀

This entire process typically completes in milliseconds.

DNS vs. Raw IP Addresses: A Quick Comparison

Feature	Raw IP Address	DNS
Human-readable	❌ No	✅ Yes
Easy to remember	❌ Very hard	✅ Simple names
Scales with internet growth	❌ No	✅ Distributed system
Supports changes	❌ Hard to update	✅ Update DNS records anytime
Required for email/SSL setup	❌ Insufficient	✅ Essential

Using raw IPs still works in certain scenarios — like internal networks or hardcoded server calls. But for public-facing services, DNS is non-negotiable.

Common DNS Record Types You Should Know

Here is a quick reference for the records developers deal with most often:

A Record — Maps a domain to an IPv4 address. This is the most common record.
AAAA Record — Maps a domain to an IPv6 address.
CNAME Record — Points one domain to another domain (alias). Used a lot in Vercel and Netlify deployments.
MX Record — Specifies the mail server for a domain. Needed for email.
TXT Record — Stores arbitrary text. Used for domain verification and SPF/DKIM email authentication.
NS Record — Identifies which name servers are authoritative for a domain.

Best Tips for Working with DNS

✅ Do's

Lower your TTL before making changes. Before you update a DNS record, lower the TTL to something like 300 seconds (5 minutes). This makes changes propagate faster. Once stable, you can raise it back.
Use a reliable DNS provider. Cloudflare DNS (1.1.1.1) and Google DNS (8.8.8.8) are fast and trustworthy for resolvers.
Use nslookup or dig to debug. These command-line tools let you query DNS directly and are invaluable for troubleshooting.
Document your DNS records. Keep a simple spreadsheet or note of what each record does. Future-you will thank present-you.

❌ Don'ts

Don't expect instant propagation. DNS changes take time to spread globally — sometimes minutes, sometimes up to 48 hours depending on TTL values.
Don't delete records without checking dependencies. Removing an MX record will break your email. Removing a CNAME might break your subdomain.
Don't rely on IP addresses directly in production configs. If the server IP changes (which happens), you will have to update every hardcoded reference. Use domain names instead.

Common Mistakes People Make with DNS

Mistake 1: Panicking when changes don't apply immediately

DNS propagation is not instant. When you update a record and it doesn't work right away, that's normal. Wait for the TTL to expire. Use tools like whatsmydns.net to track propagation globally.

Mistake 2: Forgetting to renew a domain

Your domain is registered, not owned forever. When it expires, your DNS stops working and someone else can register it. Set auto-renewal and use a real email for domain alerts.

Mistake 3: Confusing CNAME and A records

A CNAME points to another domain name. An A record points to an IP address. Using a CNAME where an A record is needed (or vice versa) is a classic setup mistake that causes hours of confusion.

Mistake 4: Setting TTL too high during migration

If you are moving a website to a new server and your TTL is set to 86400 (24 hours), visitors may keep hitting the old server for an entire day. Always lower TTL in advance before migrations.

Mistake 5: Not testing locally before going live

Use dig or nslookup to confirm your DNS is pointing where you think it is before announcing a new deployment to the world.

Conclusion

DNS is one of those technologies that works so silently and reliably that most people forget it exists — until it breaks. 😄

What started as a simple text file on a handful of computers in the early internet became a distributed, global system that handles billions of queries every single day. It replaced raw IP addresses not by eliminating them, but by making them invisible to humans — and that invisibility is the point.

For developers, understanding DNS is not just academic knowledge. It is a practical skill that shows up in deployments, debugging sessions, email setups, domain migrations, and security decisions. The more comfortable you are with it, the less mysterious the internet becomes.

The big takeaway: IP addresses are how machines talk. DNS is how humans stay sane while that's happening.

If you found this post helpful, feel free to share it with a fellow developer or student who is just starting to explore how the internet works. 😊

For more developer content, tutorials, and deep dives like this one, visit hamidrazadev.com — new posts go up regularly and cover topics from frontend development to networking concepts like this one.

Drop a comment if you have questions, or share this post if it cleared something up for you. Happy coding! 🚀

DEV Community