|
|
This chapter introduces the Cisco DNS/DHCP Manager (CDDM) and the Cisco Server Suite 1000 (CSS1000).
It contains the following sections:
The CDDM media contains the Cisco Server Suite 1000 (CSS1000), which is a subset of the CDDM that contains all components of the CDDM except the Domain Name Manager (DNM) server. This guide only refers to CSS1000 to specify systems that do not have all CDDM components installed.
The cornerstone of the CDDM is the Domain Name Manager (DNM) Server, which lets you manage zone data--primarily, host names and addresses--dynamically from across a network.
Traditionally, zone data originates as ASCII text files called "zone files," which primary name servers read on start-up and propagate to "secondary" name servers via zone transfers (see Figure 1-1).
Many network managers choose to advertise only their secondary name servers, and dedicate their primary name servers to perform zone transfers. The CDDM supports this approach by assigning zone transfer and name resolution to separate servers.
The DNM server takes over the role of zone transfers (see Figure 1-2) but leaves the role of name resolution to DNS servers. DNS servers configured as "secondary" name servers can obtain zone transfers from a DNM, but the DNM server must not be advertised as a name server with NS (name server) records because it does not resolve names.
Because the CDDM contains both the DNM and DNS servers, CDDM systems can operate as primary name servers. If you do not run the Cisco DNS server on a CDDM system, the system can still provide zone transfers like a primary name server, but it cannot resolve names.
Every time you modify the DNM server's database, the DNM server increments the appropriate zone serial numbers so that the corresponding secondary name servers can detect a change in the zones for which they are authoritative and request zone transfers.
Normally, you could not run a DNM server and a DNS server on the same host because both servers listen on port 53 for zone transfer requests. The CDDM, however, includes an enhanced DNS server that can request zone transfers over any port. The Cisco DNS server is based on BIND 4.9.5, so you can both use existing zone files and receive new zone data from your DNM server.
If you configure the DNM server to perform zone transfers on port 705, any host running the Cisco DNS server can obtain zone transfers on that port, and DNS resolvers can still obtain name service from the DNS server running on port 53. For example, in Figure 1-3, Server 1 is running the DNM server configured to provide zone transfers over port 705. The DNS server on Server 1 is configured to be secondary for zones in the DNM database and obtains zone transfers on port 705 for those zones. Because Server 1's DNM server only performs zone transfers on port 705, Server 2's DNS server must also be configured to obtain zone transfers from the DNM server on Server 1 on port 705. If Server 2 can only obtain zone transfers via port 53, it will obtain zone transfers via the DNS server on Server 1. Server 2 continues to resolve names when requests arrive on port 53 even if it receives zone transfers on port 705.
Editing zone files manually can take a long time, and making mistakes along the way can cause DNS servers to stop working. Typical mistakes include syntax errors and incorrect, unnecessary, or missing entries.
The DNM server maintains a single database instead of multiple zone files. Instead of editing the database manually with a text editor, you can manage the DNM server's database via a DNM client program. The DNM client and server communicate via a proprietary, operating system-independent protocol so you can manage any DNM server from any host running a DNM client.
The CDDM and CSS1000 include a DNM client called the DNM Browser which simplifies everyday DNS management tasks such as adding new hosts or changing host addresses and lets you configure DNM servers from remote hosts. The DNM Browser presents a view of the domain name space in an outline-style layout that makes it easy to browse through 
domains.
The DNM Browser:
The DNM Browser communicates with DNM servers over TCP/IP, so you can manage DNS names from remote hosts. On UNIX platforms, the DNM Browser is an X client. On Windows NT and Windows 95, the DNM Browser is a native Windows application. You can install the DNM Browser without installing the CDDM or CSS1000. The DNM Browser does not require a license key so you can install the DNM Browser on multiple hosts.
The Cisco DNS/DHCP Manager includes a DHCP/BootP server which can be configured to behave as a DNM client. You can configure the DHCP/BootP server to automatically update the DNM server with IP addresses and host names for dynamic hosts such as diskless workstations and mobile computers when DHCP clients receive leases. The DHCP/BootP server also tells the DNM server to create a special DHCP-only subdomain for the dynamic hosts.
To manage a DNM server's database from a DNM client, you must have a DNM server account. When you connect to a DNM server you must supply a valid user name and password. If you use the DNM Browser, you enter your account information when prompted. If you use the DHCP/BootP server to manage the DNM server, you must configure the DHCP/BootP server with valid account information using the Cisco Service Manager (CSM).
For information on creating DNM user accounts, see the Cisco DNS/DHCP Manager Administrator's Guide.
Your site may require a relatively low number of DNM servers to serve your site's DNS and DHCP/BootP servers. To take full advantage of Cisco's DNS and DHCP servers, Cisco offers the Cisco Server Suite 1000, which provides all of the CDDM's features except for the DNM server.
You can install Cisco Server Suite 1000's enhanced TCP/IP services and manage DNS from your UNIX and Windows hosts, while maintaining a central DNS database on your Cisco DNS/DHCP Managers. Figure 1-4 illustrates how you can combine CDDM and CSS1000 systems.
You can install either the Cisco Server Suite 1000 or the CDDM from the Cisco Server Suite distribution. You must have a license for each CPU on which you plan to run either product.
By configuring the Cisco DHCP/BootP server to behave as a DNM client, you automatically coordinate names in DNS with names in the DHCP/BootP server's database.
Traditionally, DHCP and BootP databases are managed independently of the DNS (see Figure 1-5).
With most DHCP and BootP servers, every time you add a host entry to the DHCP database, you must also add corresponding domain names for the host: one in the parent domain and another in the in-addr.arpa domain. Failure to update DNS when you update a DHCP database will prevent hosts from reaching DHCP clients by host name. Note that it takes time to propagate new names to DNS servers because zone transfers do not take place automatically when you update your DNM server.
The Cisco DHCP/BootP server and DNM server eliminate the need to manually coordinate the DNS with your DHCP or BootP databases by dynamically updating zones dedicated to your DHCP clients. Figure 1-6 illustrates how to use a Cisco DNM server to automatically link a DHCP database with an authoritative name server.
The DHCP/BootP server supports an Update DNS parameter (ub option tag), which lets you define the database entries it needs to propagate to DNS via the DNM server. For example, if you have a set of "static host" entries that map names and IP addresses to specific hosts, identified by their hardware (MAC) addresses, you enable the Update DNS parameter in each entry.
In addition to enabling the Update DNS parameter (ub option tag), you must:
The DHCP/BootP server only accommodates a single DNM server, even if it manages hosts in multiple domains. If your network requires multiple DNM servers, you must configure a unique DHCP/BootP server for each DNM server. Make sure that the DNM server is authoritative for both your dynamic host names and the corresponding addresses via the inverse domains under the in-addr.arpa domain.
 | Caution If your network requires more than one DHCP/BootP server, make sure they each use a separate, unique domain. |
The DHCP/BootP server lets you choose the name of a domain to which it will add domain names for DHCP clients. For example, if your domain is yoyodyne.com, you might reserve the domain, mobile.yoyodyne.com, for DHCP clients. All clients then acquire host names such as pc1.mobile.yoyodyne.com when they accept DHCP leases from your DHCP/BootP server.
The DHCP/BootP server can support only one dynamic domain, but the DNM server can accommodate multiple DHCP/BootP servers if they are configured for different dynamic domains.
**before**Avoid adding names to a dynamic domain by any means other than by the DHCP/BootP server. If you manually add names to a dynamic domain, the DHCP server may delete them, depending on how you configure it to choose names for DHCP clients (see "Specifying How the DHCP/BootP Server Chooses Names for DHCP Clients"). @@before@@ | Caution **after**Avoid adding names to a dynamic domain by any means other than by the DHCP/BootP server. If you manually add names to a dynamic domain, the DHCP server may delete them, depending on how you configure it to choose names for DHCP clients (see "Specifying How the DHCP/BootP Server Chooses Names for DHCP Clients").@@after@@ |
The DHCP/BootP server offers two ways to specify names for dynamic hosts:
The DHCP/BootP server lets you create a pool of IP addresses that spans multiple logical subnets, using the sc (subnet continuation) option tag, a functional extension of DHCP. This option tag is useful when you need to pool addresses from different networks, such as two Class C networks or a Class B and a Class C network.
For example, suppose you need to offer a pool of 400 addresses and your network is composed of two Class C networks. The sc option tag lets you combine the two subnets and put all 400 addresses in the pool.
Most IP routers let you forward DHCP/BootP requests received on a local interface to a specific host. This forwarding feature is often called "BootP helper" or "BootP forwarder." On Cisco routers, you can control BootP forwarding with the Cisco IOS commands ip helper-address and set dhcp relay. When routers forward DHCP/BootP requests, they place their own IP addresses in the DHCP/BootP packet in a field called "GIADDR." The router inserts the IP address of the interface (called the "primary" interface) on which it received the original DHCP/BootP request. The DHCP/BootP server uses the address in the GIADDR field to determine the IP subnet from which the request originated so it can determine which pool of addresses to use before allocating an IP address to the DHCP/BootP client.
When you run multiple IP network numbers on the same physical network, you typically assign multiple IP addresses to a router interface. Because the DHCP/BootP server only allocates addresses based on the GIADDR field, and because it only receives the router's primary address in the GIADDR field, you must configure the DHCP/BootP server to associate the other network addresses with the primary subnet using the Subnet Continuation parameter (sc option tag). You can specify an arbitrary number of secondary address pools in the DHCP configuration, to make all addresses in the primary and secondary entries available to DHCP clients on the corresponding network segments. DHCP entries that contain sc option tags must appear after the entry for the subnet they specify in the DHCP configuration editor's entry list.
You must also add sc option tags to entries for "static" hosts (that is, entries for hosts with specific hardware addresses) on subnets that are part of the conceptual subnet. Static host entries require sc option tags to indicate to the DHCP server that the static IP address is actually on the network segment that the GIADDR field indicates.
In addition to the DNS, DNM, and DHCP servers, the CDDM and CSS1000 include several servers that support network administration tasks (see Table 1-1).
The CDDM includes a Master Server which controls all CDDM servers. Like the inetd server on UNIX systems, the Cisco Master Server determines whether servers start automatically, the ports on which they listen for service requests, and other configuration parameters.
The Cisco Master Server runs independent of the master server provided with your computer's operating system. On Solaris, HP-UX, and AIX systems, the Cisco Master Server controls the CDDM services, while the native inetd continues to manage the native services. Similarly, on Windows NT systems, the Master Server runs independent of the Windows Service Control Manager.
You can continue to manage services under the native master server (for example "inetd" on UNIX platforms), but you must make sure no servers requiring the same port are running under the master server and Cisco's Master Server simultaneously. For example, to use the Cisco DNS server on Solaris, HP-UX, and AIX, you must disable named (the DNS server supplied with those operating systems).
The Cisco DNS/DHCP Manager and Cisco Server Suite 1000 provide a utility called the Cisco Service Manager (CSM) which lets you:
On UNIX platforms, the CSM is an X client. On Windows NT, the CSM is a native Windows application. The CSM includes a list of all available servers and a configuration editor screen for each server. For details on managing and configuring the CDDM servers, see the Cisco DNS/DHCP Manager Administrator's Guide.
Ultimately, you will configure CDDM servers with the CSM and continue to configure all other native servers with the tools provided by your operating system.
If your network already relies on a server that CDDM replaces, you probably will not want to stop the existing server until the new server is configured and tested. To simplify the migration from existing servers, you can configure CDDM servers to either use existing configuration files (for example, standard NTP configuration files), or import data from existing files (such as BIND zone files) before saving the data in a new format.
|
|