This cloudfare article defines the DNS as "a phonebook of the Internet". Before the DNS the internet kind of worked like those old rotary telephones (Yes, I am old enough to have seen one in use).
Photo by R.D. Smith on Unsplash
To call someone, you had to remember what their number was, and before the DNS, to connect to websites you had to remember what their IP addresses were. As you can probably guess, this was a lot of work, hence the creation of the DNS.
How Does it Work?
When you type a website like example.com into a browser, the computer doesn't know where that points to in the internet immediately. For that to happen the system has to go through a chain of four DNS servers.
DNS Recursor
The DNS recursor acts as a librarian at a help desk, the librarian knows where to look even though they might not know about the location of every book in the library. Just like a librarian the recursor takes your query and starts the process of looking for the IP address by making additional requests to the subsequent servers.
Root Nameserver
The root nameserver works the same way as the catalog system would in a library. It points you to the right "shelf" based on the type of domain. (.com, .me, .dev).
TLD Nameserver
This is the "shelf" where the IP addresses under the top-level-domains (.com, .me, .dev) live. It doesn't give you the IP address yet but it gives you a bunch of "books" that may contain the IP address you are looking for.
Authoritative Nameserver
The authoritative nameserver is "the book". This is where the exact IP address is found.
Photo by Denny Bú on Unsplash
So the process goes as follows:
Client - "Where is example.com?"
Recursor - "Wait let me ask Root..."
Recursor - "Root where are the .com domains kept?"
Root - "Over there that section is for the .com domains", says root pointing at a section in the endless void of cyberspace.
Recursor - Moves over to where Root was pointing and meets TLD, "TLD where is example.com?"
TLD - "I know who is in charge of that, it is over there with Auth... you can ask him for more specifics"
Recursor - "Hey Auth, can you give me the IP address for example.com ?"
Authoritative - "Here you go: 93.184.***.**. Don’t ask again for a while, okay? Caching is your friend."
Recursor - Returns IP address to Client.
Client 2 - "Where is example.com ?"
Recursor - "I am pretty sure I saved that for future references....Aha! here it is 93.184.***.** "
Query Types
Most DNS queries made by end-user devices are of recursive type. However, there are two more types that aren't as common when it comes to facing end-users. These are the Iterative and Non-Recursive types.
A recursive query happens when a client tells the DNS resolver to only get back to the client once it has located the IP address. It is like asking a librarian to find a book for you and the librarian runs around the entire library system, going to other libraries if necessary, and only comes back once they’ve found it or confirmed it doesn’t exist.
The iterative query is mostly used between DNS servers. In such a situation the goal here is to get the best possible answer, even if that means it isn't the final answer. This means the client (usually another DNS server such as the recursor) keeps on asking down the line until it finds the answer or an error.
Finally in a non-recursive query the question requires a yes/no answer. There are no extra lookups, if the client asks the server provides. This query type is used to save time and bandwidth, especially in a situation where the resolver already has the answer cached.
Caching (read : cashing - because spelling things phonetically is too easy.)
If you are a developer you have probably heard this term everywhere. Simply it just means storing some data temporarily so that data requests are faster and more reliable. Using DNS caching eliminates the need to ask multiple DNS servers where the location of an IP address is.
Where does DNS caching happen? The simplest and closest to the user is when DNS records are cached temporarily in the browser. In chrome you can checkout the DNS cache at chrome://net-internals/#dns.
The other place DNS caching happens is in the OS. An OS has a mini DNS system called a stub resolver. This is the last place your device checks before sending a query to a recursive DNS resolver. Finally DNS caching can happen at the recursive DNS resolver. Here the resolver can cache information such as; A records ( which are IP addresses ), NS records, CNAMEs, etc...
One final thing I learned here is that TTL is how long a DNS record has before it expires and is removed from the cache. I always wondered what that was but never looked it up.
Cover Photo by Ecliptic Graphic on Unsplash
