【My Study Note】The Many Steps of Name Resolution
The Many Steps of Name Resolution
At its most basic, DNS is a system that converts domain names into IP addresses.
It’s the way humans are likely to remember and categorize things resolved into the way computers prefer to think of things. This process of using DNS to turn a domain name into an IP address is known as name resolution.
How does Name Resolution work?
The first thing that’s important to know is that DNS servers, are one of the things that need to be specifically configured at a node on a network.
At first, MAC addresses are hard-coded and tied to specific pieces of hardware.
Additionally, the IP address, subnet mask, gateway for a host, and DNS server must be specifically configured. These are almost always the four things that must be configured for a host to operate on a network in an expected way.
I should call out, that a computer can operate just fine without DNS or without a DNS server being configured, but this makes things difficult for any human that might be using that computer.
Five primary types of DNS servers
- Caching name servers
- Recursive name servers
- Root name servers
- TLD name servers
- Authoritative name servers
Caching and Recursive Name Servers
Caching and recursive name servers are generally provided by an ISP or your local network.
Their purpose is to store domain name lookups for a certain amount of time.
There are lots of steps in order to perform a fully qualified resolution of a domain name. In order to prevent this from happening every single time when a new TCP connection is established, your ISP or local network will generally have a caching name server available.
Most caching name servers are also recursive name servers. Recursive name servers are ones that perform full DNS resolution requests.
In most cases, your local name server will perform the duties of both, but it’s definitely possible for a name server to be either just caching or just recursive.
Example
You and your friend are both connected to the same network and you both want to check out Facebook.com, your friend enters www.facebook.com into a web browser, which means that their computer now needs to know the IP of www.facebook.com in order to establish a connection.
Both of your computers are on the same network which usually means, that they have both been configured with the same name server.
So your friends’ computer asks the name server for the IP of www.facebook.com which it doesn’t know, this name server now performs a fully recursive resolution to discover the correct IP for www.facebook.com.
This involves a bunch of steps we’ll talk about in a moment.
This IP is then both delivered to your friend’s computer and stored locally in a cache.
A few minutes later you enter www.facebook.com into a web browser. Again, your computer needs to know the IP for this domain, so your computer asks the local name server it’s been configured with, which is the same one your friend’s computer was just talking to.
Since the domain name www.Facebook.com had just been looked up, the local name server still has the IP that it resolved to stored and is able to deliver that back to your computer without having to perform a full lookup.
This is how the same servers act as caching servers.
TTL (Time To Live)
All domain names in the global DNS system have a TTL (Time To Live).
This is a value in seconds, that can be configured by the owner of a domain name for how long a name server is allowed to cache in entry before it should discard it and perform a full resolution again.
Several years ago, it was normal for these TTLs to be really long, sometimes a full day or more. This is because the general bandwidth available on the Internet was just much less, so network administrators didn’t want to waste what bandwidth was available to them by constantly performing full DNS lookups.
As the Internet has grown and gone faster, these TTLs for most domains have dropped to anywhere from a few minutes to a few hours. But it’s important to know that sometimes you still run into domain names with very lengthy TTLs, it means that it can take up to the length of a total TTL for a change in DNS record to be known to the entire Internet.
Full Recursive Resolution
Now, let’s look at what happens when your local recursive server needs to perform a full recursive resolution.
The first step is always to contact a root name server, there are 13 total root name servers and they’re responsible for directing queries toward the appropriate TLD name server.
In the past, these 13 root servers were distributed to very specific geographic regions, but today, they’re mostly distributed across the globe via anycast.
Anycast
Anycast is a technique that’s used to route traffic to different destinations depending on factors like location, congestion, or link health.
Using anycast, a computer can send a datagram to a specific IP but could see it routed to one of many different actual destinations depending on a few factors.
This should also make it clear that there aren’t really only 13 physical route name servers anymore. It’s better to think of them as 13 authorities that provide route name lookups as a service.
TLD name server
The root servers will respond to a DNS lookup with the TLD (Top Level Domain) name server that should be queried. TLD represents the top of the hierarchical DNS name resolution system.
A TLD is the last part of any domain name, using www.facebook.com as an example again, the “.com” portion should be thought of as the TLD.
For each TLD in existence, there is a TLD name server, but just like with root servers, this doesn’t mean there’s only physically one server in question, it’s most likely a global distribution of any cast accessible servers responsible for each TLD.
The TLD name servers will respond again with a redirect, this time informing the computer performing the name lookup with what authoritative name server to contact.
Authoritative name servers
Authoritative name servers are responsible for the last two parts of any domain name which is the resolution at which a single organization may be responsible for DNS lookups.
Using www.weather.com as an example, the TLD name server would point a lookup at the authoritative server for Weather.com, which would likely be controlled by the Weather Channel, the organization itself that runs the site.
Finally, the DNS lookup could be redirected at the authoritative server for weather.com which would finally provide the actual IP of the server in question.
This strict hierarchy is very important to the stability of the internet, making sure that all full DNS resolutions go through a strictly regulated and controlled series of lookups to get the correct responses, is the best way to protect against malicious parties redirecting traffic.
Your computer will blindly send traffic to whatever IP it’s told to. So by using a hierarchical system controlled by trusted entities in the way DNS does, we can better ensure that the responses to DNS lookups are accurate.
Now that you see how many steps are involved, it should make sense why we trust our local name servers to cache DNS lookups, its so that full lookup path doesn’t have to happen for every single TCP connection.
In fact, your local computer from your phone to a desktop will generally have its own temporary DNS cache as well, that way, it doesn’t have to bother its local name server for every TCP connection either.