It is surprising how many developers have only a very limited or even no understanding of how the DNS process actually works. So it may be useful to give a quick, high-level overview of the process that is followed when a DNS resolution request is made.
At the simplest level, all the DNS system does is convert a DNS name into an IP address; however, as you’d expect there is a large degree of complexity behind the system.
Every domain that is registered creates a DNS record, usually hosted by the company that registers the domain; however, once registered, the domain name can be transferred to be hosted elsewhere. This is simply a text record that stores details about what information should be given to anyone requesting details about this domain name. This includes web-based resolution details as well as other information such as where mail servers should connect to (MX records).
In reality there are variations and optimizations of the system to improve reliability and efficiency, but the essentials of the process are as follows.
When you type an address into a web browser:
- A check is made to see if the details of that name are known locally, e.g., if the browser has made a previous request from that same domain name or there is an entry in the local DNS registry (e.g., hosts.txt on Windows).
- If no local record is found, a request is sent to your local DNS server. This could be running locally on your machine or on an office network, but most commonly it is provided by the ISP that supplies your internet connection.
- The local DNS server again checks if it already has the details of the name being requested. If there is no cached record, then the DNS server needs to locate the details of the name server that hosts the domain record for the address you are trying to resolve (the authoritative domain name server).
- To do this the DNS server breaks the name down into its different sections, starting from the righthand side of the domain name. For example, for www.google.com, this would be split into com, google, and www. The section after the final . of the domain name (in this case, com) is known as the top-level domain (TLD). A root name server is connected to find details of the server that holds the domain record for the TLD.
- The DNS server will make a request to the TLD name servers asking for details of the name servers that contain the details of the next section of the domain name (in this example, google). The DNS server then makes a request to the name server that holds the details for google.com. This name server may then return details of another name server that holds the records for www.google.com or, more likely at this point, will return the address associated with www.google.com.
- The address returned by the remote name server can be an IP address or it could be another domain name, known as a CNAME; for example, www.google.com may return a reference to cdn-us.aa1.google-us.com.
- If a CNAME is returned, the DNS server then repeats the process with the CNAME until an IP address is resolved.
An example of a recursive DNS process is shown below.
All domain name resolution information is publicly available. Using the NSLookup tool that is available on the command line of most computers, you can directly query the DNS system and find all the details of any DNS registration. NSLookup allows you to query using your default DNS server and also by specifying a different DNS server (e.g., Google’s public DNS server 184.108.40.206) to validate that your local DNS is returning the same details as other people are seeing.
There are also a number of websites that will complete an NSLookup request for you.
For more, check out our eBook DevOps & DNS: Improving Web Application Performance at the DNS Layer