Most computer engineers come across this term, and most of them study the concept of DNS. But do you understand it fully? I am sure this article; will help you know how DNS works in an easy language. Let’s start with the basic introduction and other concepts around it.
The full form of the DNS is a domain name server. It is regarded as the Internet phone directory. Comparing the analogy with the standard phone directory, which has a name and associated phone number, DNS contains the website name (domain name) and its associated IP address. In short, it translates a human-readable address, say microsoft.com, to a machine-readable IP address (example 184.108.40.206) because the machine does not understand microsoft.com; it can only understand the IP address.
Let’s try to understand some basic concepts associated with DNS.
- IP Address: Any device (Mobile, Laptop, etc.) attached to a Network or Internet has a unique address known as an IP address. It is used to communicate with other devices on the Network or the Internet.
- Static IP Address: Static IP addresses don’t change over time. Once a device is assigned a static IP address, it will remain the same until decommissioned. These are assigned by the ISP (internet service provider).
- Dynamic IP Address: Dynamic IP addresses are those IP addresses that change over time. For example, we have dynamic IP addresses assigned to our home devices, say Laptop, Mobile, etc.; when connected to home wifi, it changes when you restart your modem or device.
- Domain Name: It’s a human-friendly name like Microsoft, bound to an IP address.
- DNS Record: A domain name and its associated IP address. We will talk about this in detail afterwards.
- Domain types: They are divided into multiple levels starting with . (dot) or commonly referred to as Root domain, as shown in the diagram below.
- FQDN: It stands for a Fully qualified domain name and uses the domain hierarchies explained above. It utilizes all the labels from the bottom to the top as mentioned in the order, for example, azure.microsoft.com. , wikipedia.org, etc.
- FQDN ends with . (dot) but our browsers are advanced, and hence we can omit this root domain.
- FQDN also contains a subdomain like www, which explains that the site is part of the web. Many websites do not have this subdomain in today’s world, for example, facebook.com, so it’s not mandatory in an FQDN to include a subdomain.
I know there is too much to understand here, but don’t worry; everything will be evident in a while.
This is only a brief introduction, but we will deep dive into DNS in a short while. Before that, I want to explain the article title Why I have named it as Heart of the Internet, and the answer is simple as a human being cannot live without a heart similarly imagine if DNS is not there, then we have to type the IP address of every website we want to access. In such a case, every person needs to create a directory of the IP address of the websites they often visit. Let me make this a little more complicated if the website’s IP is not static, then a person would be updating their directory every day.
Some more basic terminologies:
- Zone: It is part of a DNS database delegated to a person, company or organization, for example, Verisign.
- Zonefile: It’s a physical database for a zone.
- Nameserver: It can be seen as a place where zone files are hosted.
- Root hint file: The root hints file contains the list of the root servers and has a pointer to DNS root servers.
- Root Server: Hosts the DNS root zone.
- Root Zone: Points to the TLD authoritative server.
DNS root or DNS root zone occupies the topmost part of DNS, and like any other part of DNS, it’s just a database. The DNS root is hosted on 13 special name servers known as root servers, and 12 different large organizations operate the root servers. (https://www.iana.org/domains/root/servers). These organizations only manage the root servers themselves, not the root zone database.
Internet assigned numbers authority (IANA) manages the root zone, so we can say that IANA is in charge of the DNS system as they control the root zone.
When something is trusted in DNS, known as authoritative, the root zone can delegate part of itself to another entity or another zone, which becomes authoritative for just the delegated part. The delegate management to other organizations is known as registries. How delegation works is in the record of (say) .com zone file (https://www.iana.org/domains/root/db/com.html) there are set of name server entries that point at other DNS names servers. This is how the root zone delegates part of itself to other registries. These name serves listed here become authoritative for the .com, so they are trusted.
So here, inside the root zone, there are name servers for .com, which point at another server. Verisign manages the server, and Verisign hosts the .com zone. At this point, the root zone trusts it; the .com zone is now authoritative for root, and it has been delegated that trust from the root zone. This process continues until the domain zone, where all the DNS records are present for a domain.
Note: Top level domains are of two types: country-codeTLDs (ccTLDs) or generic TLDs (gTLDs) example .io, .in are ccTLDs whereas .org, .com is gTLDs. This link (https://www.iana.org/domains/root/db) contains all the TLDs
As DNS is a vast service, it cannot work alone. Hence it uses multiple servers/services at its disposal, explained below.
- DNS Recursive Resolver: Also known as DNS recursor, It acts as an interface between the client and the server. It accepts the request from the user and then passes the information to the Root name server. It receives a response and passes that to the TLD server, receives a response and passes that to the Authoritative server, receives a response then responds to the client. It can also cache the request so the next time a client request the same website, the DNS recursor doesn’t have to go through all the above steps.
- Root Name Server: As explained earlier, the DNS is structured in the hierarchy, and the topmost level is the root. They can only respond to the records stored at their level. Also, they delegate the request to the next level, i.e. TLD (Top Level Domain) servers.
- TLD Server: This is the second step, and it responds to the records stored at its level. Various Top Level Domains are .com, .org, .net, .in, .ai, .io, etc. These contain the site’s information when a domain is registered.
- Authoritative Server: This is usually the last step in the journey. Once it receives a response from TLD via DNS recursor, it provides the DNS records to the DNS recursive resolver. It contains all the DNS records of the Microsoft domain like A Record, CNAME Record, NS Record etc.
Relating all this to a simple life analogy, Let’s say a customer went to Walmart to buy a Nestle Milk. Now Walmart is a big shop, and customers cannot find it. He asks for help (can be related to DNS recursor), the helper first finds where the diary section is from various sections (searching for the dairy section can be related to Root Name server as it guides where to go next). In the dairy section, there would be various racks containing multiple dairy products like butter, cheese, etc. (here searching for the milk rack among multiple dairy products can be related to TLD server), from the rack, the helper gets the Nestle Milk for the customer (can be related to Authoritative server). Hence the customer gets the Nestle Milk (final response).
I believe the above example helped you a little bit, but let’s talk in technical terms about how it happens with DNS with the help of the below diagram.
- Say you want to browse the ´www.microsoft.com´ website, So you type in the address of the Microsoft website and hit enter. Since the Microsoft.com website server is not located on your network, the result will go to the default gateway and from there to ISP, which acts as DNS recursive resolver.
- The DNS recursive resolver uses its root hints file and communicates with DNS root servers.
- Since root servers don’t have actual DNS records, they can help the resolver get closer and provide the .com servers because they have name server records for the .com authoritative servers because they have delegated to .com.
- The resolver asks for ´www.microsoft.com´ record information.
- Since the server is only .com, it doesn’t have any information on ´www.microsoft.com´, but it does have the name server that is authoritative for microsoft.com because it had delegated that right when the domain was registered.
- The resolver asks for ´www.microsoft.com´ record information; this time, the server is authoritative for zone microsoft.com is where the record resides.
- So it responds with the IP address for ´www.microsoft.com´.
- The resolver gets this response and forwards it back to the client. The client then communicated with the ´www.microsoft.com´ web server.
Because of all these steps, we are able to open any website on our browsers.
There are three more concepts that I would like to share with you.
These are various types of instructions found in the authoritative DNS server and provide information about a domain. There are multiple types of records but is not limited to the below records.
- A Record: This is the most important record, and it holds the IP or IPv4 address of a domain.
- AAAA Record: This is similar to an A record, but it contains the IPv6 address.
- CNAME Record: It maps the queries for one domain/subdomain to another domain or subdomain. It does not provide an IP address.
- MX Record: It directs the email to an email server.
- TXT Record: It helps an admin to add arbitrary text to a domain. One common use case is to prove domain ownership.
- NS Record: It identifies the name servers for the hosted zone.
- SOA Record: It stands for Start of Authority, and it stores all the essential information about a domain/zone.
DNS lookup is a tool/service that helps find all the DNS records for a given domain.
I recommend using MXToolbox website for DNS lookup.
Caching is the temporary storage of information about the DNS lookups.
There is one important field when creating a DNS record, and it’s called Time To Live or commonly referred to as TTL. The DNS results are cached at the DNS resolver for the time defined by the TTL value.
In our earlier example of ´www.microsoft.com´. The TTL value set is 60 mins meaning the IP address for the ´www.microsoft.com´ will be cached at the resolver for 60 mins. Any client that queries ´www.microsoft.com´ will get the resolver’s immediate and authoritative answer. After 60 minutes, the resolver has to go through all the processes again to get the IP along with the TTL value and then cache it.
Phew, it was a long article. I hope you enjoyed reading this and learnt something new.
When I first learned about DNS service, I was fascinated that so much goes into the background. So thought of sharing the concept with all of you in easy language, I know you must be having hundreds of questions after reading this, but I hope I was able to provide you with a starting point for DNS discussion with your friends. And with that said, this article comes to an end.
If you found this post useful or have any recommendations, feel free to post a response here.