DNS Overview

For years, Internet computers located each other by looking up host names in a database that was downloaded to each server and/or router manually or automatically from the Network Information Center (NIC). But before too long, the flat-file host name database became unwieldy and replicating it around the network became too cumbersome. But then, DNS was born!

DNS is simply a fancy database that matches user-friendly computer names to device IP addresses. To accomplish this impressive task, DNS employs two services:

• DNS Hierarchy The DNS Hierarchy (also called the Domain Name Space) specifies a host's location in the global Internet tree. This tree consists of top-level domains and more precise partitions called zones.

• DNS Name Services This is the functional DNS component that actually maps the host's name to a computer's IP address. DNS Name Services uses a client/server model with Primary and Secondary servers and clients called Resolvers.

Let's take a closer look at how DNS resolves domain names using a logical hierarchy and functional name services.

DNS Hierarchy

The DNS Hierarchy organizes IP hosts into a logical upside-down tree much like the file system directory structure (as shown in Figure 4.9). In Figure 4.9, the first three levels of the tree represent domains. The end leaves of the tree are individual host machines on the Internet. When you build an IP network, each resource must maintain a unique host name. In theory, DNS Hierarchy follows the same architectural rules as another Novell logical tree: eDirectory. However, be careful not to confuse the functionality of these two trees. DNS is a distributed database for IP addressing of physical Internet resources, whereas eDirectory is an intranetwork solution for logically identifying distributed network resources.

Figure 4.9. The upside-down DNS tree.

DNS naming operates similarly to fully distinguished naming in the eDirectory. In the IP world, an absolute (or fully qualified) DNS domain name is constructed by listing all domains on the path from the end device to the Root. Just like eDirectory, a period is used to delimit the labels in the domain name. For example, in Figure 4.9, the absolute domain name for the host SRV1 in NORAD is represented as

SRV1.NORAD.ACME.COM.

In this case, the interior nodes of the DNS tree (such as .COM and .ACME) do not represent network devices. Instead, they represent logical divisions of the DNS name space analogous to logically containers in the Novell eDirectory tree.

As you can see in Figure 4.9, many of the top-level domains have already been established by the Internet governing body, InterNIC. These predefined domains help organize the vast Internet into functional zones, as shown in Table 4.6.

Table 4.6. Predefined Domains at the Top of the DNS Tree

DOMAIN	FUNCTION
.COM	Commercial organizations. This is the most popular domain used by today's high-profile Internet organizations.
.EDU	Educational institutions. Many universities, colleges, schools, educational service organizations, and consortia have registered here. Recently, a decision was made to limit further registrations to four-year colleges and universities.
.UK	A two-letter country code. The ISO-3166 Committee has determined that each country should be represented by a specific two-letter country code. For example, .UK represents Great Britain, .AU represents Australia, .US represents the United States, .DE represents Germany, and .CA represents Canada.
.GOV	Government agencies. This domain is reserved for US federal government agencies.
.INT	International organizations. This domain is reserved for organizations that have been established by international treaties.
.MIL	United States military. This domain is reserved for branches of the US Armed Forces.
.NET	Networking entities. This domain represents computers of network providers, such as NIC and NOC computers.
.ORG	Miscellaneous organizations. This domain is an open book for organizations that do not fit into any of the previous domain categories.

The DNS Hierarchy can be further subdivided into partitions called zones. Zones begin at a specific domain and extend downward until they reach either a terminating host object or another zone. For example, the shaded area in Figure 4.10 represents the ACME.COM. zone. Furthermore, any private network (such as ACME.COM.) can implement its own domain names within the specific zone. Keep in mind that your zone must be sanctioned by the NIC to connect it to a public network, such as the Internet.

Figure 4.10. The ACME.COM. DNS zone.

This completes our discussion of the logical DNS Hierarchy. As you can see, the virtual DNS tree resembles our own logical eDirectory cloud, but with a strange twist: The DNS tree is upside-down! From an organizational naming perspective, it seems pretty straightforward. Now let's learn how DNS servers and clients resolve each other's identities using name services.

REAL WORLD

DNS supports three different zone types:

• Standard Zones A standard DNS zone contains records that resolve domain names into IP addresses. Most of today's Internet devices are addressed using standard DNS zoning rules.

• IN-ADDR.ARPA Zones The IN-ADDR.ARPA. zone type provides mappings of IP addresses to domain names in a specific format backward.

• IP6.INT Zones The ever-increasing use of the Internet along with the limited number of IP addresses, is driving the development of a new IP addressing scheme known as IPv6, which provides a greater quantity of unique IP addresses. Devices using this scheme in a zone of the Internet are part of an IP6.INT. zone type.

DNS Name Services

The second half of the DNS one-two punch is DNS Name Services. This is where the actual work is done. DNS Name Services actually maps user-friendly host names to IP addresses, and this helps computers throughout the Internet locate each other. As we mentioned earlier, DNS Name Services relies on a client/server architecture. In this model, clients (resolvers) query one or more servers for host address information. If the DNS server doesn't have the information a client needs, it relays the request to another name server up or down the DNS Hierarchy. As soon as it finds the answer it needs, the original DNS server relays it to the requesting client (resolver).

The names and IP addresses for all hosts in a DNS zone are maintained on a single server called the Primary server. The information contained on the Primary server is called the Authoritative Database for that zone. In Figure 4.11, we have set up the SRV1.NORAD.ACME.COM. server as the Primary DNS server for the NORAD.ACME.COM. zone. All updates to the DNS database for the zone are made on this server.

Figure 4.11. Using Primary and Secondary DNS servers.

TIP

It's a good idea to keep the Primary DNS server within your local zone; however, it's not required. By rule, the DNS server for NORAD.ACME.COM. can be located anywhere in the DNS hierarchy.

Furthermore, DNS supports a backup naming server called a Secondary server. Secondary DNS servers provide redundancy and load balancing for DNS naming within a zone. This backup periodically downloads a copy of the Authoritative Database from the Primary server. It's important to note that updates to the zone database are only made at the Primary server and then distributed to the Secondary server when it requests a copy. This process is known as zone transfer.

In Figure 4.11, we have configured SRV2.ACME.COM. as the Secondary DNS server for the NORAD.ACME.COM. zone. As we're sure you've noted, the Secondary DNS server is located outside of its home zone. Although it's a good idea to keep Primary DNS servers inside the zone, you should distribute Secondary DNS servers in geographically remote locations for fault tolerance purposes.

The process of DNS name resolution is actually quite similar to the way you might find a telephone number for someone who lives in a remote city. Let's say, for example, you lived in NORAD and wanted to call someone in Tokyo. First, you would call your local operator to obtain the country code and the number for directory information in Japan. Then you would call directory information in Japan and get the local number for Tokyo. Then you would call Tokyo and query your friend by name.

Let's say you reside in the LABS division of NORAD within ACME. From your DNS client, you want to access a device in the QLABS.COM. zone. Here's how your local DNS server would resolve the destination IP address (follow along in Figure 4.12):

• Point 1 To find a machine named JANE in the QLABS.COM. zone, you must first ask your local DNS server if it has a cached entry for JANE. If not, your local Primary server will relate the request to the Root server.

• Point 2 Your local Primary DNS server asks the Root DNS server for the location for the .COM server. At this point, you'll begin resolving JANE's IP address from the top down.

• Point 3 Next, the .COM server will find the IP address of the Primary server in the QLABS.COM. zone and send it to your local server.

• Point 4 After your request finds its way to the Primary DNS server in the QLABS.COM. zone, you'll be able to resolve the specific IP address for JANE. This address will then be relayed back to your local Primary DNS server (Point 1) by backtracking through all the servers (or routers) that it took to get there.

Figure 4.12. DNS address resolution for JANE.QLABS.COM.

As you can see, DNS is a powerful tool for helping users resolve complex IP addresses. Furthermore, the NetWare 6 DNS/DHCP implementation stores zone data within eDirectory and replicates it like other eDirectory data. Because of this, all NetWare servers can access DNS data from the eDirectory tree. This provides fault tolerance and load balancing for DNS data, and allows you to make changes to DNS zones from anywhere on the network.

Now let's expand our DNS/DHCP journey into the realm of DHCP the Dynamic Host Configuration Protocol.