Introduction

Imagine this scenario.

Netflix has a lot of fresh content being released. You decide that you want to watch the next season of The Politican. So, you open up your favorite browser, type in netflix.com, and hit enter. Almost instantly, Netflix's profile selection screen pops up.

You probably already know that an HTTP(S) request over a TCP connection is made to Netflix's servers and that Netflix sends back a HTTP(S) response, which is eventually rendered by your browser as the screen you end up seeing. However, a key part is missing here.

In order to make a TCP connection, you need four things:

1) The Source IP
2) The Source Port Number
3) The Destination IP
4) The Destination Port Number

The above four requirements are often referred to as the "TCP 4-Tuple". Now, you already have the source IP and port number, because you are the source! And thanks to IANA, the destination port number is already known based on the protocol used (HTTP: 80/HTTPS: 443).

The only thing missing to make the TCP connection is the destination IP address. DNS is how you obtain it.

Why do we have domain names?

First of all, why do we even have domain names? If we typed the destination IP address, the problem of obtaining the IP address wouldn't exist.

This is correct, but would involve the end-user memorizing the IP addresses of all the sites they wish to visit. You could probably memorize a few IPv4 addresses, but good luck memorizing 5+, or even a single IPv6 address.

Domain names exist so humans don't have to memorize IP addresses. In addition, IP addresses for hosts can change; having a domain name point automatically to the updated address is really handy.

History

Before diving straight into DNS, it is beneficial to know the history of the system and the motivations behind its creation.

The predecessor of DNS was the hosts.txt file for ARPANET (the predecessor of the Internet). This plain-text file was centrally maintained by the Stanford Research Institute and mapped domain names to addresses of computers on ARPANET. Since the number of hosts on ARPANET was under 1,000 at the time, it was a sufficient solution to mapping domain names. However, there were significant drawbacks.

The first drawback is that updates to the file were manually processed by hand. This resulted in long initial delays.

Second, once the original file at Stanford was updated, all hosts on ARPANET also had to have an updated copy of the hosts.txt file. This resulted in propagation times being measured in the span of days. Imagine not having your domain name be accessible for days after you submit an update!

Third, once a domain was claimed, nobody else could have it. If MIT claimed "mail", then George Washington University could not claim "mail". There was no hierarchy, so great domain names couldn't be used by multiple organizations (like "mit.mail" "gwu.mail" which are possible today).

As you can imagine, this simple file "system" wasn't going to cut it for when the future internet comes around with thousands of hosts. A new scalable and automatic system had to be made and put in place.

Defining DNS

Wikipedia defines DNS as, "a hierarchical and decentralized naming system for computers, services, or other resources connected to the Internet or a private network."

I don't know about you, but this definition doesn't really tell me much. Let's reword that a bit.

DNS is a hierarchical naming system that maps strings (called fully-qualified domain names or FQDN) to values called resource records (which can contain a corresponding IP address).

Simply put, you query DNS with a domain name (e.g. www.netflix.com) and DNS will eventually return an IP address back to you. This returned value is the destination IP address needed to complete the TCP 4-Tuple.

Diving Deeper

DNS at its core is a key-value system where the key is a fully-qualified domain name and the value is a resource record. Though DNS has additional components that are vital to the overall health and performance of the system.

We have described a real-life use case for DNS, in addition to briefly going over the need for domains in general, DNS' history and technical definition. Keep reading the "DNS Explained." series to dive deeper into more DNS topics including the RRR model and resolution!