|
|
Network Registrar provides the tools you need to manage your IP address space. Although IP address management is complex, this chapter aims at providing you with a quick overview. Its purpose is to introduce you to the terms and concepts used in this document publication.
This chapter discusses Network Registrar's main components:
These components are modular, which means that you can decide to use only Domain Name System (DNS) or only Dynamic Host Configuration Protocol (DHCP). If you want to benefit from dynamic DNS updates, however, you need to run both DNS and DHCP.
For more information about these services, refer to the specific chapters in this document and to the online help, which is accessible while you are running Network Registrar.
To understand how DNS works, imagine a typical user named John. One morning John logs into his computer. He launches his Web browser because he wants to access the website at the company, QuickExample. He types the name of their website: http://www.example.com. This request causes the following (see Figure 1-1) to occur:
1. John's workstation sends a request to his DNS server asking if it knows the IP address of www.example.com.
2. John's DNS server checks its database and finds that www.example.com is a pseudonym for IP address 192.168.1.4.
3. The DNS server sends the IP address 192.168.1.4 back to John's browser.
4. The browser uses the IP address to locate the website.
5. The browser displays QuickExample's home page on John's monitor.
John is able to reach QuickExample's website because his DNS server knows the IP address of www.example.com. His DNS server learned the address of QuickExample's website by performing a search through the DNS domain name space. DNS was designed as a tree structure, where each domain (node in the tree structure) is named and can contain subdomains. The top-most node of the tree is the DNS root node (.), under which there are subdomains such as com (commercial), edu (education), gov (government), and mil (military) (see Figure 1-2).
Each domain has a unique name and each of the subdomains has a unique name within their domains. The fully qualified domain name (FQDN), which includes the names of all network domains leading back to the root, is unique for each host on the Internet. The fully qualified domain name for the sample domain is example.com., which indicates that the domain is example, and its parent domain is com, whose parent domain is "."
When John's workstation requests the IP address of the website www.example.com, John's DNS server does the following (Figure 1-3):
1. John's DNS server checks its database and finds that www.example.com is not part of its domain.
3. The dot DNS server directs the query to one of the DNS name servers for the .com domain. The .com DNS name server knows about the subdomains of the .com domain.
4. The .com DNS server responds that example.com is one of its subdomains, and responds with example.com's name server IP address.
5. John's DNS server asks example.com's name server for the location of the Web server www.example.com.
6. Example.com's name server tells John's DNS server that www.example.com's IP address is 192.168.1.4.
7. John's DNS server sends this address to John's Web browser. The browser can then connect to the IP address 192.168.1.4.
The QuickExample company was able to have a website that John could reach because they had registered their domain with the InterNIC, and they were using valid IP addresses. The InterNIC is the official source of all network numbers. They assign network numbers to Internet-connected networks, and ensure that no ranges overlap.
The QuickExample company had applied to the InterNIC to register its domain name, and the company also was entered into the .com's DNS name server database.
QuickExample also requested a network number, which defines a range of IP addresses. In this case, the network number is 192.168.1.0, which is composed of all the IP addresses in the range 192.168.1.1 through 192.168.1.255.
The domain name space is divided into areas called zones. Zones start at a domain and extend down to the leaf domains or to domains where other zones start. Zones usually represent administrative boundaries.
A zone is a point of delegation in the DNS tree. It contains all names from a certain point downward except those for which other zones are authoritative. Authoritative name servers can be asked by other DNS servers for name-to-address translation. Within an organization you can have many name servers, but only the authoritative ones can be queried by the clients across the Internet. The other name servers only answer internal queries.
The QuickExample company has registered its domain, example.com. They have established three zones: example.com, marketing.example.com, and finance.example.com. QuickExample has delegated authority for marketing.example.com and finance.example.com to the DNS servers in the Marketing and Finance groups within the company. If someone queries example.com about hosts in marketing.example.com, example.com directs the query on to the marketing.example.com name server. In Figure 1-4, the example.com domain includes three zones, and the example.com zone is only authoritative for itself.
QuickExample might have chosen not to delegate authority for its subdomains. In that situation, the example.com domain would consist of the example.com zone, which is also authoritative for the subdomains marketing and finance (Figure 1-5). Consequently, all outside queries about marketing and finance would be answered by the example.com name server. For more information about zone delegation, see the "Delegating Subzones" section in the "Configuring DNS" chapter.
DNS uses a client/server model, which means that the DNS servers contain information about a portion of the DNS database and they make this information available to clients that query the DNS name server across the network. DNS name servers are programs that run on a physical host and store information about zones. As administrator for a domain, you set up a name server that contains the database with all the resource records describing the hosts in your zone or zones (Figure 1-6). For more information about Resource Records, see the "Resource Records" appendix.
The DNS servers provide name-to-address translation, or name resolution. They interpret the information in a FQDN to find its specific address. If a local name server does not contain the data requested in a query, it asks other name servers until it finds the specific name and address it needs. Local name servers contain information about many commonly requested names because name servers cache (save) domain name space information that is returned from queries.
Each zone must have one primary name server that loads the zone contents from a local database, and a number of secondary servers, which load the zone contents by fetching a copy of the database from the primary server (Figure 1-7). This process of updating the secondary server from the primary server is called a zone transfer.
When you configure a DNS zone, you specify primary and secondary name servers, however, the definition is meaningful only in respect to their roles. A server can be a primary for some zones and a secondary for others, or it can be only a primary, or only a secondary, or it can serve no zones and just answer queries by means of its cache.
Although all servers are caching servers, because they save the information received until the data expires, a caching-only server is a server that is not authoritative for any zone. This server answers internal queries and asks other servers, who have the authority, for the information needed. Sites create caching-only servers to relieve the traffic on the authoritative servers. Instead of every query being directed at the authoritative server, the internal queries can be handled by the caching-only server.
As you configure Network Registrar's DNS name server, you specify what role you want the name server and each zone to perform: the role of a primary name server for the zone, a secondary name server for the zone, or a caching-only server.
For more information about configuring a primary name server, see the "Configuring a Zone's Primary Name Server" section in the "Configuring DNS" chapter. Information about configuring a secondary name server can be found in the "Configuring a Zone's Secondary Name Server" section in the "Configuring DNS" chapter. For more information about configuring a caching-only server, see the "Configuring a Caching-Only Server" section in the "Configuring DNS" chapter.
The DNS can easily resolve names to addresses by searching though its database for the correct address, because all the data is indexed by name. Finding a domain name when you only know the address, however, would require a search of every domain name in the tree.
The DNS solves this problem by supporting a domain name space that uses addresses as names. In the Internet's domain space, this portion of the name space is the in-addr.arpa domain. Within that domain there are subdomains for each network based on the network number. For consistency and natural grouping, the four octets of a host number are reversed. When you read the IP address as a domain name it appears backwards, because the name is read in leaf-to-root order.
For example, QuickExample's example domain's network number is 192.168.1.0. QuickExample's reverse zone is 1.168.192.in-addr.arpa. If you only know the DNS server address (192.168.1.1), the query to the inverse domain would find the host entry 1.1.168.192.in-addr.arpa that would map back to example.com (Figure 1-8).
These activities are time-consuming and error prone. For these reasons, DHCP was created. DHCP frees you from the burden of individually assigning IP addresses. It was designed by the Internet Engineering Task Force (IETF) to reduce the amount of configuration required when using TCP/IP. DHCP allocates IP addresses to hosts, and can provide all the parameters hosts require to operate and exchange information on the Internet network to which they are attached.
DHCP localizes TCP/IP configuration information and manages the allocation of TCP/IP configuration information by automatically assigning IP addresses to systems configured to use DHCP. Thus, you can ensure that hosts have Internet access without having to configure each host individually.
DHCP was designed to make TCP/IP easier to install on large networks with little user intervention required. DHCP accomplishes much of this by shifting the configuration from the individual workstation level to that of global address pools at the server level.
After Beth's workstation (bethpc) has been configured to use DHCP, the following occurs when she first starts her workstation (Figure 1-9):
1. Her workstation automatically requests an IP address from a DHCP server on the network.
3. Before the IP address's lease expiration time, bethpc attempts to renew its lease. It will continue to use the lease right up to its expiration.
As long as the DHCP server has the correct configuration information, none of the workstations or servers using DHCP will ever be configured incorrectly. Therefore, there is less chance of incurring difficult-to-trace network problems that can result from incorrectly configured workstations and servers.
Leases are grouped together in a pool, called a scope, which defines the set of IP addresses that can be lent to requesting hosts. A lease can be reserved, which means that the host always receives the same IP address, or dynamic, which means that the host receives the next available lease in the scope.
At the QuickExample company, the DHCP server has been configured to lease IP addresses 192.168.1.100 to 192.168.1.199 (Figure 1-10).
If you are concerned about running out of IP addresses for a particular subnet, you can improve utilization of IP addresses by making the lease times short, such as a few hours, although this technique is not recommended if you are using dynamic DNS. This will increase the rate at which leases become available and give users an opportunity to acquire a lease.
If you do not plan to have more network devices than configured addresses for the scope, you can define long lease times, such as 1-2 weeks, to reduce network traffic and DHCP server load. For more information about leases, see the "Configuring Policies" section in the "Configuring DHCP" chapter.
A scope contains a set of IP addresses for a particular subnet along with a variety of configuration parameters that tell DHCP how to operate on these addresses. You must define at least one scope for each subnet on which you want a DHCP server to supply IP addresses to DHCP clients. For more information about scopes, see the "Configuring DHCP Scopes" section in the "Configuring DHCP" chapter.
Policies are especially useful if you have more than one scope at your site. You can create policies that apply to all the scopes on the current server, or create a policy for a selected scope. Policies are a convenient way of ensuring that the DHCP server supplies all the correct options for scopes and alleviates the task of specifying the information separately per scope.
In practice you usually need to specify a router for each policy, which means that you need a policy for each scope, or an extension that specifies the router for the subnet. For more information about policies, see the "Configuring Policies" section in the "Configuring DHCP" chapter. For more information about DHCP extensions, see the Network Registrar CLI Reference Guide.
The difference between scopes and policies (Figure 1-11) is that scopes contain information about addresses, such as which address is leasable, whether or not to ping the client before offering a lease, and other configuration options. Policies, on the other hand, contain configuration information for clients, such as the duration of the lease and the address of the local DNS server.
Although DHCP frees you from the burden of distributing IP addresses, it still requires manual updating of the DNS server with the names and IP addresses of the DHCP hosts. Dynamic DNS update automates the task of keeping the DNS database of names and IP addresses current.
Network Registrar's dynamic DNS update allows the DHCP server to tell the corresponding DNS server when a name-to-address association has been created or changed. When a host obtains a lease for an address, Network Registrar tells DNS to add the host information. When the lease expires, or when the host gives up a lease, Network Registrar tells DNS to remove the association.
In normal operation you do not have to reconfigure DNS, no matter how frequently clients' addresses change through the use of DHCP. Network Registrar uses the host name that the client workstation provides. You also can have Network Registrar create names for clients who have not provided names.
For more information about using dynamic DNS update see the "Enabling Dynamic DNS Updates" section in the in the "Configuring DNS" chapter and the "Defining Dynamic DNS Update Support" section in the "Configuring DHCP" chapter.
In the sample company, QuickExample, the administrator has created a scope on the DHCP server and allocated 100 leases (192.168.1.100 to 199) to the workstations on the network. Each workstation is named after its owner. The administrator also has configured the DHCP server to use dynamic DNS update and associated it with the correspondingly configured DNS server. The administrator does not need to enter any of the workstations into the DNS server's database.
Monday morning, Beth (user of bethpc) logs in and wants to use the Internet to access a website. After her machine starts, if it does not have a lease, it broadcasts a request for an Internet address. This request causes the following to occur (Figure 1-12):
1. The DHCP server gives bethpc the next available IP address, which is 192.168.1.125.
2. The DHCP server updates her DNS server with the host name and IP address (bethpc 192.168.1.125) and updates her inverse DNS name server.
Beth is able to reach the website. In addition, programs that need to translate the name of Beth's machine to her IP address or vice versa can query the DNS server.
Later that day, Beth learns that she needs to travel out of town. She turns off her computer. Her IP address is still leased to her computer and expires, according to the DHCP policy, after three days. When the lease expires, the following occurs (Figure 1-13):
1. The DHCP server acknowledges that the IP address is now available for other users.
2. The DHCP server updates the DNS server. The DNS server no longer contains information about bethpc or its IP address.
When Beth returns on Friday from her trip, she starts her workstation and the following occurs:
1. Her workstation sends out a broadcast for an IP address.
2. The DHCP server checks to see if her previously leased IP address is available. If it is, the server leases it to bethpc. If it is not, it leases her a new IP address and updates the DNS server.
3. Beth, in either case, has an IP address, and can use the Internet. She does not know, nor does she need to know, what her IP address actually is.
You can use Network Registrar's client or client-class facility to provide differentiated services to users accessing a common network. You can group your user community based on administrative criteria, and then ensure that each group of users receives the appropriate class of service when they access the network.
One way you might use Network Registrar's client-class facility is to allow visitors access to some, but not all, of your network.
For example, when Joe, a visitor to QuickExample, attempts to attach his laptop computer to example.com's network, Network Registrar recognizes his laptop as foreign. QuickExample has created a class of clients who are known to Network Registrar and who have access to the entire network, and another class of client who are visitors and thus have access to only a subset of the network.
If Joe, as a visitor, needs more than the standard visitor's access, he can register his laptop with the Network Registrar system administrator who will add him to another client-class with the appropriate class of service. For more information about client-class, see the "Client-Class" section in the "Configuring DHCP" chapter.
The three components of Network Registrar, DNS servers, DHCP servers, and dynamic DNS update, work together to allow you to easily provide your user community with IP addresses:
The remaining chapters in this document describe how to configure and maintain the Network Registrar suite of servers.
Posted: Thu Jul 13 11:28:35 PDT 2000
Copyright 1989-2000©Cisco Systems Inc.