UEU-co logo


Previous Page Next Page

Hour 15. Understanding the Domain Name Service

What You’ll Learn in This Hour:

As network operating systems have moved away from proprietary network protocols and have embraced the open TCP/IP protocol stack, the need for resolving names to IP addresses has arisen. This hour looks at the Domain Name Service (DNS) provided by Windows Server 2008.

DNS Server Overview

The Domain Name Service provides a hierarchical name-resolution strategy for resolving a Fully Qualified Domain Name (FQDN), hostnames, and other service-related names to IP addresses. DNS servers provide this resolution from a “friendly name” to logical address (the IP address) on TCP/IP networks such as the Internet. For example, when you type Microsoft.com into your web browser address window, a DNS server somewhere on the Internet actually resolves the FQDN name (Microsoft.com) to the IP address of the Microsoft website.

So, in terms of TCP/IP networks and the Internet in particular, each organization deploys DNS servers that provide FQDN resolution to IP addresses. In effect, each large company, organization, or service provider manages the name-resolution duties for its own portion of the Internet. In fact, when a company registers a domain name with InterNIC, it must submit the IP addresses of two DNS servers that will handle the name-resolution duties for that domain. You can choose to run your own DNS implementation or outsource it to an ISP or other networking company that provides the service. (For individuals who register a domain name, the DNS server addresses are typically provided by your service provider.)

Servers maintained by InterNIC provide the mechanism for a local DNS server to resolve an FQDN to an IP address on a remote portion of the Internet. Because the InterNIC servers hold a database that provides a listing of all domain DNS servers and their IP addresses, the local DNS merely queries the InterNIC server for the IP address of the DNS server that services a particular domain (using the friendly name). When the local server receives the IP address of the remote DNS server, it can then query it directly for the resolution of the remote FQDN to an IP address.

With each network really responsible for the local mapping of friendly names to IP addresses (meaning the network must deploy its own DNS servers), the DNS database is a distributed database. Each organization maintains its part of the overall DNS database.

By the Way

An alternative to DNS is the hosts file. Hosts files are used as a system to resolve the friendly name to the IP address on TCP/IP networks when DNS is not employed (or was not employed—hosts files served as a precursor to DNS). A hosts file is an ASCII text file that contains two columns of information (and is stored in the %systemroot%system32etcdrivers folder). The computer’s hostname is listed in the first column; the corresponding IP address is listed in the second column.

With Windows Server 2008 embracing the Active Directory as its directory services platform, DNS, FQDNs, and TCP/IP become an integral part of implementing and administering a Windows network. Because Windows Server 2008 is outfitted with the newer Dynamic DNS server standard (DDNS), the administrative chores related to maintaining the DNS database are greatly reduced (when compared to other DNS servers). The DDNS database is built dynamically by the server and the DNS clients.

The DNS Namespace

To understand how DNS or FQDN names are determined, you need to understand the domain namespace, which is an integral part of how Internet websites are named.

The domain namespace is the actual scheme used to name domains that are at different levels in the DNS domain hierarchical tree. The domain namespace also provides for down-level names of individual computers and other devices on a network.

The first thing to define is what a domain is in relation to DNS. Each division on the DNS tree (which takes the form of an inverted tree) is considered a domain.

By the Way

DNS domains and Microsoft Active Directory domains are not the same thing and should not be confused (even though they are closely related and based upon different logical hierarchies). When you use the DNS naming structure on your network as the Active Directory domain structure, the two naming systems appear to be the same. In fact, when you configure a new domain controller and add the Domain Name Service during the domain controller creation, the forward lookup zone for the DNS server is identical to the Active Directory domain structure (lookup zones are discussed later in this hour).

At the base of the DNS tree is the root domain. The Internet’s root domain is represented by a period (see Figure 15.1). Below the root domain are the top-level domains. The top-level domains consist of suffixes such as .com and .edu. Some of the top-level domain names available are listed here:

Figure 15.1. The domain namespace tree provides the naming conventions for domains and objects that reside in domains, such as hosts.

Below the top-level domains are the second-level domains; these secondary domains consist of company, institutional, and private domains commonly used to access a site on the Web, such as samspublishing.com (Sams Publishing’s domain name) and une.edu (the domain name of the University of New England in Biddeford, Maine). Under the second-level domains are found subdomains. These subdomains are typically used to divide a larger secondary domain into geographical or functional units. For example, if I have a company that uses the secondary domain name of Habraken.com and my business is divided into two distinct divisions (consulting and sales), I could create the two subdomains consulting.Habraken.com and sales.Habraken.com (see Figure 15.1).

Second-level domains (and subdomains) also contain hosts, which are the computers and other devices that reside within the second-level domain or subdomain namespace. For example, if I have a computer named joe1 and it is in the sales.Habraken.com subdomain, it is referred to as joe1.sales.Habraken.com, using the DNS nomenclature.

How DNS Works

Now that you’ve seen the DNS naming hierarchy, it’s time to delve into how DNS resolves FQDNs to IP addresses, and vice versa. The DNS service consists of two different entities: the resolver and the server. The resolver is software built into a WinSock application, such as a web browser that queries the server when a host’s FQDN needs to be resolved to an IP address. The server component of DNS is handled by the DNS server, which, in our discussion, is a server running Windows Server 2008 and the DDNS service.

When a client computer attempts to resolve a FQDN to an IP address, the resolver checks a local cache (if the resolver is set up to maintain a local cache) to see whether the resolution information for going from FQDN to IP address is available. If the information is in the cache, the process is over when the FQDN is resolved to an IP address by the client computer itself.

By the Way

All Windows clients and servers maintain a DNS cache, which helps a DNS client quickly resolve a DNS query basically by itself. The cache is typically useful only when trying to resolve a friendly name to an IP address for a resource that is used often. All other queries go to the DNS server. You can view the DNS cache with the command-line utility ipconfig/displaydns.

If the information is not available in the cache, the resolver software obtains the IP address of the local DNS server, using the settings found in the client computer’s TCP/IP settings. Windows clients and servers on the network are configured with a preferred DNS server either statically or by a DHCP server. (The types of TCP/IP settings that a DHCP server can provide are discussed in Hour 16, “Using the Dynamic Host Configuration Protocol.”) Figure 15.2 shows the TCP/IP properties of a Windows Server 2008 member server that specifies a preferred DNS server (and is also configured with a static IP address).

Figure 15.2. The preferred DNS server is listed in a client’s TCP/IP properties.

The client sends a request to the preferred DNS; if the FQDN to be resolved is for a host computer in the local DNS domain, the DNS server looks up the name in the DNS database and returns the appropriate IP address to the requesting computer. If the name is for a computer that is not in the local domain, the name can be resolved using the cache that is maintained by the local DNS server.

If the information is not cached on the local DNS server, your DNS server contacts the root server for the hostname’s top-level domain (these IP addresses are built into the Windows Server 2008 DNS implementation) by querying it with the hostname. The root server uses the hostname to determine the IP address of the authoritative DNS server for the domain to which the particular host belongs. When your DNS server has the IP address of the other domain’s DNS server, it can query that server, which then supplies the resolution information for moving from FQDN to IP address. The local DNS server can then pass this information on to the original requesting host.

By the Way

So, in a nutshell, DNS can resolve DNS names to IP addresses (and vice versa) because DNS servers host the information needed by a computer running the DNS client when it needs to resolve a FQDN to an IP address. The DNS client on the local computer needs the aid of the DNS server only if it does not have the FQDN and IP address equivalent stored in its cache.

Active Directory Domain Services and DNS

When you add the Active Directory Domain Services role to a server on the network and promote the server to a domain controller, you create the Active Directory structure for the network. The first domain created is at the forest level. You can then create subsequent domains such as regional domains that provide the branches in domain root.

By the Way

When you define your own domain namespace keep your second-level domain names simple and use geographic location or company division information for subdomain levels. Also try to limit the number of domain levels if possible. Don’t create subdomains just for the sake of creating divisions in the namespace.

DNS is tightly wound with the Active Directory Domain Services (AD DS). In an ideal network implementation, your DNS and AD DS structure will mirror each other. The integration of DNS and AD DS enables you to take advantage of DNS features that directly relate to AD DS, such as AD DS replication. Also be aware that DNS is necessary for the location of domain controllers on the network (by DNS clients) and that the Netlogon service uses DNS for the registration of domain controllers in the DNS domain namespace.

When you install DNS as part of the process of creating a new domain or adding a domain controller to an existing domain, the DNS namespace is derived from the Active Directory namespace. This means that the AD DS domain hierarchy is incorporated in the DNS zone hierarchy.

For example, when you bring AD DS, a domain controller, and DNS online during the Active Directory Directory Services installation (discussed in Hour 8, “Understanding and Configuring Active Directory Domain Services”) the forward lookup zones created for DNS directly reflect the Active Directory domain structure (see Figure 15.3).

Figure 15.3. DNS and AD DS can be tightly integrated in terms of their logical hierarchies.

[View full size image]

Lookup zones are examined more closely later in this hour. Let’s take a look now at how to install the Domain Name Service on a server that will provide DNS as one of its primary functions on the network (meaning it is not a domain controller).

Previous Page Next Page

Leave a Reply

Time limit is exhausted. Please reload the CAPTCHA.


apply_now Pepperstone Group Limited