Are you curious about DNS (domain name system), the system responsible for routing traffic for every domain on the web?
In this post, you will learn what DNS is and exactly how it works.
Let’s get started:
What is DNS?
The domain name system (DNS) allows us to access websites with an alphanumeric web address.
The world wide web as we know it was invented in 1989, and the first web page didn’t go online until 1991. Still, the internet was being developed and in use decades before then.
Your website and other entities hosted on the web have a specific location on the net. This is represented by a numeric IP address, such as 220.127.116.11, similar to how your street address represents the location of your home.
Domains, such as bloggingwizard.com, didn’t exist when the internet was being developed. Its users were required to enter a location’s IP address instead. Given how difficult it is to remember and enter numeric addresses for everything the internet’s users needed to access at this time, finding a new method to access them was crucial.
Paul Mockapetris brought this new method to the internet when he invented the domain name system in 1983. By 1984, internet users could access the net’s locations with user-friendly, alphanumeric domain names and six top level domains (TLDs):
- .com – created for commercial purposes.
- .org – created for organizations.
- .net – created for networks.
- .gov – created for government-sponsored locations.
- .edu – created for educational computer systems.
- .mil – created for military-sponsored locations.
DNS is responsible for translating every domain on the web into an identifiable IP address.
When you want to visit a website, your browser relies on this system to find its exact location on the web.
What is a nameserver?
You may find that some people use the terms DNS and nameservers interchangeably. Typically because they are referencing the exact same thing – your DNS records.
In a technical sense, a nameserver is simply the server where DNS records are stored.
How do domains work?
In order to understand how domain servers work, we need to understand how domains work.
Domains are the alphanumeric addresses we use to access specific locations on the web, typically websites. As we explained earlier, they represent the IP addresses that identify those locations and allow us to access them without having to enter those IP addresses into our address bars.
When you enter a web address into your browser, the DNS goes through several steps before your browser loads the web page you’re trying to access a second later.
In order for your browser to complete your request, it must receive the IP address of the domain you’re trying to access from the DNS. This is called DNS resolution, and it runs through a few different nameservers before it completes your request.
This includes the TLD nameserver.
TLD stands for “top level domain.” Domains have a hierarchy made up of three levels, though modern domains only use the second and top levels. Here’s an example featuring the domain of the tool I’m using to write this draft, Google Docs.
Google Docs’ domain – docs.google.com:
- docs = third level or “subdomain.”
- .google = second level or “domain name.”
- .com = top level or “domain extension.”
Remember when we said there were only six TLDs in 1984? Today, there are more than 1,500. They’re organized into three different categories.
Generic top level domains (gTLD) are the biggest category. gTLDs include common domains like .com, .org and .net but also include more unique iterations. When you register a domain today, you’ll find offers for domains that include such TLDs as .biz, .me, .io, .xyz, .pizza, .beer, .motorcycles and more.
Sponsored top level domains (sTLD) are TLDs sponsored by specific entities, such as governments, military forces and educational organizations. As such, these TLDs include .gov, .mil and .edu.
Country code top level domains (ccTLD) are TLDs made for specific countries. Websites use them when they want to target customers in specific countries. There are more than 200 ccTLDs in existence, including .uk for the United Kingdom, .ru for Russia, .cn for China, .br for Brazil, and so on and so forth.
When you register a domain, you need to choose a domain name and TLD for it. Its IP address will be stored on your registrar’s DNS server.
It’s important to note that you will not have authority over other domains that use your domain name with different TLDs unless you register it.
This means if you register example.com, a competitor could register example.xyz. They’re treated as entirely different domains by the DNS.
In order to have your new domain lead to your website when you enter it in your browser, you must use your registrar’s DNS settings to point the domain to your host’s nameservers.
How do domain servers work?
Nameservers are part of the process involved in translating domains into their loctable IP addresses. They store DNS records, particularly those very IP addresses that help us identify websites.
Let’s go over the process (called DNS resolution) the DNS goes through to return an IP address to your browser when you try to visit a website.
Let’s say you want to visit the Google Docs dashboard. You enter “docs.google.com” in your browser (or your browser does if you use a shortcut). Before the DNS can translate that domain for you, it needs to run your request through four primary servers in order to identify its IP address.
The first is the recursor server. This one is simple as its purpose is to simply handle your request. It’ll also send additional requests for you if need be.
Next is the root nameserver. Nameservers are containers for DNS records, including the A record that contains a domain’s IP address. We’ve established this already. We’ve also already established how the DNS is responsible for translating human-readable domains into machine-friendly IP addresses through a process called DNS resolution. The root nameserver initiates this process.
After your request moves through the root nameserver, it moves onto the TLD nameserver. At this point, the DNS is looking for your domain’s A record where the IP address is stored. It does this by locating the domain in the appropriate TLD nameserver based on the TLD attached to it. This is the .com TLD nameserver in the case of docs.google.com.
Once it locates your second and top level domains, it looks for a subdomain as this may have a different IP address depending on how its DNS settings are configured. This means its search will trickle down to docs.google.com in the .com TLD nameserver for Google Docs.
Once the DNS has found your record in the correct TLD nameserver, the authoritative server verifies the website’s identity via its IP address before returning it to the recursive resolver (from the original recursor server) so your browser can load the web page.
You enter addresses into your browser regularly. Your browser does it for you when you use search engines and shortcuts. Either way, the DNS went through multiple steps to find the website’s exact location on the web for you.From your perspective, you seen a web page load within a few seconds in your browser.
If you’ve already visited the website, the process is much shorter as the original recursive resolver will look through its cached information first to identify the website’s IP address rather than calling on the authoritative server.
DNS servers explained
The DNS recursor and authoritative servers often get confused with one another as they both return IP addresses to your browser. However, they’re quite different from one another. For instance, they’re used at different points in the DNS resolution process.
The confusion stems from the recursor server’s ability to resolve DNS queries on its own. Normally, the recursor server acts as a liaison between your request and the authoritative server where the IP address is stored. However, when you’ve already visited a website and have not cleared your cache, the recursor server is able to return the site’s IP address on its own by reviewing its own cached data.
Without that cached data, your query must travel down the DNS resolution pipeline like usual until it reaches the authoritative server. This server is the last step in the process as this server does not need to make additional requests. Its where DNS records are stored.
If no record is found, it will return an error message instead, and you won’t be able to load the website you’re trying to visit.
IP addresses are stored in different records within the authoritative server. You may have seen these records before if you’ve ever had to update DNS settings for your domain, such as when you want to connect an email client (like Google Workspace) to your domain.
These records are comprised of multiple text files written in “DNS syntax.” Different records have different syntax, and each one has different instructions for how the authoritative server should handle the information contained within each record when requests come through.
Here are the different types of records you’ll find attached to a domain and brief explanations for what they’re for:
- A – Stores a domain’s IP address.
- CNAME – Forwards an alias domain or subdomain to the actual domain it represents. CNAME records do not store IP addresses as they’re only used when the domains or subdomains stored within them are used as aliases for another domain. Alias domains do not have A records, so the authoritative server must forward requests to the A record of the domain the alias points to.
- MX – Points to an email server. This is the record DNS servers use when you want to use your domain to send emails from business email addresses, such as firstname.lastname@example.org as opposed to email@example.com.
- TXT – Used to store text notes from administrative purposes.
- NS – The record used to store nameservers. This is what you’ll use when you want to register a domain with a dedicated registrar rather than your host. You’ll need to create a different NS record for each nameserver your host uses. The record points your domain to your host’s nameservers so the website you’ve stored there loads when you enter the domain attached to the record in a web browser. Many NS records also have “TTL” settings you can configure. This stands for “time to live,” or the number of times routers are able to pass the record around until it expires. It represents the number of times the recursor server can return a cached IP address it has stored. When the record expires (runs out of TTL counts), the server must send its request down the DNS resolution tube once more to find a domain’s IP address. You’ll also find TTL settings when you set up CDN caching.
- SOA – Used to store admin information. TTL settings can be applied here as well. This record also contains information about admin email addresses and how long it’s been since the domain was updated.
There are other DNS records, but these are the most common ones you’ll find attributed to your domain.
The root nameserver is the first step in translating a domain name into its identifiable IP address. The recursor server sends its request here first. The root nameserver is responsible for passing that request onto the appropriate TLD nameserver.
There are 13 types of root nameservers the DNS uses, and they’re all managed by a nonprofit organization called the Internet Corporation for Assigned Names and Numbers (ICANN).
This organization controls all jurisdiction in regards to domains. It’s the organization that created the bylaw that requires you to attribute your personal information to every domain you register.
Every recursive resolver is familiar with each type of root nameserver, and the DNS uses multiple copies of each around the world.
Root nameservers are also responsible for applying Anycast routing to the traffic your domain receives when you use a CDN or registrar that supplies DDoS protection. Anycast is a network addressing method that routes traffic to multiple servers. This is as opposed to unicast routing, which sends traffic to a single server.
TLD nameservers store information on domains based on the TLD each domain uses. For example, “docs.google.com” is stored in the .com TLD nameserver.
Once the recursive resolver is sent to the correct TLD nameserver, it pinpoints the domain’s subdomain, if available, before the request is sent to the authoritative server.
TLD nameservers are also overseen by ICANN, only these nameservers are managed by a branch of the organization called the Internet Assigned Numbers Authority (IANA).
The IANA separates domains into two groups, gTLDs and ccTLDs, by combining gTLDs and sTLDs into one group.
A lot of technical information is attributed to the domain name system. Fortunately, you won’t need to remember most of it in order to register and maintain your own domain.
Still, you will need to update your domain’s nameservers if you don’t register it with your host.
You’ll also need to update the DNS records if you want to use a CDN or business email clients. This doesn’t require much more than knowing where to copy and paste the correct records, which most services make easy through descriptive support tutorials.
If you still need a domain, be sure to check out these guides: