DNS: How the Internet’s Naming System Works

The Domain Name System (DNS) is a naming system used to help locate different entities on the networks such as the Internet. It’s kind of like a modern-day phone book that helps one computer find another using a series of names, numbers, and protocols. DNS helped bring you to this website and plays an integral role in modern society.

Domain Name System (DNS) was first presented in RFC1034 with elaboration on domain naming conventions expanded in RFC1035. The DNS system has been updated considerably through various successive RFCs. DNS is a very complex system built on very simple concepts: distributing responsibility makes things more flexible and more widely accessible.

What is DNS; Why DNS is Important

DNS is like a phonebook for websites. It translates common names like example.com into IP addresses so computers can load remote resources. It prevents us from having to remember numbers like 93.184.216.34 (IPV4) or—even worse—something like 2606:2800:220:1:248:1893:25c8:1946 (IPV6). This keeps things human-readable at a high level but allows for easy translation into machine-readable formats for efficiency.

Every device connected to the Internet has a unique IP address assigned so other devices can find it. In this way, IP addresses are like physical addresses. When you type example.com into your web browser, the first request is to a DNS server to translate that human-readable name into an actual IP address. Only then can your browser connect to the example.com web server and load the page.

A more technical description of DNS is as follows:

1. A distributed database system that implements a hierarchical structure of DNS servers;
2. Application-layer protocol that allows clients to query the DNS database;

That’s just for us geeks out there. The general takeaways are that DNS allows one computer to find another and that it uses a pretty complex network of other computers to do so. This complicated process is known as DNS resolution or DNS lookup.

DNS Services

DNS can be thought of as the internet’s directory service. It’s utilized by a wide range of applications including email clients, FTP clients, and especially web browsers. Each of these uses a DNS lookup protocol to translate common hostnames into IP addresses that can be used by network routers to facilitate TCP/IP connections. The basic protocol of DNS Lookup is outlined here:

1. A client captures a hostname from a user request (example.com)
2. The client passes the hostname to the client-side DNS resolver
3. The DNS resolver sends a request with the hostname to a local DNS server
4. The Local DNS server responds with the IP address of the hostname
5. The client uses the IP address to initiate a TCP/IP connection with example.com

DNS is designed to be a “black box service” such that consumer applications like email, video games, and web browsers can make a single network request and receive a single network response. Behind the scene, however, the process is much more complex and involves several distinct phases of DNS resolution.

[alert type=yellow ]Summary: DNS “resolves” hostnames into IP addresses.[/alert]

Application-Level Services

DNS itself is an application-layer service meaning it provides utility to software applications of all types. This includes operating systems, email clients, web browsers, and even video games. When a piece of software needs to find an IP address for a hostname—it uses DNS services.

Most web-based applications use Transmission Control Protocol (TCP) for communication between servers. TCP offers reliability, among other services, that is preferable for things like web streaming, loading websites, and even transmitting login credentials. However, TCP requires a bit more work on the backend to facilitate these services.

For this reason, DNS relies on another protocol named User Datagram Protocol (UDP) which runs on port 53. In a nutshell, UDP reduces the number of times that DNS servers have to communicate back-and-forth so data transmission can begin more quickly. Keep in mind, before a webpage can start to load—DNS has to be resolved.

Hostname Aliasing – Allows one hostname to represent another. For example, www.example.com could be an alias for example.com In this case, example.com is considered the canonical hostname.

MailServer Aliasing – Mailserver aliasing is similar to hostnames but differs in that it’s email specific. This allows email addresses such as bob@12.us-relay-west-7.example.com to be simplified to bob@example.com.

Load Distribution/Balancing– Modern websites are often replicated on several servers such that many IP addresses are associated with the same canonical hostname. Load balancing selects from a list of IP addresses when responding to DNS queries as a means of distributing client requests across several different servers.

[alert type=yellow ]Summary: DNS relies on UDP protocols to minimize network requests and offers several services to help distribute requests to simplify network structure.[/alert]

DNS Servers

Internet Service Providers (ISPs) provide local DNS servers for their customers that store records of common hosts. For example, your ISP absolutely knows the IP address for google.com. ISPs cache DNS records for hostnames to help reduce the time their customers have to wait to connect to websites and other remote hosts.

What happens when new websites are queried? What about when a website changes its IP address? These are cases where local DNS servers don’t have the required information for customer applications. In these situations, local DNS servers must then go out onto the DNS server network to find the IP address. This can be a complex process and involves several steps.

DNS queries originate from the Application layer and, regardless of the depth of traversal on the DNS server network, ultimately end up on the Application layer of each successive DNS server. The process can become complex based on network design but involves the following stages.

[alert type=yellow ]Summary: DNS Servers are on a global, distributed, complex network.[/alert]

DNS Resolvers

DNS lookup requests originate from a wide range of applications including email, web-browsers, and even video games. Using local DNS resolver services, applications are able to make simple DNS hostname requests and not have to worry about the complexity. DNS resolvers typically communicate directly with local ISP DNS servers but applications can easily be configured to use 3rd party services such as Cloudflare’s 1.1.1.1 instead.

Local DNS Servers

The first step in DNS resolution is through a client’s ISP via UDP on port 53. The request is passed to the local DNS server. Local DNS servers cache hostname/IP translations and, if the DNS record already exists and has not expired, the local DNS server can immediately provide the IP mapping for the queried hostname. Otherwise, the local DNS must venture onto the DNS network for updated information.

Root DNS Servers

Root servers are the most authoritative servers on the DNS network. Currently, there are 13 root DNS servers located around the world hosted by entities such as Verisign, Inc., Cogent Communications, NASA, and the US Department of Defense (R).

The Root DNS servers are tasked with maintaining a database of Top-Level Domain (TLD) mappings that include things like .com, .net, .org, .gov, and even country-specific mappings like .us, .co.uk, and .zm. These mappings direct DNS hostname queries to the DNS servers responsible for finding host/IP mappings specific to a given TLD (R).

The Internet Address Name Association (IANA) is responsible for maintaining a publicly-viewable record of Root DNS records. Using their database, one can quickly find the mappings between TLDs and nameservers. For example, the .com TLD has the following information:

Sponsoring Organization

VeriSign Global Registry Services

12061 Bluemont Way
Reston Virginia 20190
United States

Name Servers

This type of information is available for all TLDs available and used by Root DNS servers to provide accurate nameserver information for Local DNS server requests.

TLD Servers

TLD servers direct DNS queries to a deeper level DNS server specific to a single Generic Told Level Domain (gTLD). These DNS nameservers are maintained by individual organizations that have applied for respective gTLDs registered via ICANN (R). Common applicants include government agencies, countries, and corporate entities.

The U.S. Department of Defense (DoD) has been charged with oversight of ICANN in the past. In 2016 however, as an extension of an earlier removal of DoD oversight, U.S. lead oversight of ICANN was relinquished (R). The oversight of ICANN has been, expectedly, a very politicized debate. Generally speaking, the new model is a multi-stakeholder model such that no single country would have total control and all would be privy to pertinent details.

After a DNS query has found it’s TLD DNS server, there is still the chance that an IP mapping is not available. TLD DNS servers sometimes only provide Name Service mapping to another, authoritative, DNS server. In such cases, the TLD server must then send a DNS request to that server.

Authoritative Server

Any entity with a publicly-accessible hostname must maintain publicly-accessible DNS records that map a hostname to a server IP address. The authoritative DNS records are, in a manner of speaking, the final say as to which IP address should be mapped to a particular hostname. This DNS server is the deepest within the DNS server hierarchy.

There may be several “hops” on the network between a TLD DNS server and the final Authoritative DNS server. For example, a DNS TLD server may point to a common domain registrar, such as NameCheap.com where an NS DNS record may then direct DNS queries to a WebHost like FlyWheel.com’s DNS Zone Files which would potentially contain an authoritative DNS mapping between hostname and IP.

DNS Query Types

DNS queries can be made in several ways. Which each request, a DNS query receives a response from a DNS server. Depending on that response, the initial querying DNS server may still have some work left to do. There are two primary DNS Types: recursive and iterative. In recursion, a program continues to run itself until a specified condition is met. In iteration, a set of specific instructions are run until a condition is met. The differences may seem subtle but in practice, these are two very different approaches. DNS is no exception.

Iterative DNS Query

Iterative DNS queries are such that a single server, usually an ISP’s local DNS server, orchestrates the DNS lookup process. In iterative DNS lookups, the local DNS queries each component necessary to find a hostname/IP mapping. In iterative-based DNS queries, servers may respond with a referral answer that directs the Local DNS to query another server. Below is an example iterative DNS query:

1. The client queries the local DNS server for example.com IP address.
2. Local DNS queries Root DNS for gTLD DNS;  gets a response
3. Local DNS queries gTLD DNS for Authoritative DNS; gets a response
4. Local DNS queries Authoritiatve DNS; gets a response
5. Local DNS sends a response to the initial client.

[alert type=yellow ]Summary: Iterative DNS lookups require the Local DNS server to handle the majority of network requests.[/alert]

Recursive DNS Query

Recursive DNS queries are structured such that no DNS server answers a query with a response only partially-sufficient to map a hostname to an IP address. In this query type, if a DNS server cannot respond with an answer, it will make requests to collect the required information. An example of a recursive DNS query is as follows;

1. The client queries the Local DNS server for example.com’s IP Address.
2. The Local DNS queries the Root DNS Server; awaits a response.
3. The Root DNS server queries the gTLD server; awaits a response.
4. The gTLD server queries the Authoritative server; gets an IP address.
5. The gTLD server then passes the IP address to the Root DNS server
6. The Root Server then passes the IP address to the Local DNS server.
7. The Local DNS server then passes the IP address to the client.

[alert type=yellow ]Summary: Recursive DNS queries require the lookup to be distributed on the network such that all DNS servers handle, at most, a single request.[/alert]

Non-Recursive DNS Query

In some cases, a DNS server may immediately know the answer to a DNS query. A DNS server may be able to utilize DNS caching to have saved the IP address for a previously-queried hostname or a DNS server might also be authoritative for a hostname. Either way, the DNS query has to resolve somewhere and when that server is queried it’s considered non-recursive.

[alert type=yellow ]Summary: Non-Recursive DNS queries are used when a DNS resolver already knows the answer and no more DNS servers need to be contacted.[/alert]

Pros vs. Cons

Recursive DNS queries typically resolve faster than iterative-based queries. Also, recursive minimizes the number of queries (load) on any single DNS server. Recursive DNS servers cache the IP addresses of each request and store that information for a specified amount of time, known as the Time to Live (TTL) value.

Recursive DNS opens up the DNS system to possible security issues such as DNS amplification attacks and/or DNS cache “poisoning” (R). DNS servers can be configured to either allow/disallow recursive requests based on the administrative entity(ies) preference. For example, the most common DNS Server client BIND (R) has options for allowing/disallowing recursive DNS (R).

[alert type=yellow ]Summary: Recursive DNS has some notable benefits but ultimately comes with some major security concerns for public services.[/alert]

DNS Zones

Just like different components of DNS (root, gTLD, Authoritative, etc.) are responsible for DNS queries, DNS Zones delegate responsibility. DNS zones are different from DNS servers in that each zone is responsible for a certain sub-domain and/or sub-domains. The difference is most evidenced in comparing to gTLD servers: A DNS query to example.com will resolve, eventually, to the Authoritative server for example.com. However, what if the request is for blog.example.com?

In this case, the gTLD server will map to a server with a DNS zone record for the hostname example.com. This server will contain information for DNS mappings to the example.com and blog.example.com hosts. These hosts may resolve to the same IP address via aliasing, may point to two different servers, and may require further DNS querying to resolve to an authoritative server. Per RFC1024; a domain is a subdomain of another domain if it is contained within that domain.

[alert type=yellow ]Summary: DNS Zones help organize many authoritative DNS servers in a distributed fashion.[/alert]

DNS Resource Records

DNS servers are responsible for maintaining a myriad of different records as they pertain to hosts. These record types are used to meet different demands and offer a wide range of options. Below are some of the most utilized and popuar DNS record types.

Address Mapping Record (A-Record) – Stored by the authoritative DNS server. Maps a hostname to an IP address.

IPV6 Address Mapping Record (AAAA-Record) – Stores the IPV6 address of a hostname

Canonical Name Record (CNAME) – Used to alias one hostname to another. A common example is the www CNAME record to map www.example.com -> example.com

Mail Exchanger Record (MX) – Specifies the SMTP server for a hostname, used to route emails.

Name Server Records (NS) – Specifies another DNS server as being authoritative for a host and containing the A record and corresponding IP address.

Text Record (TXT) – Contains machine-readable data commonly used in Domain verification, encryption, and validation services.

Start of Authority record (SOA) – Specifies information about a particular domain or DNS zone. Contains information like admin contacts, when the domain was last updated, and how long a server should wait between refreshes.

Authoritative vs. Non-Authoritative

DNS servers host a myriad of records that may, or may not, result in a final answer to a resolver’s query. In the latter case, a DNS Server may indicate that another DNS server should be queried to adequately resolve a hostname lookup.

In cases of iterative DNS queries, a Non-Authoritative DNS server will respond to a query indicating that another DNS server should be contacted. The initiating resolver will then send a separate request to that server that may, or may not, be authoritative.

In recursive DNS queries, a Non-Authoritative DNS server will forward the query to the next DNS server and expect an answer in response. This dynamic is one reason recursive DNS is more efficient, albeit more prone to security risks.

[alert type=yellow ]Summary: There are many types of DNS records each suited for specific use cases that may or may not result in a direct resolution to an IP[/alert]

DNS Record Examples

DNS resource records store a different number of values based on their intended use. For example, A-type records (Authoritative) store 4 values:

• Name – The hostname
• Value – IP Address, Another Hostname, etc.
• Record Type – A, CNAME, TXT, etc.
• TTL – How long the record should be cached.

Consider the following example of an A-Type DNS record for the domain example.com:

• Name: example.com
• Value: 123.456.789
• Type: A
• TTL: 3600

NameServer (NS) records (Non-Authoritative) only store 3 DNS values and indicate that another DNS server is authoritative for a particular DNS query. A NS record may look like this:

• Name: example.com
• Value: ns1.domain-name-service.net
• Type: NS

Note the lack of the TTL value in this record. Given the DNS server’s lack of authority for the host, it’s unable to provide that information.

[alert type=yellow ]Summary: There are several different types of DNS records with distinct data formats[/alert]

DNS Caching

DNS caching is no different than the general concept of data caching, other than that it deals specifically with DNS. Local DNS resolvers often store the response to successful DNS lookups for a specified amount of time before trying again. DNS caching allows applications like web-browsers to resolve DNS much more quickly without having to venture into the full DNS hierarchy for every request.

DNS caches can appear on different nodes of a DNS network as well as the operating system and applications of the user. For example, Windows has a DNS cache, Google Chrome has a DNS cache, and even local ISPs have a DNS cache. In some cases, such as updating content on a remote server, users may be unable to view those changes until the local ISP DNS cache, OS, or application DNS cache has been flushed (deleted.)