The Domain Name System (DNS) is a service that allows you to resolve a hostname to an Internet Protocol (IP) address. One of the inherent complexities of operating in networked environments is working with multiple protocols and network addresses. Owing largely to the tremendous rise in the popularity of the Internet, however, most environments have transitioned to use Transmission Control Protocol/Internet Protocol (TCP/IP) as their primary networking protocol. Microsoft is no exception when it comes to supporting TCP/IP in its workstation and server products. All current versions of Microsoft’s operating systems support TCP/IP, as do most other modern operating systems.
An easy way to understand DNS is to think about making a telephone call. If you wanted to call Microsoft and did not know the phone number, you could call information, tell the operator the name (Microsoft), and get the telephone number. You would then make the call. Now think about trying to connect to Server1. You don’t know the TCP/IP number (the computer’s telephone number), so your computer asks DNS (information) for the number of Server1. DNS returns the number, and your system makes the connection (call). DNS is your network’s 411, or information, and it returns the TCP/IP data for your network.
TCP/IP is actually a collection of different technologies (protocols and services) that allow computers to function together on a single, large, and heterogeneous network. Some of the major advantages of this protocol are widespread support for hardware, software, and network devices; reliance on a system of standards; and scalability. TCP handles tasks such as sequenced acknowledgments. IP involves many jobs, such as logical subnet assignment and routing.
Hosts File
Nowadays, most computer users are quite familiar with navigating to DNS- based resources, such as WillPanek.com. To resolve these “friendly” names to TCP/IP addresses that the network stack can use, you need a method for mapping them. Originally, ASCII flat files (often called HOSTS files, as shown in Figure 5.1) were used for this purpose. In some cases, they are still used today in small networks, and they can be valuable in helping to troubleshoot name resolution problems.

As the number of machines and network devices grew, it became unwieldy for administrators to manage all of the manual updates required to enter new mappings to a master HOSTS file and distribute it. Clearly, a better system was needed.
As you can see from the sample HOSTS file in Figure 5.1, you can conduct a quick test of the email server’s name resolution as follows:
- Open the HOSTS file: C:\Windows\Systems32\drivers\etc.
- Add the IP- address- to- hostname mapping.
- Try to ping the server using the hostname to verify that you can reach it using an easy- to- remember name.
Following these steps should drive home the concept of DNS for you because you can see it working to make your life easier. Now you don’t have to remember 10.0.0.10; you only need to remember exchange03. However, you can also see how this method can become unwieldy if you have many hosts that want to use easy- to- remember names instead of IP addresses to locate resources on your network.
When dealing with large networks, users and network administrators must be able to locate the resources they require with minimal searching. Users don’t care about the actual physical or logical network address of the machine; they just want to be able to connect to it using a simple name that they can remember.
From a network administrator’s standpoint, however, each machine must have its own logical address that makes it part of the network on which it resides. Therefore, some scalable and easy- to- manage method for resolving a machine’s logical name to an IP address and then to a domain name is required. DNS was created just for this purpose.
DNS is a hierarchically distributed database. In other words, its layers are arranged in a definite order, and its data is distributed across a wide range of machines, each of which can exert control over a portion of the database. DNS is a standard set of protocols that defines the following:
■ A mechanism for querying and updating address information in the database
■ A mechanism for replicating the information in the database among servers
■ A schema of the database
DNS was originally developed in the early days of the Internet (called ARPAnet at the time) when it was a small network created by the Department of Defense for research purposes. Before DNS, computer names, or hostnames, were manually entered into a HOSTS file located on a centrally administered server. Each site that needed to resolve hostnames outside of its organization had to download this file. As the number of computers on the Internet grew, so did the size of this HOSTS file—a nd along with it the problems of its management. The need for a new system that would offer features such as scalability, decentralized administration, and support for various data types became more and more obvious.
DNS, introduced in 1984, became this new system.
With DNS, the hostnames reside in a database that can be distributed among multiple servers, decreasing the load on any one server and providing the ability to administer this naming system on a per- partition basis. DNS supports hierarchical names and allows for the registration of various data types in addition to the hostname- to- IP- address mapping used in HOSTS files. Database performance is ensured through its distributed nature as well as through caching.
The DNS distributed database establishes an inverted logical tree structure called the domain namespace. Each node, or domain, in that space has a unique name. At the top of the tree is the root. This may not sound quite right, which is why the DNS hierarchical model is described as being an inverted tree, with the root at the top. The root is represented by the null set: “”. When written, the root node is represented by a single dot (.).
Each node in the DNS can branch out to any number of nodes below it. For example, below the root node are a number of other nodes, commonly referred to as top- level domains (TLDs). These are the familiar .com, .net, .org, .gov, .edu, and other such names. Table 5.1 lists some of these TLDs.
TABLE 5.1 Common top- level DNS domains
Domain name | Type of organization |
com | Commercial (for example, stormwind.com for StormWind Training Corporation). |
edu | Educational (for example, gatech.edu for the Georgia Institute of Technology). |
gov | Government (for example, whitehouse.gov for the White House in Washington, D.C.). |
int | International organizations (for example, nato.int for NATO); this top- level domain is fairly rare. |
mil | Military organizations (for example, usmc.mil for the Marine Corps); there is a separate set of root name servers for this domain. |
net | Networking organizations and Internet providers (for example, hiwaay.net for HiWAAY Information Systems); many commercial organizations have registered names under this domain too. |
org | Noncommercial organizations (for example, fidonet.org for FidoNet). |
au | Australia. |
uk | United Kingdom. |
ca | Canada. |
us | United States. |
jp | Japan. |
Each of these nodes then branches out into another set of domains, and they combine to form what we refer to as domain names, such as microsoft.com. A domain name identifies the domain’s position in the logical DNS hierarchy in relation to its parent domain by separating each branch of the tree with a dot. Figure 5.2 shows a few of the top- level domains, where the Microsoft domain fits, and a host called Tigger within the microsoft.com domain. If someone wanted to contact that host, they would use the fully qualified domain name (FQDN), tigger.microsoft.com.
FIGURE 5.2 The DNS hierarchy

An FQDN includes the trailing dot (.) to indicate the root node, but it’s commonly left off in practice.
As previously stated, one of the strengths of DNS is the ability to delegate control over portions of the DNS namespace to multiple organizations. For example, the Internet Corporation for Assigned Names and Numbers (ICANN) assigns the control over TLDs to one or more organizations. In turn, those organizations delegate portions of the DNS namespace to other organizations. For example, when you register a domain name, let’s call it example.com, you control the DNS for the portion of the DNS namespace within example.com. The registrar controlling the .com TLD has delegated control over the example.com node in the DNS tree. No other node can be named example directly below the .com within the DNS database.
Within the portion of the domain namespace that you control (example.com), you could create host and other records (more on these later). You could also further subdivide example.com and delegate control over those divisions to other organizations or departments. These divisions are called subdomains. For example, you might create subdomains named for the cities in which the company has branch offices and then delegate control over those subdomains to the branch offices. The subdomains might be named losangeles .example.com, chicago.example.com, portsmouth.example.com, and so on.
Each domain (or delegated subdomain) is associated with DNS name servers. In other words, for every node in the DNS, one or more servers can give an authoritative answer to queries about that domain. At the root of the domain namespace are the root servers, which I’ll cover later in the chapter.
Domain names and hostnames must contain only characters a to z, A to Z, 0 to 9, and – (hyphen). Other common and useful characters, such as the & (ampersand), / (slash), . (period), and _ (underscore) characters, are not allowed. This is in conflict with NetBIOS’s naming restrictions. However, you’ll find that Windows Server 2022 is smart enough to take a NetBIOS name, like Server_1, and turn it into a legal DNS name, like server1 .example.com.
DNS servers work together to resolve hierarchical names. If a server already has information about a name, it simply fulfills the query for the client. Otherwise, it queries other DNS servers for the appropriate information. The system works well because it distributes the authority over separate parts of the DNS structure to specific servers. A DNS zone is a portion of the DNS namespace over which a specific DNS server has authority. (DNS zone types are discussed in detail later in this chapter.)
Within a given DNS zone, resource records (RRs) contain the hosts and other database information that make up the data for the zone. For example, an RR might contain the host entry for www.example.com, pointing it to the IP address 192.168.1.10.