The DNS is used to assign names to computers and systems connected to the internet. Similar to how a phone book can be used to link a phone number to a name, the DNS allows us to link a hostname to an IP address.
When your program needs to connect to a remote computer, such as www.example.com, it first needs to find the IP address for www.example.com. In this book so far, we have been using the built-in getaddrinfo() function for this purpose. When you call getaddrinfo(), your operating system goes through a number of steps to resolve the domain name.
First, your operating system checks whether it already knows the IP address for www.example.com. If you have used that hostname recently, the OS is allowed to remember it in a local cache for a time. This time is referred to as time-to-live (TTL) and is set by the DNS server responsible for the hostname.
If the hostname is not found in the local cache, then your operating system will need to query a DNS server. This DNS server is usually provided by your Internet Service Provider (ISP), but there are also many publicly-available DNS servers. When the DNS server receives a query, it also checks its local cache. This is useful because numerous systems may be relying on one DNS server. If a DNS server receives 1,000 requests for gmail.com in one minute, it only needs to resolve the hostname the first time. For the other 999 requests, it can simply return the memorized answer from its local cache.
If the DNS server doesn't have the requested DNS record in its cache, then it needs to query other DNS servers until it connects directly to the DNS server responsible for the target system. Here's an example query resolution broken down step-wise:
Client A's DNS server is trying to resolve www.example.com as follows:
- It first connects to a root DNS server and asks for www.example.com.
- The root DNS server directs it to ask the .com server.
- Our client's DNS server then connects to the server responsible for .com and asks for www.example.com.
- The .com DNS server gives our server the address of another server – the example.com DNS server.
- Our DNS server finally connects to that server and asks about the record for www.example.com.
- The example.com server then shares the address of www.example.com.
- Our client's DNS server relays it back to our client.
The following diagram illustrates this visually:
In this example, you can see that resolving www.example.com involved sending eight messages. It's possible that the lookup could have taken even longer. This is why it's imperative for DNS servers to implement caching. Let's assume that Client B tries the same query shortly after Client A; it's likely that the DNS server would have that value cached:
Of course, if a program on Client A wants to resolve www.example.com again, it's likely that it won't have to contact the DNS server at all – the operating system running on Client A should have cached the result.
On Windows, you can show your local DNS cache with the following command:
ipconfig /displaydns
On Linux or macOS, the command to show your local DNS varies depending on your exact system setup.
One downside of setting a large TTL value for a domain record is that you have to wait at least that long to be sure that all clients are using the new record and not just retrieving the old cached record.
In addition to DNS records that link a hostname to an IP address, there are other DNS record types for various purposes. We'll review some of these in the next section.