When the Internet was young—so young, in fact, that it was known as ARPANET—it consisted of only a few hundred computers. The task of tracking what host names went with what IP addresses was a relatively easy one. All of these mappings were located in a file named HOSTS, which was kept on a central computer on the network and perhaps mirrored on a few additional computers. Whenever a computer needed to resolve a host name, it consulted that file (occasionally copying it to the local com puter). As the network grew, however, it became impossible to use a single file to hold all the mappings. There were three problems with the existing setup:
■ The file became too big to manage effectively and required administration many times per day.
■ All name resolution traffic had to be routed through the computer that held the HOSTS file and the file could not be copied enough to be continually up to date. ■ The file used a flat data structure, so every computer on the network had to have
a unique host name.
Domain Name System (DNS) was created to solve these three problems. The DNS data- base is distributed across many computers on the Internet, all these computers sharing the burden of name resolution. The DNS namespace is also hierarchical and broken down into different domains. A particular host name has to be unique only within its domain instead of within the whole network. Each domain is considered the authority on names within its boundaries.
Domain Namespace
A namespace is a defined realm in which the names of all like components must be similarly structured, but uniquely identifiable. The Internet is the most readily under- stood DNS namespace. All hosts on the Internet must be uniquely identifiable; their full DNS name must point to a particular address.
The domain namespace is organized into a hierarchy that works much like the folder structure on a computer. You cannot have two files named readme.txt in the same directory. However, there are probably dozens of files by this name scattered across different directories on your computer. That’s how DNS works, too. You could not have two hosts named mailserver within the same domain, but every different domain out there could have one host named mailserver. Figure 1-6 illustrates the hierarchical nature of domain name space.
org com net gov
microsoft headrest yahoo cnn
sales server1 server2 research . Root Domain Top-Level Domains Second-Level Domains Third-Level Domains Host Names
Figure 1-6 DNS domains are organized hierarchically.
The Root Domain At the top of the DNS hierarchy, there is a single domain called the
root domain. The root domain is represented by a single period.
Top-Level Domains Top-level domains are controlled by the Internet Activities Board
(IAB), an Internet authority controlling the assignment of domain names, among other things. Top-level domains have names like com (for business) and gov (for govern ment). Table 1-1 lists common top-level domains, starting with the most frequently used domains.
Table 1-1 Common Top-Level Domain Names Top-Level Domain Type of Organization
com Commercial organizations
edu Educational institutions
org Nonprofit organizations, although this is not strictly enforced net Network service providers, although this is not strictly enforced
gov Government institutions
mil Military institutions
num Telephone numbers
arpa Used for reverse DNS lookups. See the section “DNS Reverse Lookup” later in the chapter
xx Two-letter country codes; every country has its own top-level domain name
info Available for all uses
name Used for personal sites
Second-Level Domains Beneath the top-level domains, there is a second level of
domains that is registered to individual organizations. For example, microsoft.com and contoso.com are second-level domains within the top-level domain com. Once a second-level domain is registered, control of the namespace for that domain is passed to the registering organization to manage. The organization can even further divide the namespace into another level of domains. For example, a company with the domain contoso.com might divide the domain into the third-level domains sales.contoso.com and research.contoso.com.
Fully Qualified Domain Names A fully qualified domain name (FQDN) is the full
description of a particular host’s place in the DNS hierarchy—think of it like the full path of a file in your computer’s file system. The following is an example of an FQDN: mailserver.sales.contoso.com
The name refers to a host named mailserver in a subdomain named sales, which is under a second-level domain named contoso, which in turn is under the top-level domain com, which of course is in the root domain (.).
Zones and Name Servers
In addition to being segmented into domains, the DNS namespace is also broken up into partitions called zones. Each zone is a file representing a contiguous portion of the namespace for which a particular name server (or group of servers) is responsible. A zone actually corresponds to a series of resource records stored on a DNS server that
map IP addresses to various hosts and services in the zone. This database of records is considered authoritative for all the domains contained in that zone.
A zone encompasses at least one domain, which is referred to as the zone’s root domain. The zone may also contain subdomains of that root domain but does not nec essarily have to hold all the subdomains of the root domain. Consider the example shown in Figure 1-7, which shows a second-level domain named contoso.com that contains two subdomains, sales.contoso.com and research.contoso.com. In this case, contoso.com is the root domain of zone1 and sales.contoso.com is also contained in this zone. A separate zone, zone2, has been configured for the subdomain research.contoso.com. zone1 com sales.contoso.com contoso.com research.contoso.com zone2
Figure 1-7 A domain is divided into nested zones of authority.
Zones must contain contiguous domains within the namespace. This means that a sin gle zone could contain a domain and its subdomains, but a zone could not contain two different subdomains without also containing the parent domain. Take another look at the example in Figure 1-7. Zones could be configured the way they are shown in the figure. Or a single zone could be configured that contained contoso.com and its two subdomains. You could not, however, create a zone that contained the contoso.com domain and then create a separate zone that contained just the two subdomains. Each zone has at least one name server responsible for knowing the address informa tion for each device within that zone, and a single name server can be configured to manage more than one zone. Each name server also knows the address of at least one parent name server. If a particular name server cannot resolve a host name, it can pass the query on to another name server that may have the information.
Using Multiple Name Servers in a Zone You can also create multiple name servers for a single zone. One of these name servers contains a master copy of the zone database file, which is referred to as the primary zone file. Other name servers created for a zone act as secondary servers, and each contains a secondary zone file. When records in the zone are updated, they are updated on the primary server and then replicated to the secondary servers. Using multiple servers in a zone provides a number of important benefits, including:
■ Redundancy—If a primary name server fails, secondary servers can provide DNS services to your network.
■ Load Balancing—On large networks, creating multiple servers distributes the load of client requests among the primary and secondary servers, decreasing response time.
■ Remote Access—Creating secondary servers on remote subnets prevents client requests from having to cross remote access links, decreasing response time.
Types of Zones Windows Server 2003 supports three distinct types of zones. These
zones include:
■ Active-Directory Integrated In this type of zone, the DNS database is stored within Active Directory. All DNS servers in an Active Directory–integrated zone are considered primary servers because the DNS information actually becomes part of the Active Directory database; any DNS server can be updated and any of them can resolve client requests. Active Directory is responsible for replicating zone information between DNS servers, often making replication quicker and making it a part of Active Directory management instead of a separate management practice. ■ Standard Primary The master copy of the DNS database resides in a standard
ASCII text file. Only this primary zone can be directly modified.
■ Standard Secondary The zone information is a read-only replica of an existing standard primary zone and helps provide a backup to the primary zone. Zone information is updated on the primary DNS server and then transferred to any sec ondary servers.
The Name Resolution Process
Resolving a name means determining the IP address that is associated with that name. In DNS, the client that performs name resolution is called a resolver. In Windows, this resolver is a service named the DNS Client service. The resolver operates at the appli cation layer of the TCP/IP model (discussed later in the chapter) and is often built into different programs that may need to resolve host names. For example, when you type an address (an FQDN) into your Web browser, the browser uses DNS to query the name server configured on the local host and resolve the address.
There are two types of queries that a resolver can perform: a forward lookup query, which translates names to IP addresses, and a reverse lookup query, which translates IP addresses to names. Both types of queries are serviced by DNS name servers.
Forward Lookup Queries The most common type of query is the forward lookup
query, where a host or domain name must be resolved to an IP address. In this type of query, a resolver sends a resolution request to its configured name server. If that name server has the information, it passes it back to the client. If it does not, it in turn sends queries to other name servers until it finds the information.
The example shown in Figure 1-8 illustrates this process at work as a resolver on the Internet attempts to resolve the name www.contoso.com.
Resolver Root Name
Server Com Name Server contoso.com Name Server Local Name Server 1 7 8 6 5 4 3 2
Figure 1-8 Multiple name servers might handle a single query.
1. The resolver sends a query to its local DNS server, asking for resolution of the domain name contoso.com. The name server either returns the information to the resolver or does not. The name server cannot refer the resolver to another name server (though the name server itself can query another resolver). This type of query is a recursive query—the server must eventually either respond with the mapping or a reply that the name/IP was not found.
2. The local name server that receives the request from the resolver checks the zones under its authority. If the requested hostname or domain is in one of its zones, it returns the information to the client. If not, as in this case, the local name server checks its local name cache to see if the name has been recently resolved. If it has not, it sends a query for www.contoso.com to a root name server.
3. The root name server has authority for the root domain and replies to the local server with the IP address of a name server that has authority for the com top-level domain.
4. The local name server sends out another query for www.contoso.com to the IP address supplied by the root name server. These types of queries are called itera tive queries because the same query is sent to multiple servers until resolved.
5. The com authoritative server replies with the IP address of a name server that has authority over the contoso.com second-level domain.
6. The local name server sends another query for www.contoso.com to the IP address of the contoso.com name server.
7. The contoso.com name server replies with the IP address for www.contoso.com. 8. The local name server returns the IP address of www.contoso.com to the original
resolver.
Reverse Lookup Queries A reverse lookup query is one in which an IP address is
resolved to a host or domain name. Some TCP/IP utilities (such as nslookup, ping, and netstat) use reverse lookups. Reverse lookups can also be useful if you are trying to keep track of network usage, if you are trying to track down a host that is causing issues on the network, or even if you are trying to verify the identity of a host. Because DNS databases are indexed using names and not IP addresses, searching for a name on the basis of an IP address within a regular DNS database structure would be a slow process. To solve this problem, a special domain was created in the arpa root domain named in-addr.arpa, which stands for Inverse Address. In-addr.arpa uses the IP address as an index to the host's resource record information. When the proper resource record is located, the host name can be extracted.
Nodes in the in-addr.arpa domain are named after the numbers in the dotted decimal representation of an IP address. However, because IP addresses get more specific from left to right and domain names get more specific from right to left, the order of the IP address octets is reversed when building the corresponding name in the in-addr.arpa domain. For example, a host name with the IP address 192.168.201.35 would be a PTR record in the 201.168.192.in-addr.arpa zone file. The entry in that file would take the form 35 IN PTR host_name.
The in-addr-arpa domain is built using a hierarchy just like a standard DNS domain. As the in-addr-arpa domain is built, special resource records called pointer (PTR) records are added to the domain’s database to map IP addresses to host names. You’ll learn more about resource records in the next section.
Resource Records
Zone files are made up of resource records. A resource record contains a mapping of a hostname or service to an IP address. Table 1-2 shows many of the types of resource records supported by the Windows Server 2003 DNS service.
Table 1-2 DNS Resource Records Resource
Record Use
A An address record that maps a host name to an IP. A records use the 32-bit IP ver sion 4 format.
AAAA Also an address record, AAAA records use the 128-bit format of the next genera tion of the IP protocol, IPv6.
CNAME A canonical name record establishes an alias—a synonym for a host name. Using CNAME records, you can have more than one name resolve to a single IP address. MX A mail exchange record identifies the mail server for a particular DNS domain. NS A name server record identifies a name server for a particular DNS domain. PTR A pointer record associates an IP address with a host in a DNS reverse-naming zone. SOA A start of authority record is the required first entry for all forward and reverse
lookup zones. It specifies the domain for which a DNS server is responsible. It also specifies a variety of parameters that regulate operation of the DNS server. SRV The service record allows you to specify what services a server provides and what
domain it services. The SRV record is required in order for Active Directory to be used. WINS A Windows Internet Name Server record identifies a WINS server that can be con
sulted to obtain names that are not recorded in the DNS name space. WINS_R A reverse WINS record causes Microsoft DNS to use the nbstat command to
resolve reverse-lookup (address-to-name) client queries.
WKS A well-known service record describes services provided by a specific protocol on a specific adapter.
Exam Tip You should know some of the more important resource records for the exam. These include address (A), canonical name (CNAME), mail exchanger (MX), name server (NS), pointer (PTR), start of authority (SOA), and service (SRV). Remember them by name and acro nym and understand their importance.