An Overview of DNS – CompTIA Network+ N10-006 – 1.3


The Domain Name System is one of the most important applications on the Internet. In this video, you’ll learn about DNS and the process it uses to resolve fully qualified domain names.

<< Previous: DHCP OptionsNext: DNS Records >>


Our networks would be so much more difficult to use if we did not have the Domain Name System. The Domain Name System or DNS is designed to take these names that we commonly associate with a server like ProfessorMesser.com, or Google.com, and Yahoo.com, and convert them into an IP address that your computer can use to communicate with that server across the network. This way we don’t have to remember what all of those IP addresses are. I don’t even remember what the IP address is for ProfessorMesser.com because I simply reference my DNS whenever I need to access my server. The domain name system is hierarchical. That means that there is a top layer, and you move down through the layers from there, and when we look at a diagram of how the domain name system is laid out and the way that we resolve a name it will become very clear how this hierarchy works.

The domain name system is a very, very, very distributed database with servers that are located all over the world. There are 13 root server clusters these 13 root servers are the jumping off point that can help you find any other domain name in the world. There are hundreds of generic top level domains gTLDs, as we call them. The most familiar, of course are .com, and .net, but there are hundreds and hundreds of others you can choose from. There over 275 country code top-level domains. Things like .us, for the United States, .ca, for Canada, .uk, UK for the United Kingdom and many others, as well.

Here’s a diagram that shows top level domains, like the .com, and the .nets there right here at the top. The very top is the root, and then we work down from there. So you can see under .com, for instance, is a ProfessorMesser domain for ProfessorMesser.com, and on my site, I might have a www server for the web server you might be on. I might have a mail.ProfessorMesser.com. There might be an east and a west side, and you can keep breaking things out. For instance, there could be and Ethan server that’s in the west under ProfessorMesser.com, and that would be ethan.west.ProfessorMesser.com and you can even keep going with this hierarchy. No matter how you design it, this structure is used for every domain that you’ll find.

When we piece together all of those different components of the domain name we have something called a fully qualified domain name or at QDN. This is the entire name all put together. For instance under the ProfessorMesser.com domain I do have a www.ProfessorMesser.com, and if you recall, I also had an east, and a west, and I had different devices that were in the east side and the west side of the domain. You can see ethan.west.ProfessorMesser.com Is the fully qualified domain name for that server that is located in the west, that happens to be called ethan. My ProfessorMesser server simply www.ProfessorMesser.com, so that’s the fully qualified domain name.

So if you’re working on a device and configuring it, it asks you for the FQDN of the device. It’s asking you for more than just the name of the server. It’s asking you to list out the entire hierarchy of that particular device. In our example, we’re going to look for the www.ProfessorMesser.com server, I need the IP address of that device, so that I can access it. And we will, of course, be talking to one of the 13 root servers that’s on the internet. That will take us to the .com name server. And of course, there are other name servers not listed here for .net and .org, and all of those others. And of course, I have a name server that handles all of my local IP addresses that I configure, so that ultimately, we’re going to talk to that server to find out, really, what is the IP address of my web server.

Let’s start with the resolver. I’ll go to a browser, I’ll type in wwwProfessorMesser.com, and the first thing the resolver does is ask my local name server if it happens to have that information already in a cache. If it does, we can answer directly back to the resolver instead of going through the process here. But for illustration purposes, let’s assume that that particular domain, and that server name is not cached on the local name server. So the local name server sees that I’m looking for www.ProfessorMesser.com. First thing it needs to do is talk to a root server and determine, where are the .com servers that give me more information about ProfessorMesser.com, and the root server talks back to the local name server for that information. Notice that the root server isn’t talking all the way back to the station quite yet. All of the work is really being handled by the local name server.

Now that the local name server knows where the .com server is, it repeats the process to the .com server and asks, how do I get to ProfessorMesser.com? The .com name server says, oh, James has set up a DNS server just for his local purposes, here’s the information you need to find that particular name server. Now that your local name server knows how to get to my name server, it communicates directly to the ProfessorMesser.com name server. I now, of course, provide the information, the IP address of my web server back to the local name server, and the local name server tells your workstation, here is how do you get to ProfessorMesser.com through this particular IP address.

At this point, we’ve gone through a lot of work just to figure out where all of these different servers are, and what the IP address ultimately is of ProfessorMesser.com. So all of this content is cached. There is a local DNS cache on the resolver, there’s a cache on the local name server, and elsewhere on these domain name servers, as well. That way if we are asked again, very quickly, by someone else on the network, where is ProfessorMesser.com, we don’t have to go through this process again. We can simply have the local name server respond back to the resolver, and as you’ll see in the next video, we’ll talk about those timers, and how often information is clear it out of those caches. Hopefully, this is giving you an idea about how DNS is working behind the scenes. You can see it’s a very flexible system, and allows us to find all of those IP addresses of the servers that we need to access wherever they might be located in the world.