DNS Servers, Roles And Functions

The internet is a confusing web of connections, protocols, servers, service providers,

and more. There are a lot of interconnecting forces at work that help your browser
provide the content you expect. Domain Name Services, or DNS, is a large part of what
helps this remain consistent. This guide aims to help you in understanding DNS Roles
and Function.

Domain Name Services

The internet is a network of connected computers either publicly available or within a
private, internal network. These computers and resources are all assigned an IP
Address. For instance, Google’s Home Page is hosted on one of many different IP
Addresses. How does your browser know, then, to go to those IP Addresses when all
you give it is a domain name? That is where DNS comes into play. DNS associates a
domain name to a place to find content for that domain.

The Roles Of DNS

When you want to call someone, you typically load up your contact list, tap their name
and hit call. You know that behind the scenes, this associates a phone number with the
contact, and your cellular connection initiates a phone call. DNS is your internet
phonebook. It lets you tell your browser to go fetch a domain name and automatically
know the physical IP Address, without you ever having to do more than hit the enter key
and wait. Make sense? I hope so. Let’s talk about how it works.

DNS Function

DNS relies on two major parts: a Nameserver and the DNS Records. The purpose of
a nameserver is explicitly to store information on how to find the DNS Records. When
your browser makes its request for a domain, the Nameserver it uses provides a
location to find details about the DNS Records. Without too much detail, a DNS Record
is what actually converts a URL (uniform resource locator, web address) into an IP Address.
Let’s take a look at the below example. You enter google.com into your browser. Your
browser reaches out to the root nameservers for any .com domain names from Verisign
(the root) and finds the nameserver for Google.com. That nameserver
is ns1.google.com. Now, that nameserver points you to the DNS Manager for the
domain, google.com. Upon checking, the DNS Manager provides 172.217.9.238 as
the DNS Record for google.com. Your browser then lands at the above IP Address
showing google.com’s site content.

A visual example of the DNS Process

It can be a bit overwhelming, as it is a lot of information. Even this is a fairly simple
showcase of how DNS works. The most important take away here is the role of DNS is
an extremely important aspect of ensuring the proper functions of a website.

DNS At Hostwinds
Hostwinds offers options to manage DNS Records for domains that are purchased here
or need to be managed in your Hostwinds Cloud Portal to point to your server. The
Nameservers we provide with your service control where your DNS Records are
managed. Let’s provide a couple of example scenarios:

Shared Web Hosting DNS

Within our Shared Web hosting plans, your DNS Records are managed by your cPanel
account. To allow the cPanel account the ability to control your DNS, our Shared web
hosting plans are provided specific URLs to use as Nameservers. They will look
something like this:

seans1.hostwindsdns.com

seans2.hostwindsdns.com

These would be the nameservers you provide to your registrar, or, the location in which
you last paid for your domain. Once your domain is using these nameservers, your
cPanel account takes control of the DNS Records. You would edit them using the
DNS Zone Editor within cPanel.

Cloud VPS Hosting DNS

The Cloud VPS hosting options provided at Hostwinds does not offer a default DNS
manager. Not all clients need this. As such, Hostwinds provides an external tool within
the Cloud Control portal. The Cloud DNS Manager acts as your DNS Records manager.
Nameservers that point to the Cloud DNS Manager look like this:

mdns1.hostwindsdns.com

mdns2.hostwindsdns.com

You would use these if you do not have a service or software running on your VPS that
manages DNS records. Adding DNS Records to the Cloud DNS Manager is a separate
step, and must be done manually in this case.

Private Nameservers

Whenever a nameserver is required, there is an option to create your own URL with a
domain you own. For instance, if you own the domain example.com, you could create
ns1.example.com and ns2.example.com. For domains purchased at Hostwinds, follow
our Private Nameserver Creation guide. Otherwise, take a look at our other guides that
feature other common registrars.

DNS Wrap Up

Understanding DNS Roles and Function is a difficult concept to grasp. Here at

Hostwinds, our goal is to ensure you get the help you need. Don’t forget that we are
available 24/7/365 via LiveChat and through our Technical Support tickets, so if you
have further questions, reach out!
 What is DNS? Domain Name System, DNS
Server, and IP Address Concepts Explained

Chloe Tucker

Introduction
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:

 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