An Overview of DNS – CompTIA Network+ N10-007 – 1.8

Domain Name Services provide an important conversion between FQDN and IP address. In this video, you’ll learn about the process that DNS uses to resolve a fully-qualified domain name to an IP address.

<< Previous Video: Cloud Services and Delivery Models Next: DNS Record Types >>

Many people don’t realize just how much we take advantage of the domain name system, or DNS. Anytime you’re converting from a human readable name like and accessing a website, there has to be some conversion to IP addresses. And it’s the domain name system that provides that conversion process. DNS is a hierarchical system which follows a very specific path to be able to find exactly the server you’re trying to locate. And it’s a database that’s very distributed.

There are many DNS servers around the world. There are over 13 clusters of root servers at the core of DNS, and you often find generic top-level domains like a .com, a .org, or a .net. And there are also country code top-level domains for the US, Canada, UK, and other countries.

Here’s an example of the hierarchy that’s used with the DNS. We very often will see a .com address or a .net, and that’s the top-level domain of this hierarchy. Underneath .com, you might have another domain name such as professormesser. So you can put together

Of course, at professormesser there may be a web server and that web server’s name may be www. But there may also be a, an, and a And you can have servers that were one level down from that. So there may be an and so on.

Visually, you can see how this domain name might work. You have a fully qualified domain name that encompasses everything within And within there, there may be the web server for We may break out these domains even further to have a and an And there may be servers that exist in these different regions, and we can specify their fully qualified domain name as and

We mention that DNS is a very distributed database and to be able to find all of those different services that are located as those fully qualified domain names, we may need to ask a number of servers before we’re able to fully resolve their IP addresses. Let’s start with my laptop. We refer to this device as a resolver. This is a device that will, for instance, be trying to find the IP address that might be associated with the

This device is configured for a local name server that it will reference. This might be a local server that’s within your organization or it might be a third-party name server that you’re using. This resolver will query that name server to ask where is the IP address for The first request will be made from the resolver to the local name server asking if this particular device knows where happens to be.

This local name server does not have this IP address in its cache, so it needs to start asking other name servers where it can go to find the IP address. Its first step is going to be talking to this root server. The root server is going to respond back and say if you’re looking for anything with a .com, you need to go to the .com name server.

So the next step will be the local name server will talk to the .com DNS server. And this server will have a list of where my local DNS server is for, and it will provide that information to the local name server. The local name server will then query the name server, which obviously will have the IP address associated with and that information is provided to the local name server.

At this point, the local name server will let the resolver know what that IP address happens to be, and it will store that information in a cache. If anyone else that uses this local name server then needs to access, they can get that information from the local cache rather than going through all of these queries all over again.

Many organizations will maintain an internal DNS. That’s because there are internal servers that you need to have some type of reference to that you may not want to make public on an external DNS server. These internal DNSs are usually installed and maintained by your local network team, and it usually is going to have your internal information that no one else should have access to. It’s very common, for example, to run a DNS service on a Windows Server so that you’re able to keep up with all of the different Windows devices on your internal private network.

If you’re an organization that doesn’t need an internal DNS server, you might want to use an external DNS. A good example are the ones that are managed by Google on their Google DNS or Quad9. These external DNSs will obviously not have any information about any internal devices, but you’re able to use and maintain those external resources without having to run your own server internally in your organization.

There’s also a middle ground where you can have a third party providing you with your own internal DNS services. Especially if you’re in a very large environment, you may be having to manage many, many different DNS servers. And instead of you managing that, you might want to hand that off to a third party where you’ve outsourced your internal DNS function to this third party. All of these DNS servers are running in the cloud.

You might have multiple instances of them available around the world, and it would still provide you with the same internal functionality except you’re using a cloud-based service external to your organization. This also might provide you with some capabilities you normally wouldn’t have if you were maintaining your own servers. You may have high availability to have these DNS services available all the time. They may be low latency servers providing very fast response time. And if you need additional servers spun up, you simply request that from the third-party DNS and you’re able to scale up and scale down as needed.