DNS For Software Developers
DNS is an important topic for everyone who deploys software applications, it defines how users access web applications, how we can define multiple applications on the same domain on different paths and subdomains, and even how to access the same web application using multiple different domains.
In this article, we will dive through what a DNS is, how we access web applications using domains, and more.
What is a DNS?
When accessing a website or web application, you first open a brower tab, insert a URL such as google.com, and click on “Enter”. A few seconds later, the Google webpage shows up on the screen. How did that happen?
To understand what a DNS is, we need to go back to the beginning.
The way you could access websites was through an IP Address. Typically, a website administrator would buy a server, upload their website on it, and serve it on the Public IP Address of that server. So to access that website, you would have to type in the IP Address of that website on your browser, for example, going to 172.217.171.238 should take you to Google. This was a difficult task for humans, since you would need to remember each IP Address of each website you wish to access.
This lead to the creation of the Domain Name System, or DNS. The DNS was a system that translated human-readable and understandable name to an IP Address of a server. So instead of typing in the IP Address 172.217.171.238, you could simply type google.com and the website should load up!
Diving Deeper
We understood that websites are basically served on specific IP Address, and the DNS simply transforms a domain name such as google.com to its IP Address, which then takes us to the relevant website. There are a couple of things that happen here.
After you type in the URL of the website and press “Enter”. A request is made to the nearest DNS server to you. This DNS server will take the domain name you typed in, and find the relevant IP Address for it. You can imagine that the DNS server is basically a huge database of Domains that have a value of an IP Address. The DNS will take the domain name, search for that domain in the “database”, find the IP Address (assuming there is one), and returns the IP Address to the browser. The browser then takes that IP Address and requests it, which should return a response from the server with that public IP Address.
The sequence of events is as follows:
- You type in the URL in the browser
- A request is made to a DNS server on port 53
- A response is returned with an IP Address
- The browser requests the IP Address and caches it for later use
- The webpage of the URL you requested is displayed on the browser
DNS servers consist of different records which represent different types of information for a URL. We will go through that in the next section.
DNS Records
A URL typically has 1 or more DNS records which represent different types of data. We have A records, CNAME records, TXT records, and more. When opening a page on a browser, the DNS server will return the value stored in the A record (which is the IP Address). Think of DNS records as different objects under a domain name
While there are many types of DNS records, we will go through the record types that are most relevant for Software Developers and people responsible for deploying web applications.
While going through the records, we will use a command-line tool called dig to view some of the DNS record values for google.com. This tool can be found on Linux machines such as Debian or Ubuntu.
A & AAAA Records
An A Record is the simplest type of DNS record, it basically holds the value of the IP Address for the relevant domain.
When you open your browser and type in the URL of a website and the DNS is requested, it returns the value of the A record, which is the IP Address.
To see the A record of google.com, run the following command:
dig google.com A
This should return a long response, but what we care about is the “ANSWER SECTION”:
; <<>> DiG 9.10.6 <<>> google.com A
...
;; ANSWER SECTION:
google.com. 21 IN A 172.217.21.14
...
As you can see in the Answer Section shown above, we got the IP Address of the domain google.com through the A record.
An AAAA Record is the same as an A record, except that it is used for IPv6 addresses, instead of IPv4, which are the ones used in the A record.
To see the AAAA record of google.com, run the following command:
dig google.com AAAA
The Answer Section of the response should look like this:
;; ANSWER SECTION:
google.com. 266 IN AAAA 2a00:1450:4006:80f::200e
Now we know both the A and AAAA record values for google.com.
TXT Record
A TXT Record stores data that can be used for verification purposes. An example of this is some services require you to insert a specific value in a TXT of your domain to verify the ownership.
For example, when adding your website to Google Analytics or Google Search Console, you will be provided with a string value and asked to add it to a new TXT record on your websites domain. Once you add the TXT record, the Google service will make a request to the DNS server to check whether there is a TXT record with the value provided, this will verify that you own the website.
To view the TXT records of google.com, run the following command:
dig google.com TXT
The response will look like this:
;; ANSWER SECTION:
google.com. 3600 IN TXT "facebook-domain-verification=22rm551cu4k0ab0bxsw536tlds4h95"
google.com. 3600 IN TXT "google-site-verification=4ibFUgB-wXLQ_S7vsXVomSTVamuOXBiVAzpR5IZ87D0"
google.com. 3600 IN TXT "google-site-verification=wD8N7i1JTNTkezJ49swvWW48f8_9xveREV4oB-0Hf5o"
google.com. 3600 IN TXT "MS=E4A68B9AB2BB9670BCE15412F62916164C0B20BB"
google.com. 3600 IN TXT "docusign=1b0a6754-49b1-4db5-8540-d2c12664b289"
google.com. 3600 IN TXT "globalsign-smime-dv=CDYX+XFHUw2wml6/Gb8+59BsH31KzUr6c1l2BPvqKX8="
google.com. 3600 IN TXT "cisco-ci-domain-verification=479146de172eb01ddee38b1a455ab9e8bb51542ddd7f1fa298557dfa7b22d963"
google.com. 3600 IN TXT "docusign=05958488-4752-4ef2-95eb-aa7ba8a3bd0e"
google.com. 3600 IN TXT "onetrust-domain-verification=de01ed21f2fa4d8781cbc3ffb89cf4ef"
google.com. 3600 IN TXT "v=spf1 include:_spf.google.com ~all"
google.com. 3600 IN TXT "google-site-verification=TV9-DBe4R80X4v0M4U_bd_J9cpOJM0nikft0jAgjmsQ"
google.com. 3600 IN TXT "apple-domain-verification=30afIBcvSuDV2PLX"
As you might be able to see, these records include values for verification purposes (you can see the word verification in some of the values of the records).
Name Server Record
A Name Server Record, or NS, is a record that stores the URL of a DNS server that controls your domain records.
Say you deployed your website on a server that you got from a cloud provider, the server usually would have an IP Address that can be publicly accessed, so you set the A record value of your domain to the servers IP Address. You request the domain from a browser page and get your website!
But what happens when the server is rebooted for any reason? Most of the time, the Public IP Address of the server will change after the reboot. Now, when you try to open your website through the assigned domain name, you get no response!
This happened because the A record value is not matching with the new IP Address of the server.
Constantly updating the A record value everytime the server changes the IP Address is painful. That is why we have Name Server Records.
Name Servers, which can be found on Platform-as-a-Service websites such as Vercel or Netlify as well as some other cloud providers, will take control of your domain records.
You assign the Name Server record to the Platform-as-a-Service DNS domain, and anytime a new deployment is made or the IP Address of the deployment server is changed, the PaaS service will instantly update the DNS A record with the new IP Address.
To view the NS records of google.com, run the following command:
dig google.com NS
The Answer Section of the response should look like this:
;; ANSWER SECTION:
google.com. 77025 IN NS ns4.google.com.
google.com. 77025 IN NS ns2.google.com.
google.com. 77025 IN NS ns3.google.com.
google.com. 77025 IN NS ns1.google.com.
As we can see, there the values look like normal domains (except with the additional . at the end). These are the URLs of the Name Servers which “manage” the records of the domain google.com.
CNAME Record
A CNAME Record is a record that allows you to “forward” requests coming from one domain to the other.
Say you deployed your website on a cloud provider or a Platform-as-a-Service and instead of providing you with an IP Address of your deployed website, they provide you with a (usually long) domain or URL that looks something like this:
https://luxury-dolphin-013baa.netlify.app
This URL has an advantage over IP Addresses when viewing a website deployed on a cloud provider, which is that this domain does not change like in the case of IP Addresses. No matter how much times you redeploy the application or restart the server, this domain will remain the same.
While it is great that this domain is “persistent”, it is not a very convenient URL to type into the browser everytime you want to access the website, neither is it a good representation of the website you are hosting.
Now comes the benefit of having CNAME records. Instead of adding an IP Address to an A record, which might need frequest changing to keep the domain name of your website working, we simply add a CNAME record which has the URL provided by the cloud provider as the value. This will forward the requests coming from your domain name to the long URL we saw above, allowing users to use your website through your own domain name.
So now, instead of accessing your website through the long URL we saw above, you can access it through your own domain name.
Conclusion
Domain Name Systems are a great tool that allow us to customize how users can access our website, and make it easy for us to access any website we want without having to remember the IP Address of each website.
I hope this article was valuable and useful to you, and I hope to see you in the next one!