Internet Performance Delivered right to your inbox

How Does the Domain Name System (DNS) Actually Work?

Understanding fundamental Domain Name System (DNS) concepts is a critical part of your understanding of how the internet works. DNS is the mechanism that helps you get from Point A to Point B. This blog series will cover basic DNS terminology, in general terms, with nothing vendor-specific or proprietary. There are many opinions on this subject, so I will lay out multiple points of view, wherever possible. The goal is to provide a good representation of all these terms and how they actually function in the real world, while covering as many as we possibly can. Ready?

Global DNS

Let’s kick this off by defining the actors on the stage. The DNS can really be broken down into three major groups from a request perspective, and those are the 3 requests you need to understand: user, recursive, and authoritative. As we’ll discuss later, there are a number of things you can be authoritative for.

This can’t possibly be repeated enough: users are our eyeballs on the edge of the internet accessing internet resources. Whenever we hit a URL like http://www.dyn.com/blog, our devices parse it out into multiple parts.

http:// www.dyn.com /blog
Scheme DNS name path

The scheme defined the protocol by which this URL will be accessed as http. The DNS name of the resources is www.dyn.com, and more specifically the IP address represented by that DNS name. Lastly, the path at the webserver is /blog. To access that nameserver, our device needs the IP address represented by the DNS name. If it has that answer stored locally (that is, in cache), it will go to that IP to read the blog. The rest of the time, it needs some help from the recursive resolver defined for the network.

How a Request Is Resolved

For most of the world, the default designated recursive resolver is a server provided by the local internet service provider (ISP) or the business maintaining the network. The job of the recursive is to make requests to the larger DNS ecosystem on behalf of the user, allowing for economies of scale and freeing up resources for the user. Ultimately, the recursive will ask a series of DNS servers that are authoritative for components of the DNS in order to process the request and hand back to the user the IP of the DNS name that was requested. It looks broadly like this:

When the recursive is interacting with the DNS, it is navigating the largest distributed database in the world. The DNS is formatted in a large tree structure much like the folder structure on your computer. Like any tree structure it has a beginning known as root. If we go back to our www.dyn.com example, the actual real host has a usually unrepresented “.” at the end – www.dyn.com. – which represents that beginning of root.

The recursive will check its cache left to right (do I have www.dyn.com? Dyn.com? Com?). However, if it doesn’t have any of the answers in cache, the recursive goes to the root to get things started. The idea of the root is to provide an origin to the query, providing the nameservers for all the Top Level Domains (TLD) such as com, net, fr, edu, and others. The root then delegates the authority for the namespace of that name to the authoritative DNS of an organization designated to run that TLD independently. This process is called a delegation.

TLDs come in a couple varieties. First, they can be run for a country (like .fr for France and .sg for Singapore), and these are called ccTLDs. They can also be generic like .com or .net. These are called gTLDs. Lastly, there is a variation of gTLD, which is wholly owned and operated by an organization as though it were a normal domain like .nike or maybe .dyn. These are called colloquially “.brand” TLDs, even though they are really just commercially special TLDs.

Sometimes, TLDs will divide their namespace a little further before allowing names to be individually registered, such as breaking out edu.sg, co.uk, or gov.il. These are called Second Level Domains, or SLDs.

Registering a Domain and Creating a Zone

Most TLDs are commercially operated and lease off portions of their namespace for private operation. The group that maintains a TLD is known as a Registry, while the authorized resellers of those names are Registrars. Therefore, when you go to the Dyn website and register wacky-awesome-cats.info, you are interacting with a registrar for the .info registry.

When you register a domain, a few things happen. You register the domain, which designates the DNS namespace of that domain—and all its children—to you. This initiates the process to create a DNS zone, a unit of DNS administration. The zone is fully established when a SOA record is created at the location the nameservers designated in the registration. This registered domain can actually spawn multiple zones within the total namespace, but there will be at least one zone to start. At any rate, when you register that domain, one of the things the registrar will ask is which DNS servers will act as the authority for your domain. This acts to delegate the authority of your domain to your own authoritative DNS servers, exactly as the root delegated the TLDs above. Do you sense a pattern? It’s “turtles on turtles” all the way down.

Let’s review before we get into the topic of my next blog: the terms used to manage a zone at a DNS provider on a day-to-day basis. We registered a domain, which created a zone, via a registrar, acting for a registry of a TLD, which is a division of the DNS namespace below the root, through a process of delegations, in order to provide answers to users through their recursives to our domain authoritative DNS. In our next installment we will go further into records and zones themselves.

Got all that? Get ready, because in my next blog, we’ll do a deep dive into zones.


Share Now

Whois: Matt Torrisi

Matt Torrisi is a Senior Solutions Engineer at Oracle Dyn Global Business Unit, a pioneer in managed DNS and a leader in cloud-based infrastructure that connects users with digital content and experiences across a global internet.