The DNS is the distributed name service and database that provides a system for associating registered domain names with corresponding IP addresses and related services necessary for sharing information across the internet. DNS servers respond to queries, returning the correct IP addresses for web servers, mail servers and other internet services. Conceived in 1983, and put into practice in the following years, the DNS delegates the responsibility of assigning and mapping names to IP addresses via a system of servers. The DNS uses its namespace and specified protocol to make those connections. The DNS namespace is the hierarchy by which domain names are organized on the internet. The DNS protocol is the “rulebook” used by computers, applications, mail servers and more to enable communication with any service associated with a domain name.

Everything connected to the internet — laptops, tablets, mobile phones, websites, smart devices — has an Internet Protocol (IP) address, a unique numerical identifier assigned to each connected device or network.

Internet Protocol (IP) address

The IP address space is managed by the Internet Assigned Numbers Authority (IANA) and the world’s five regional internet registries (RIRs). IANA assigns specific ranges of computer-generated IP addresses to the RIRs, which then distribute them to local internet registries, such as internet service providers (ISPs) in their region.

Your favorite website might have an IP address like 104.22.52.141 or 2606:4700:3032::6815:3565, but those aren’t easy to memorize. On the other hand, a domain name, such as dnib.com, is easily recognized and memorable. The DNS is a distributed database managed by thousands of servers worldwide responding to queries in a process called resolution: retrieving the assigned, machine-readable IP addresses associated with human-memorable domain names.

The DNS parallels the progression of our telephone networks. Telephone operators once manually connected and directed calls using protocols and hierarchies of area codes, numbers and exchanges listed in a printed directory. Similarly, early architects of the internet maintained a text file listing human-readable domain names and their corresponding machine-readable IP addresses. Now, the DNS achieves the same kind of connections using its own protocols and hierarchy for the internet.

HOSTS.txt file

The HOSTS.txt file was managed by the Stanford Research Institute’s Network Information Center (NIC) under the supervision of Elizabeth "Jake" Feinler and her team. The HOSTS.txt file had to be manually updated and distributed to all users on the network.

Before the DNS, users had to remember, or look up in a physical book, individual IP addresses to access resources. In a small, contained system, like the early years of the internet, this was not a huge problem. But it quickly became clear that scaling and managing this analog system would be untenable as the internet grew in size and use cases.

How Does the DNS Work?

The DNS as we know it today functions seamlessly due to an adherence to the DNS protocol and the many thousands of people and organizations that support it. The current DNS protocol standardizes how the distributed DNS database is queried and updated across the internet, using specific message formats, communication methods and name resolution procedures through different types of servers.

The original DNS protocol was outlined in the 1980s, in a series of documents called RFCs, by the internet’s early architects and the Internet Engineering Task Force (IETF). Two documents, RFC 882 and RFC 883, authored by Paul Mockapetris in November 1983 defined the DNS. 

RFCs

RFCs are documents published by the Internet Engineering Task Force (IETF) outlining the technical foundations of the internet, such as routing and addressing, and specifying the protocols used to deliver services over the internet, such as email and the DNS.

The acronym comes from their historical title, Request for Comments, though that no longer accurately describes these standards and best practices once they are finalized.

The first RFC was published in 1969, before the IETF even existed, and there are now more than 9,000 documents in the series. A new RFC can render an old one obsolete, or just update it, but once an RFC is published, it is never changed – making for an extensive IETF-maintained archive. Even if a technical or editorial error is discovered after publication, the error is documented and either verified or rejected by international standards experts, added to a searchable database and linked to the RFC.

After four years of managing and using the DNS, Mockapetris updated and expanded the original documents with RFC 1034 and RFC 1035. These RFCs describe the concepts and theory behind DNS and specify the implementation details for protocols, data structures and the transmission of queries and responses.

We all use the DNS and these protocols every day – even if we don’t realize it! Let’s explore the components and processes that keep billions of internet users and hundreds of millions of domain names connecting.

DNS Components

The DNS has four main components:

  1. Namespace and resource records
  2. Name servers
  3. Recursive resolvers
  4. Client software

Namespace and Resource Records

Domain names are the part of the DNS with which end users and systems interact. The DNS namespace is organized in a standardized hierarchical structure and each domain name has associated data called resource records. There are many types of resource records relating to a domain name’s use, some better known than others. One of the most common, the A Record or Address Record contains the IP address used by your browser to reach a website. Others include the Mail Exchange Record (MX record), which routes a domain name’s email to the right server or the DNS Key Record (DNSKEY), a public key used to verify DNS Security System Extension (DNSSEC) signatures, which is a security protocol designed to mitigate certain common DNS attacks.

Name servers

Name servers store information about an assigned group of domain names and are responsible for keeping data current and responding to queries. The group of domain names a name server is responsible for is called a zone. Name servers provide recursive resolvers with authoritative data for its assigned zone of domain names. They are sometimes called “authoritative name servers” to distinguish them from other DNS components.

Recursive resolvers

Recursive resolvers are the intermediaries between user requests and name servers. To respond to, or resolve, a DNS query, the resolver retrieves authoritative data from the hierarchy of name servers. If it’s a query the recursive resolver has responded to recently, it uses the previously queried cached information to respond.

Caching

Recursive resolvers maintain a small database of query responses for a specified period of time before they need to be refreshed. This cache can be reused for future queries, since many DNS queries are duplicates – more than one user asking for the IP address of dnib.com – with the same reliable answer. Caching reduces the number of times recursive resolvers need to ask authoritative name servers for frequently queried domain names, making resolution even faster and more efficient.

Client Software

All internet-enabled devices, from laptops to smart TVs and thermostats, have software designed to interact with and request address information from the DNS. An email application needs this information to find the destination IP address to send a message and a browser needs this information to connect to the IP addresses of the server hosting a website.

DNS Resolution Process

DNS resolution takes place behind the scenes, instantaneously, between recursive resolvers and applications like web browsers and email clients. The DNS stores and responds to queries for many of types of information related to domain names. But the most familiar type of DNS resolution is probably the process of translating a domain name into an IP address – when you type a domain name into a web browser and the page you were seeking appears on your screen.

Let’s take a look at how it works.

The Query

When you type www.dnib.com into your browser, the browser sends the request to the client's DNS service for resolution using locally saved information. If the queried name can be resolved with previously saved data, the query is answered and the process is complete. If the query does not match or it is the first time this query has been made, your browser sends it across the internet to find the IP address for the web server hosting the website you’re seeking. Let's follow the path of this question through the DNS components.

The Recursive Resolver

The first server your query interacts with is the recursive resolver, which may be operated by your Internet Service Provider (ISP), your wireless carrier or a third-party provider. The recursive resolver knows the steps for asking other DNS servers where to find the answer to your original query, “What is the IP address of the web server for www.dnib.com?”

If the recursive resolver already has the answer for your query in its cache, it returns the answer to your browser or other software. If it doesn’t have the answer, it asks the servers in the DNS hierarchy to point it in the right direction, quickly reaching the authoritative name server for the domain name in your query.

The Root Server

When the recursive resolver has no current information cached for the domain name you seek, the first type of DNS server it talks to is a root server. There are thousands of root servers operating all over the world, each with the same DNS information about all top-level domains (TLDs) in a file called the root zone.

To begin answering your query, the recursive resolver looks for DNS information about the TLD for the domain name you’re querying – in this case, “.com.” The root server – the trusted authority for the root zone – replies to the recursive server with the addresses of the authoritative name servers for the TLD in the query.

The TLD Name Server

Each TLD name server stores DNS information about all of the different authoritative name servers for second-level domains (SLDs) – in your www.dnib.com query, “dnib” is the SLD within the .com TLD. The recursive resolver sends the full query to a TLD name server, usually the one closest based on network topology.

The TLD name server does not have the final answer to the question of “what is the IP address of the web server for www.dnib.com?” because it does not store IP addresses for web servers – but it does have the list of authoritative name servers for the SLD. So, the TLD name server answers the recursive resolver with the IP address of the domain name's SLD name server, which will provide the next piece of the puzzle.

The SLD Name Server

Next, the recursive resolver queries one of the SLD name servers for the domain name you’re asking about. This server is an authoritative server for the SLD, so it knows all the services and IP addresses associated with the domain name dnib.com, including the IP address of the web server. The SLD name server responds to the recursive resolver with the IP address of www.dnib.com’s web server.

Resolution

Now that the recursive resolver knows the IP address of the web server for the domain name in your query, the recursive resolver returns it your browser.

With this information in hand, your browser sends a request to the website’s server and retrieves the content you seek.

Fractions of a Second

Query resolution happens in the blink of an eye! Here, we've slowly walked through the step-by-step process for a basic DNS query, which happens in a fraction of a second. The process might seem involved, but this computer-to-computer communication takes very little time at all.

Conclusions

We have discussed what the internet would be like without the DNS, who created it, and how it works, including what happens – in a split second! – when you type a domain name into your browser.


VIDEO: DNS Resolution for Websites

Glossary