It may seem like something automatic that we take for granted, but there is a whole process that happens behind the scenes that makes it run.

So...The Internet. What is it?

The Internet is actually a wire. Well, many wires that connect computers all around the world.

The Internet is also infrastructure. It's a global network of interconnected computers that communicate through a standardised way with set protocols.

Really, it's a network of networks. It's a fully distributed system of computing devices and it ensures end to end connectivity through every part of the network. The aim is for every device to be able to communicate with any other device.

_Visualisation of a possible routing path on the Internet. Image from Wikimedia Foundation._

The Internet is something we all use everyday, and many of us can't imagine our lives without it. The internet and all the technological advances it offers has changed our society. It has changed our jobs, the way we consume news and share information, and the way we communicate with one another.

It has also created so many opportunities and has helped helped humanity progress and has shaped our human experience.

There is nothing else like it – it's one of the greatest inventions of all time. But do we ever stop to think why it was created in the first place, how it all happened, or by whom it was created? How the internet has become what it is today?

This article is more of a journey back in time. We'll learn about the origins of the Internet and how far it has come throughout the years, as this can be beneficial in our coding journeys.

Learning about the history of how the Internet was created has made me realise that everything comes down to problem solving. And that is what coding is all about. Having a problem, trying to find a solution to it, and improving upon it once that solution is found.

The Internet, a technology so expansive and ever-changing, wasn't the work of just one person or institution. Many people contributed to its growth by developing new features.

So it has developed over time. It was at least 40 years in the making and kept (well, still keeps) on evolving.

And it wasn't created just for the sake of creating something. The Internet we know and use today was a result of an experiment, ARPANET, the precursor network to the internet.

And it all started because of a problem.

Scared of Sputnik

It was in the midst of the Cold War, October 4 1957, that the Soviets launched the first man made satellite into space called Sputnik.

As it was the world's first ever artificial object to float into space, this was alarming for Americans.

The Soviets were not only ahead in science and technology but they were a threat. Americans feared that the Soviets would spy on their enemies, win the Cold War, and that nuclear attacks on American soil were possible.

_Image from Wikimedia Foundation_

So Americans started to think more seriously about science and technology. After the Sputnik wake up call, the space race began. It was not long after that in 1958 the US Administration funded various agencies, one of them being ARPA.

ARPA stands for Advanced Research Project Agency. It was a Defence Department research project in Computer Science, a way for scientists and researchers to share information, findings, knowledge, and communicate. It also allowed and helped the field of Computer Science to develop and evolve.

It was there that the vision of J.C.R. Licklider, one of the directors of ARPA, would start to form in the years to come.

Without ARPA the Internet would not exist. It was because of this institution that the very first version of the Internet was created – ARPANET.

Creating a Global Network of Computers

Although Licklider left ARPA a few years before ARPANET was created, his ideas and his vision laid the foundation and building blocks to create the Internet. The fact that it has become what we know today we may take for granted.

Computers at the time were not as we know them now. They were massive and extremely expensive. They were seen as number-crunching machines and mostly as calculators, and they could only perform a limited number of tasks.

So in the era of mainframe computers, each one could only run a specific task. For an experiment to take place that required multiple tasks, it would require more than one computer. But that meant buying more expensive hardware.

The solution to that?

Connecting multiple computers to the same network and getting those different systems to speak the same language in order to communicate with one another.

The idea of multiple computers connected to a network was not new. Such infrastructure existed in the 1950's and was called WANs (Wide Area Networks).

However, WANs had many technological limitations and were constrained both to small areas and in what they could do. Each machine spoke it's own language which made it impossible for it to communicate with other machines.

So this idea of a 'global network' that Licklider proposed and then popularised in the early 1960's was revolutionary. It tied in with the greater vision he had, that of the perfect symbiosis between computers and humans.

He was certain that in the future computers would improve the quality of life and get rid of repetitive tasks, leaving room and time for humans to think creatively, more in-depth, and let their imagination flow.

That could only come to fruition if different systems broke the language barrier and integrated into a wider network. This idea of "Networking" is what makes the Internet we use today. It's essentially the need for common standards for different systems to communicate.

Building a Distributed Packet Switched Network

Up until this point (the end of the 1960's), when you wanted to run tasks on computers, data was sent via the telephone line using a method called "Circuit switching".

This method worked just fine for phone calls but was was very inefficient for computers and the Internet.

Using this method you could only send data as a full packet, that is data sent over the network, and only to one computer at a time. It was common for information to get lost and to have to re-start the whole procedure from the beginning. It was time consuming, ineffective, and costly.

And then in the Cold War era, it was also dangerous. An attack on the telephone system would destroy the whole communication system.

The answer to that problem was packet switching.

It was a simple and efficient method of transferring data. Instead of sending data as one big stream, it cuts it up into pieces.

Then it breaks down the packets of information into blocks and forwards them as fast as possible and in as many possible directions, each taking its own different routes in the network, until they reach their destination.

Once there, they are re-assembled. That's made possible because each packet has information about the sender, the destination, and a number. This then allows the receiver to put them back together in their original form.

This method was researched by different scientists, but the ideas of Paul Baran on distributed networks were later adopted by ARPANET.

Baran was trying to figure out a communication system that could survive a nuclear attack. Essentially he wanted to discover a communication system that could handle failure.

He came to the conclusion that networks can be built around two types of structures: centralised and distributed.

From those structures there came three types of networks: centralised, decentralised, and distributed. Out of those three, it was only the last one that was fit to survive an attack.

_Image from RAND CORPORATION_

If a part of that kind of network was destroyed, the rest of it would still function and the task would simply be moved to another part.

At the time, they didn't have rapid expansion of the network in mind – we didn't need it. And it was only in the years to come that this expansion started to take shape. Baran's ideas were ahead of his time, however, they laid the foundation for how the Internet works now.

The experimental packet switched network was a success. It led to the early creation of the ARPANET architecture which adopted this method.

How ARPANET Was Built

What started off as a response to a Cold War threat was turning into something different. The first prototype of the Internet slowly began to take shape and the first computer network was built, ARPANET.

The goal now was resource sharing, whether that was data, findings, or applications. It would allow people, no matter where they were, to harness the power of expensive computing that was far away, as if they were right in front of them.

Up until this point scientists couldn't use resources available on computers that were in another location. Each mainframe computer spoke its own language so there was lack of communication and incompatibility between the systems.

In order for computers to be effective, though, they needed to speak the same language and be linked together into a network.

So the solution to that was to build a network that established communication links between multiple resource-sharing mainframe supercomputers that were miles apart.

The building of an experimental nationwide packet switched network that linked centers run by agencies and universities began.

On October 29 1969 different computers made their first connection and spoke, a 'node to node' communication from one computer to another. It was an experiment that was about to revolutionize communication.

The first ever message was delivered from UCLA (University of California, Los Angeles) to SRI (the Stanford Research Institute).

It read simply "LO".

What was meant to be "LOGIN" was not feasible at first, as the system crashed and had to be rebooted. But it worked! The first step had been made and the language barrier had been broken.

By the end of 1969 a connection had been established between four nodes on the whole network which included UCLA, SRI, UCSB (University of California Santa Barbara) and the University of Utah.

But the network grew steadily throughout the years and more and more universities joined.

By 1973 there were even nodes connecting to England and Norway. ARPANET managed to connect these supercomputing centers run by universities together into its network.

One of the greatest achievements of that time was that a new culture was emerging. A culture that revolved around solving problems via sharing and finding the best possible solution collectively via networking.

During that time scientists and researchers were questioning every aspect of the network – technical aspects as well as the moral side of things, too.

The environments where these discussions were taking place were welcoming for all and free of hierarchies. Everyone was free to express their opinion and collaborate to solve the big issues that arose.

We see that kind of culture carrying over to the Internet of today. Through forums, social media, and the like, people ask questions to get answers or come together to deal with problems, whatever they may be, that affect the human condition and experience.

As time passed, more independent packet switched networks emerged that were not related to ARPANET (which existed on an international level and started to multiply by the 1970's) . That was a new challenge.

These different networks had their own dialects, and their own standards for how data was transferred. It was impossible for them to integrate into this larger network, the Internet we know today.

Getting these different networks to speak to one another – or Internetworking, a term scientists used for this process – proved to be a challenge.

A Need for Common Standards

Now our devices are designed so that they can connect to the wider global network automatically. But back then this process was a complex task.

This worldwide infrastructure, the network of networks that we call the Internet, is based on certain agreed upon protocols. Those are based on how networks communicate and exchange data.

From the early days at ARPANET, it still lacked a common language for computers outside its own network to be able to communicate with computers on its own network. Even though it was a secure and reliable packet-switched network.

How could these early networks communicate with one another? We needed the network to expand even more for the vision of an 'global network' to become a reality.

To build an open network of networks, a general protocol was needed. That is, a set of rules.

Those rules had to be strict enough for secure data transfer but also loose enough to accommodate all the ways that data was transferred.

TCP/IP Saves the Day

Vint Cerf and Bob Khan began working on the design of what we now call the Internet. In 1978 the Transmission Control Protocol and Internet Protocol were created, otherwise known as TCP/IP.

The rules for the Interconnection were:

• The independent networks were not required to change
• There was an effort to achieve communication
• Internal networks would exist in addition with gateways that would connect these networks. Their job would be to translate between the networks. There would be one universal, agreed upon protocol for that.
• There would be no central control, no one person or organization in charge.

As Cerf explained:

The job of TCP is merely to take a stream of messages produced by one HOST and reproduce the stream at a foreign receiving HOST without change.

The Internet Protocol (IP) makes locating information possible when looking among the plethora of machines available.

So how does data travel?

So how does a packet go from one destination to another? Say from the sending destination to the receiving one? What role does TCP/IP play in this and how does it make the journey possible?

When a user sends or receives information, the first step is for TCP on the sender's machine to break that data into packets and distribute them. Those packets travel from router to router over the Internet.

During this time the IP protocol is in charge of the addressing and forwarding of those packets. At the end, TCP reassembles the packets to their original state.

What Happened Next with the Internet?

Throughout the '80s this protocol was tested thoroughly and adopted by many networks. The Internet just continued to grow and scale at a rapid speed.

The interconnected global network of networks was finally starting to happen. It was still mainly used widely by researchers, scientists, and programmers to exchange messages and information. The general public was quite unaware of it.

But that was about to change in the late '80s when the Internet morphed again.

This was thanks to Tim Berners Lee who introduced the Web – how we know and use the Internet today.

The internet went from just sending messages from one computer to another to creating an accessible and intuitive way for people to browse what was at first a collection of interlinked websites. The Web was built on top of the Internet. The Internet is its backbone.

I hope this article gave some context and insight into the origins of this galaxy of information we use today. And I hope you enjoyed learning about how it actually all started and the path it took to becoming the Internet we know and use today.

Introduction

By the end of this article, you should have a better understanding of:

1. What DNS is and what it does
2. What DNS servers do
3. How Internet Protocol (IP) Addresses work in the context of DNS

Important concepts

There are some essential mental models to be familiar with when learning about DNS, DNS servers, and IP addresses. Going over these concepts now, before starting to learn about DNS, will

• help make sense of all the different terms used to describe behavior that fits into these models, and
• aid in memory retention.

Mental models give you a frame of reference when things get a little weird and unfamiliar.

So let’s lay the groundwork.

• Query and response. This is when Thing 1 asks Thing 2 for something, and Thing 2 responds to that request. Like this:

Query and Response

• Parent-child node relationships and graphs that look like this (only more complicated).

Tree graph

• Messages. It’s not a query and response because there is no response. In the world of DNS, the formatting and content of messages vary according to usage.

Message

• Client-server relationship. In simplest terms, a server is a software or hardware device that provides functionality for other software or hardware devices, called “clients.”

Prepare for a lot of talk about servers. As it turns out, there’s a whole lot of servers that go into this thing we call DNS, and how we, as humans, use it when we connect to the Internet.

Client-server relationship

What is DNS?

The Domain Name System (DNS) maps human-readable domain names (in URLs or in email address) to IP addresses. For example, DNS translates and maps the domain freecodecamp.org to the IP address 104.26.2.33.

To help you fully understand this description, this section details:

• Historical context for the development of DNS - what problems were it and IP addresses solving?
• Domain names
• IP addresses

Historical Context

In 1966, the Advanced Research Projects Agency (ARPA), a US government agency, founded a computer network called ARPAnet. In simple terms, think of ARPAnet as the first iteration of what we now know today as the Internet.

The main goals of ARPAnet included

“(1) providing reliable communication even in the event of a partial equipment or network failure, (2) being able to connect to different types of computers and operating systems and (3) being a cooperative effort rather than a monopoly controlled by a single corporation. In order to provide reliable communication in the face of equipment failure, ARPANET was designed so that no one point or link was more critical than any other. This was accompanied by the building of redundant routes and the use of on-the-fly rerouting of data if any part of the network failed.”

The Problems

DNS and TCP/IP were critical in solving two issues with ARPAnet:

For ARPAnet, there was a single location (a file called HOSTS.TXT) that contained all name-to-address mapping for every host on the network.

“HOSTS.TXT was maintained by SRI’s Network Information Center (dubbed “the NIC”) and distributed from a single host, SRI-NIC.[*] ARPAnet administrators typically emailed their changes to the NIC, and periodically FTP’ed to SRI-NIC and grabbed the current HOSTS.TXT file. Their changes were compiled into a new HOSTS.TXT file once or twice a week.”

There were three challenges with this set-up:

1. Traffic and load - distributing the file was becoming too much for the responsible host to handle.
2. Name collisions - each host had to have a unique name, and there was no centralized authority that prevented network users from adding a host with a conflicting (non-unique) name, thereby “breaking the whole scheme.”
3. Consistency - the act of updating the file and ensuring all hosts had the most updated version became impossible or at least very difficult.

In essence, HOSTS.TX was a single point of failure, so the entire process here didn’t scale well past a certain number of hosts. ARPAnet needed a decentralized and scalable solution. DNS was it. Source

Host-to-host communication within the same network wasn’t reliable enough. TCP/IP helped solve this issue.

1. Transmission Control Protocol (TCP) provides quality assurance measures for the process of turning messages (between hosts) into packets. The TCP protocol is connection-oriented, which means a connection between source host and destination host must be established.
2. Internet Protocol (IP) defines how messages (packets) are carried between source host and destination host. An IP address is a unique identifier for a specific path that leads to a host on a network.
3. TCP and IP work closely together, which is why they’re usually referenced like “TCP/IP.”
4. While I won’t dive into it in this article, both TCP and User Datagram Protocol (UDP) are used in the data transport layer of DNS. UDP is faster, much less reliable, and doesn’t require connections; TCP is slower, much more reliable, but needs connections. They are used as needed and appropriate in DNS; needless to say, the inclusion of TCP in APRAnet was a valuable addition to the data transport layer.

By the early 1980s, DNS and TCP/IP (and therefore, IP addresses) were standard operating procedures for the ARPAnet.

This history is very abridged. If you’d like to learn more about these topics, please reference the Resources section at the end of this article.

Now that we have some historical context, let’s move on to learning more about domain names and IP addresses.

Domain Names

In the context of DNS, a domain name provides a user-friendly way to point to non-local resources. This could be a website, a mail system, print server, or any other server that is available on the Internet. A domain name can be more than just a website!

“The goal of domain names is to provide a mechanism for naming resources in such a way that the names are usable in different hosts, networks, protocol families, internets, and administrative organizations.”

A domain name is much easier to remember and enter into a terminal or Internet browser, than an IP address.

A domain name is part of a Uniform Resource Locator (URL), but the terms are not synonymous. A URL is the complete web address of a resource, while the domain name is the name of a website and is a sub-component of every URL.

While there are technical distinctions between URLs and domain names, web browsers usually treat them the same way, so you’ll get to the website if you type in the complete web address, or just the domain name.

Top Level Domains and Second Level Domains

There are two parts to any given domain: top-level domain (TLD) and second-level domain (SLD). The parts of a domain name become more specific when moving from the right (end) to the left (beginning).

This can be confusing at first. For example, let’s look at “freecodecamp.org”

• URL: https://www.freecodecamp.org
• Domain name: freecodecamp.com
• TLD: org
• SLD: freecodecamp

In the early days of ARPAnet, there were a limited number of TLDs available, including com, edu, gov, org, arpa, mil, and 2-letter country code domains. These TLDs were initially reserved for institutions participating in the ARPAnet, but some later became available on commercial markets.

Today, there is a comparative wealth of available TLDs, including net, aero, biz, coop, info, museum, name, and others.

Second-level domains are the domains that are available for individual purchase through domain registrars (for example, Namecheap).

IP Addresses

While IP addresses are related to DNS in their function, the Internet Protocol itself is technically separate from DNS. I’ve already provided historical context for this distinction, so now I’ll explain how IP addresses function.

An IP address, as previously mentioned, is a unique identifier for a specific path that leads to a host on a network. I’d like to reference the analogy of a phone number and a phone: a phone number doesn’t represent the phone itself, it’s just a way to reach the person with the phone.

This analogy is reasonably appropriate (at least, on a surface level), with IP addresses. An IP address represents an endpoint, but it isn’t the endpoint itself. IP assignments can be fixed (permanent) or dynamic (flexible and may be reassigned).

Like a domain name, the organization of IP addresses follows a hierarchical structure. Unlike domain names, IP addresses get more specific going left-to-right. This is an IPv4 example below:

This diagram shows that 129.144 is the network part and 50.56 is the host part of an IPv4 address.

• Network: the unique number assigned to your network
• Host: identifies the host (machine) on the network

If greater specificity is needed, network administrators can subnet the address space and delegate additional numbers.

How many IP addresses are there?

IPv4 was the very first iteration of IP that ARPAnet used in production. Deployed in the early 80s, it’s still the most prevalent IP version. It’s a 32-bit scheme, and can therefore support slightly over 4 billion addresses.

But wait, is that enough? Nope.

IPv6 has a 128-bit scheme, which allows it to support 340 undecillion addresses. It also offers performance improvements on IPv4.

Example IPv4 address:

• 104.26.2.33 (freeCodeCamp)

Example IPv6 address:

• 2001:db8:a0b:12f0::1 (the compressed format and not pointing to freeCodeCamp)

How does the Domain Name System work?

So, we’ve learned about domain names! We’ve learned about IP addresses! Now how do they relate to the Domain Name System?

First of all, they fit into the namespace.

The Domain Namespace

As implied by the language “top” level domain and “second” level domain, the namespace is based on a hierarchy

“...with the hierarchy roughly corresponding to organizational structure, and names using "." as the character to mark the boundary between hierarchy levels.” Source.

This tree graph, with the root at the top, best illustrates the structure:

The Namespace

Let’s break this down, starting at the top.

The top of this graph, noted with a “.” is called the “root.”

“The authoritative name servers that serve the DNS root zone, commonly known as the “root servers”, are a network of hundreds of servers in many countries around the world. They are configured in the DNS root zone as 13 named authorities.”

The root domain has a zero-length label.

From here-on down, each node (dot) in the graph has a unique label up to 63 characters long.

The first level down from the root are the TLDs: the com, org, edu, and gov. Please note that this graph does not contain a full list of TLDs.

Below TLDs are the SLDs, the second-level domains. The children of each node are called “subdomains,” which are still considered part of the parent domain. For example, in freecodecamp.org, freecodecamp (the SLD) is a subdomain of org (the TLD).

Depending on the hierarchy of the website, there may be third-, fourth, fifth- level domains. For example, in hypothetical-subdomain.freecodecamp.org, hypothetical-subdomain is the third-level domain, and the subdomain of freecodecamp. So on and so forth, at least up to 127 levels, which is the maximum allowed by DNS.

Who manages the namespace?

Wouldn’t it be nuts to try to have one person or organization administer everything? Yes, it would. Especially because one of the chief design goals of DNS was to promote distributed, decentralized management of the system at large.

I wish I could tell you the folks in charge are called the “Namespace Kings,” but alas.

Each domain (or subdomain) in the domain namespace is or is part of a zone, “an autonomously administered piece of the namespace.” So, the namespace is broken into zones.

Responsibility for those zones is managed through delegation and administration.

The process of assigning the responsibility of subdomains to other entities is called delegation.

For example, the Public Interest Registry administers the domain name org, and has since 2003. Public Interest Registry may delegate responsibility to other parties to manage subdomains of org, say freecodecamp. And then whoever administers freecodecamp may assign responsibility for the subdomains of freecodecamp (for example, hypothethical-subdomain.freecodecamp.com) to another party.

If someone (an organization, team, or individual) administers a zone, what they’re doing is administering the nameserver that is responsible for the zone.

This brings us into one of the most foundational concepts in the Domain Name System.

Domain Name Servers

“The programs that store information about the domain namespace are called nameservers.”

At this point is where thinking about a client-server relationship, at least initially, is useful. Domain nameservers are the “server” side of the client-server relationship. Nameservers may load one, hundreds, or even thousands of zones, but they never load the entire namespace. Once a nameserver has loaded the totality of a zone, it is said to be authoritative for that zone.

To understand why nameservers function the way they do, it’s useful to understand the “client” part of the relationship.

Resolvers

In DNS, the client (the requester of information) is called the “resolver,” which may seem backward at first. Wouldn’t the server that is resolving the request be called the “resolver?” I thought so, too, but it’s not. Best to just memorize that and move on.

Resolvers are typically included, de facto, in most operating systems, so the applications installed on the OS don’t have to figure out how to make low-level DNS queries.

DNS queries and their responses are types of DNS messages, and have their own data transport protocol (usually UDP). Resolvers are responsible for helping applications installed on the OS translate requests for DNS-related data into DNS queries.

In sum, resolvers are responsible for packaging and sending off requests for data. Once the resolver receives the response (if at all), it passes that back to the original requesting application in a format consumable to the requesting application.

Back to Nameservers

Now that we are a bit more familiar with the client-side of the relationship, we need to understand how domain nameservers respond to resolver queries.

Nameservers respond to DNS queries through resolution. Resolution is the process by which nameservers find datafiles in the namespace. Depending on the type of query, nameservers respond differently to different queries, but the end goal is resolution.

Query Types

Type of query? Yes, there are multiple types of DNS queries. But first, what’s usually in a DNS query? It’s a request for information, specifically for the IP address associated with a domain name.

• Recursive: recursive queries allow the query to be referred on to multiple nameservers to be resolved. If the first queried nameserver doesn’t have the desired data, then that nameserver sends the query along to the most appropriate next nameserver, until the nameserver with the desired datafiles is found and sends a response to the resolver.
• Iterative: iterative queries require the queried nameserver to respond either with the desired data or with an error. The response may contain the IP address of the most appropriate nameserver to send the request to next; the resolver may then send another request to that, more appropriate, nameserver.

In case you need it, you can also query for the domain name, if all you have is the IP address. This is called a reverse DNS lookup.

Once the query reaches a nameserver that contains the desired datafiles, then the query can be resolved. Nameservers have a number of datafiles associated with them, all or some of which may be used to resolve the query.

Resource Records (RRs)

These are the datafiles in the domain namespace. These datafiles have specific formats and contents.

The most common RRs:

• A Record: if you haven’t heard of any other RRs except for this one, that would make sense. It’s likely the best-known RR and contains the IP address of the given domain.
• CNAME Record: if you haven’t heard of any other RRs except for this one and the A record, that would also make sense. The “C” stands for “canonical”, and is used instead of an A record, to assign an alias to a domain.
• SOA Record: this record contains administrative information about the one, including the email address of the administrator. Hint: if you administer a zone, make sure there’s a valid email address here, so folks can get in touch with you if needed.
• Other important Resource Record (RR) types are PR, NS, SRV, and MX. Read about them here.

Caching and Time to Live (TTL)

When the local nameserver receives a response from a query, it caches that data (stores it in memory), so next time it receives the same query, it can just answer the query directly rather than go through the original, longer resolution process.

But once this information is cached, it is both static and isolated, and is therefore at risk of becoming out of date. Therefore, resource records all have what is called a time to live (TTL) value, which dictates how long that data can be cached. When that time runs out (reaches zero), the nameserver deletes the record.

Important note: TTL doesn’t apply to the name servers that are authoritative for the zone that contains the resource record. It just applies to the nameserver that cached that resource record.

A Day in the Life of a Query

We’ve covered a lot of ground in this article, and it’s been heavy on the concepts. To tie this all together and make it real, here’s a day (figurative day) in the life of a query.

Source

So why do I need to know all of this?

There are so many reasons to be familiar with DNS and IP address related concepts.

• First, it’s a backbone of the Internet, the thing many of us use, develop feelings for (love/hate/you-name-it), and take for granted every day. It’s important to be familiar with the structures that enable us to accomplish great things today with technology and the Internet today.
• Incredibly smart people spent decades of their lives building this stuff! Let’s acknowledge and appreciate their contributions.
• Now that I got the gushy stuff out of the way, it’s important to be familiar with DNS concepts in case you’re responsible for anything relating to infrastructure in your company or team or your own business. Having a frame of reference when significant issues crop up allows you to act that much faster and find solutions that much sooner.

Conclusion

At this point, you should understand what DNS is and what a nameserver is, as well as be familiar with technical concepts relating to IP addresses.

Many books have been written about and dive deeper into the fascinating world of DNS, and there is so much more to learn. The topics that were not included in this article but are either part of DNS or very related include:

• Nameserver implementations
• Forwarding
• (More about) node labels
• Primary and secondary nameserver relationships
• Retransmission algorithms
• Load balancing
• Plus, other more general topics about the how the Internet functions, like:
• World Wide Web
• HTTP
• FTP
• Communication protocol layers: link layer, IP layer, transport layer, Internet layer, etc.

For those of you who are still reading and want to learn more about DNS, I first and foremost recommend “DNS and BIND, 5th Ed.”, written by Cricket Liu and published by O’Reilly Media. It’s invaluable.

I also encourage everyone to poke around in the original Request for Comments (RFCs) linked below. Not only are there points for reading primary sources, but they’re also exceptionally well-organized and comprehensible documents, which is why I quoted them in this article.

Resources

1. RFC 1034: DOMAIN NAMES - CONCEPTS AND FACILITIES
2. RFC 1035: DOMAIN NAMES - IMPLEMENTATION AND SPECIFICATION
3. RFC 1122: Requirements for Internet Hosts -- Communication Layers
4. More about DNS Design Goals, from Connected: An Internet Encyclopedia
5. How the Internet was Born from the ARPAnet to the Interpret, from The Conversation
6. Learning DNS Video Course, by Cricket Liu, from O'Reilly Media

A bit about me

I'm Chloe Tucker, an artist and developer in Portland, Oregon. As a former educator, I'm continuously searching for the intersection of learning and teaching, or technology and art. Reach out to me on Twitter @_chloetucker and check out my website at chloe.dev.