Domain Name System
The Internet has two major systems organizing it, domain names and internet protocol (IP) addresses. IP addresses are the meat and bones of how connections are made and how information will be transported, while domain names provide easy to remember names for these addresses. Although this example is getting dated rather quickly, this system acts like a phone book for the Internet: You could memorize your friend’s street address, or you could look up their name in a phone book, and find the address associated with them. The Domain Name System (DNS) does this same process, but for domain names and IP addresses.
The most common use of this will be navigating to a website in a web browser. Let’s say we want to visit www.google.com. The first thing your browser will do is check its cache for Google’s IP address. The cache should be keeping a record of recently visited sites, so that when you want to visit them again, it doesn’t need to ask around for them again. It saves time and bandwidth for everyone! But maybe you’re an avid fan of DuckDuckGo, and you haven’t used Google in a while, so the record for Google is missing. From there, your browser will need to go upstream to check another, presumably larger, DNS cache. If you’re in some company or organization, this will likely be that group’s own DNS server, which will be in charge of resolving DNS requests for everyone in the group, and should have a much larger cache of known IP addresses.
But let’s suspend our disbelief, and say no one in the company has been to Google’s homepage recently, and the record is missing from the DNS server’s cache too. This means the request will continue upstream, likely to the Internet Service Provider (ISP) for you or your group. There may be more steps in-between, and other caches being checked along the way, but the point is that this is a recursive search. Each entity is asking itself, “Do I know this address? If so, I’ll return it. If not, I should ask my parent.”
Worst-case scenario is that this search continues over and over until it reaches a root server. At this point, the search will change a bit. When the root server is asked for the address for www.google.com, it will provide directions to the .com top level domain (TLD) server, narrowing the search down to all websites ending with “.com”. Next, the .com TLD server will be asked, and it will provide directions to the google.com authoritative nameserver, which should be the final step in the search. At this point, we’d be directly asking Google themself what www.google.com’s IP address is, and something terribly wrong must be happening if they don’t know it. Google’s server will look for the “www” domain, and send this information back down the line to your browser.
On that trip back, all the DNS servers your request went through will make a record of this address, so the next time someone requests it, the request won’t need to reach all the way to Google. And now that your browser has the IP address it needs, it can start sending HTTP requests out and retrieve the Google homepage.
References:
Linus is the best, so he gets to be at the top of references.
The very nice diagram I used as the article thumbnail.
Lots of good definitions, but I feel the flow and layout of the article are a little rough.
https://www.cloudflare.com/learning/dns/what-is-dns/
Cute animation on the topic.
