|
|
This chapter introduces the Cisco DNS/DHCP Manager (CDDM) and the Cisco Server Suite 1000 (CSS1000).
The CDDM is a suite of servers and tools that:
The cornerstone of the CDDM is the Domain Name Manager (DNM) Server, which lets you manage zone data - typically, 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 when they start and propagate to "secondary" name servers via zone transfers (see Figure 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 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 must not be advertised as a name server with NS (name server) records because it does not 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.3, 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 3, Server 1 is running the DNM server configured to provide zone transfers over port 705. The coresident DNS server 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 Server 1 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 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 (see Figure 4).
The DNM Browser:
On UNIX platforms, the DNM Browser is an X client. On Windows NT, 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. When the DHCP/BootP server starts, it automatically updates the DNM server with IP addresses and host names for dynamic hosts such as diskless workstations and mobile computers. The DHCP/BootP server also tells the DNM server to create a special DHCP-only subdomain for the dynamic hosts. If the DHCP-only subdomain already exists, the DNM server deletes the old domain and creates an entirely new domain using the new DHCP information.
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.
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 5 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 can update DNS when the DHCP/BootP server starts. Note that the DHCP/BootP server can only update the DNM server with information from its DHCP database. The DHCP/BootP server does not propagate information from its BootP database to the DNM server.
Traditionally, DHCP and BootP databases are managed independently of the DNS (see Figure 6).
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.
The Cisco DHCP/BootP server eliminates the need to manually coordinate the DNS with your DHCP or BootP databases by dynamically updating zones dedicated to your DHCP clients. Figure 7 illustrates how to use a Cisco DNM server to automatically link a DHCP database with an authoritative name server.
The DHCP/BootP server supports a new "ub" tag which lets you define which database entries it needs to propagate to DNS via the DNM server. When the DHCP/BootP server starts, the DHCP/BootP server deletes the dynamic zone, and then rebuilds it based on the current DHCP and BootP databases. Note that DHCP leases IP addresses to other hosts when existing hosts move from one net to another. This may cause stale information to persist in the DNM database for a short time.
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, BootP forwarding is controlled by the IOS command ip helper-address. 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 on the primary subnet, 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 address using the new "sc" (subnet continuation) 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" tags must appear after the entry for the primary subnet 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.
All CDDM servers are controlled by a "master" server called NetControl. You can use NetControl alongside the master server provided with your computer's operating system (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 NetControl simultaneously. For example, to use the Cisco DNS server on HP/UX, you must disable named (the DNS server supplied with HP/UX).
The Cisco DNS/DHCP Manager and Cisco Server Suite 1000 include the following "supporting" servers:
The Cisco DNS/DHCP Manager and Cisco Server Suite 1000 provide a configuration utility called the Service Configuration Manager (SCM) that lets you configure and manage all CDDM servers that run under NetControl. The SCM provides a graphical interface to configuration parameters that you would otherwise have to modify manually with a text editor.
On UNIX platforms, the SCM is an X client. On Windows NT, the SCM is a native Windows application. 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 SCM 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.
|
|