Understanding DNS

An extremely important part of managing IP networks is understanding the Domain Name Service. The Domain Name System (DNS) provides a hierarchical name resolution strategy for resolving a Fully Qualified Domain Name (FQDN) to an IP address. DNS servers provide this "friendly name" to logical address (the IP address) resolution 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 (Microsoft.com) to the IP address of the Microsoft Web site.

So in terms of TCP/IP networks and the Internet in particular, each organization will deploy DNS servers that provide FQDN resolution to IP addresses. In effect, each large company, organization, or service provider manages the name resolution duties for their own portion of the Internet. In fact, when a company registers a domain name with InterNIC, the company must provide the IP addresses of two internal DNS servers that will handle the name resolution duties for that domain (for individuals that 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 a FQDN to an IP address on a remote portion of the Internet. Since 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). Once 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 using DNS servers, the DNS database is a distributed database. Each organization maintains its part of the overall DNS database. This means that each organization will typically deploy its own DNS servers (which handle most of the local DNS related queries). We will discuss deploying a DNS server in a moment. First, we need to take a look at the DNS namespace.

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 Web sites 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 that we should define is what a domain is in relation to DNS. Each division on the DNS tree (which takes the form of an inverted or upside-down tree) is considered a domain.

At the base of the DNS tree is the root domain. The Internet's root domain is represented by a period (see Figure 12.8). Below the root domain are the top-level domains. The top-level domains consist of suffixes such as .com, .edu, and so on. Some of the top-level domain names available are

• com . Used by commercial organizations. For example, quepublishing.com is the domain name for Que Publishing.

• edu . Reserved for educational institutions. For example, une.edu is the domain name of the University of New England.

• org . Used by noncommercial organizations and institutions. For example, gsusa.org is the domain name of the Girl Scouts of America.

• gov . Reserved by the United States for governmental entities. For example, senate.gov is the domain for the U.S. Senate.

• net . To be used by companies involved in the Internet infrastructure, such as ISPs.

• country names . .bs for the Bahamas, .ga for Gabon, and many more.

• biz . A new top-level domain added recently to accommodate businesses.

• info . Another new top-level domain recently added, which can be used for informational Web sites (or just about anybody looking for a domain name).

Below the top-level domains are the second-level domains; these secondary domains consist of company, institutional, and private domains that we commonly use to access a Web site on the Web, such as quepublishing.com (Que Publishing's domain name) and une.edu (the domain name of the University of New England in Biddeford, ME). Under the second-level domains are 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 12.8).

Figure 12.8. The domain name space tree provides the naming conventions for domains as well as objects that reside in domains such as hosts .

Second-level domains (and subdomains) will 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 will be referred to as joe1.sales.Habraken.com using the DNS nomenclature .

How DNS Works

Now that we've looked at the DNS naming hierarchy, we should 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 in to 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.

When a client computer attempts to resolve a FQDN to an IP address, the resolver will check a local cache (if the resolver is set up to maintain a local cache) and see if the FQDN to IP address resolution information is available. If the information is in the cache, the process is over; the FQDN is resolved to an IP address by the client computer itself.

Note

All Windows clients (and other OS clients ) maintain a DNS cache, which helps a DNS client to quickly resolve a DNS query basically by itself. The cache is typically only useful when trying to resolve a friendly name to an IP address for a resource that is used often. All other queries will go to the DNS server.

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 (or provided by a DHCP server as discussed earlier in the chapter).

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 not on your domain, two things can happen: One possibility is that the name can be resolved using the cache that is maintained by the local DNS server; the server will cache or remember host names that it has previously resolved. If the information is in this cache, the DNS server provides it to the requesting client.

In cases where the information is not cached on the DNS server, your DNS server will contact the root server for the host name's top-level domain by querying it with the host name. The root server will use the host name to determine the IP address of the authoritative DNS server for the domain that the particular host belongs to. Once your DNS server has the IP address of the other domain's DNS server it can query that server, which will then supply the FQDN-to-IP address resolution information. The local DNS server can then pass this information on to the original requesting host.

Configuring a DNS Server

Now that you've seen how DNS works, let's take a look at configuring DNS on a server. As with DHCP, DNS is a service that you can add to the configuration of a network operating system (or install it when you first install the network operating system). For example, NetWare, Windows Server 2003, and Linux all provide support for DNS. Windows Server 2003 uses the Configure Your Server Wizard (as discussed earlier in the chapter in relation to DHCP) to add services such as DNS to the server.

Once you have the DNS service installed on a network server, you must configure DNS. The first thing you must add to the DNS configuration is a forward lookup zone. A forward lookup zone allows for forward lookup queries, in which a host can find an IP address by querying a DNS server with the host name of a particular computer or device. For DNS to work, at least one forward lookup zone is required.

When you create the forward lookup zone, you have to name it. The name of the zone will be the same as the DNS domain name for that portion of your network. For example, if your DNS domain for the network is spinach.com, the zone name would be spinach.com.

Figure 12.9 shows the iManager screen that is used to configure DNS on a NetWare server. Note in the figure that a name must be supplied for the zone and the zone type.

Figure 12.9. The Novell iManager is used to configure DNS zones.

There are two types of forward lookup zones: primary and secondary. A primary zone is the master copy of the DNS database. The primary zone is administered on the server the zone was created on. So, the server would be considered the authoritative DNS server for the zone. A secondary zone uses a database file that is a read-only replica of an existing zone. The DNS server configured with the standard secondary zone helps the primary DNS server handle the name resolution required for the network.

Another type of zone that should be configured on the DNS server is a reverse lookup zone . A reverse lookup zone allows for the resolving of IP addresses to host names, which is called a reverse lookup query . To name the reverse lookup zone, you provide your network ID. The network ID is the portion of an IP address that does not contain any references to host address. For example, in the Class C IP address 192.168.5.1, only the fourth octet contains host address information (the default class C subnet mask of 255.255.255.0 basically tells you which octet is used for host addressing). This means that the network ID would be 192.168.5. Figure 12.10 shows the New Scope Wizard, which is used to create reverse lookup zones (and forward lookup zones) on a server running Windows Server 2003.

Figure 12.10. A reverse lookup zone can also be created on the DNS server.

Once the zones have been configured on the DNS server, records must be placed in the zones. Depending on the implementation of DNS you are using (meaning the NOS you are using), you might have to create certain zone records. One example is the A record, which provides host name and IP address information for a particular host device on the network (such as a computer). In the case of Windows Server 2003 DNS, which is also called Dynamic DNS, a number of the records used by DNS to handle queries are automatically generated in the appropriate zones.

Figure 12.11 shows the DNSMGMT snap-in that is used on a Windows 2003 server to manage DNS. The forward lookup zone spinach.com holds an A Host record that was automatically generated for the server (Hermes1) that is providing the DNS service. The DNS server shown in the Figure 12.11 had just been newly created and so the number of records in the forward lookup zone is minimal; as the Windows DNS server listens to the network, it will acquire additional A Host and other records until it is able to resolve all local DNS queries.

Figure 12.11. Windows Dynamic DNS automatically generates A Host records for hosts on the network.

As you can see, Host records provide a host's name and a host's IP address. There are also other record types found on DNS servers that are used for various purposes. Table 12.1 provides a list of record types that are found in a DNS database.

Table 12.1. DNS Resource Record Types

Record Type	DNS Snap-in Name and Description
SOA	Start of AuthorityIdentifies the name server that is authoritative for data within the domain, and is the first record in the zone database file. It is created automatically when you bring your primary name server online.
NS	Name ServerA record is created for each name server assigned to the domain.
A	HostProvides the host name to IP address mapping in a forward lookup zone.
PTR	PointerThis type of record is the reverse of an A record and points to a host record. Found in the reverse lookup zone, the PTR record provides for IP address to host name mappings.
SRV	ServiceThis type of record shows which services are running on a particular host computer. For example, SRV records could identify the domain controllers on the network.
MX	Mail ExchangerThis record type identifies the mail servers on the network, as well as what order the mail servers should be contacted in.
CNAME	Canonical Name or AliasThis type of record is used to create an alias for an existing record. This allows you to point several different names at the same IP address. This would be particularly useful for pointing at your Web server on the network.
HINFO	Host informationThis record type can be used as a sort of low-rent resource tracking tool for your DNS server. This record can provide information on the CPU, operating system, and other software/hardware information.
WINS	WINSThis type of record supplies DNS with the ability to use WINS to help resolve a host name.

Managing DNS has become another important task for the network administrator. Before it became necessary to deploy IP networks, DNS was not an issue, particularly on networks that ran other protocol stacks such as IPX/SPX. While many small companies will leave the DNS management to the Internet service provider, larger networks will require internal DNS implementations . For more about DNS and other TCP/IP topics you may want to check out the book Special Edition Using TCP/IP from Que Publishing.