The Ultimate Windows Server 1002003 System Administrators Guide [Electronic resources] نسخه متنی

NAMING SERVICES AND IP ASSIGNMENTS

Network naming services were developed to correlate numeric addresses best understood by computers and natural language names that are provided to the same network device. Windows Server 2003 embraces several of them. The DNS is an integral part of Windows .NET and, especially, Active Directory implementations. It has evolved as the primary naming service for the UNIX OS and the Internet. Because of Microsoft's decision to make Windows Server 2003 Internet compatible, DNS has replaced the Windows Internet Name Service (WINS) as the default name-resolution technology.

NOTEA vulnerability of early implementations of DNS centered on security. With Windows Server 2003, the DNS server provides basic compliance with the IETF standard DNS Security Extensions protocol as defined in RFC 2535. The DNS server may now store the record types (KEY, SIG, and NXT) defined in the IETF standard. These records respond to the queries according to RFC 2535. The server does not provide full compliance and does not perform the cryptographic operations specified in RFC 2535. The feature is activated through the DNS snap-in.

This section examines DNS and other naming services and related technologies, including DHCP and the Microsoft WINS. DHCP dynamically assigns IP addresses. While technically not a naming service, it resembles one when deploying networks.

Domain Name System Conventions

The role of DNS is to match a Fully Qualified Domain Name (FQDN) with its IP address. FQDNs are organized in a top-down fashion, forming a hierarchy from general to specific (Figure 12.6). This hierarchy is read from right to left and identifies a specific host in a subdomain. For example, the fully qualified host name host.EntCert.com identifies host in the EntCert subdomain. The root domain, indicated by the period on the far right, is usually omitted from the FQDN for normal use, but is required for DNS configuration files. The com portion is, in this example, the highest subdomain under the root domain, indicating a commercially assigned name.

In our example (Figure 12.6), we have a real company name and the registered domain name of EntCert.com. Enterprise Certified is a private corporation that requested allocation of this subdomain name from the Network Information Center. The host portion is a host within the EntCert subdomain that is assigned an IP address for one of its network interfaces. This fully qualified host name can be used to reference this IP address by accessing a domain name server.

Understanding DNS

The DNS system is composed of clients and servers. DNS servers maintain forward and reverse records for their zones. The forward lookup zone is used to find the IP address of a host using an FQDN; the reverse lookup zone does just the opposite and uses an IP address to locate the subject's FQDN. A configured DNS client maintains the IP address of the DNS server for its zone. When the client attempts to resolve a fully qualified name, it checks three sources:

Local cache obtained from previous queries. These entries are valid for the Time-to-Live (TTL) period defined in the query response.

Lmhosts, or host files that contain host-name-to-address mappings that remain on the hard disk when the client is shut down.

DNS server.

Once the client has attempted to find a locally valid IP address for the sought-after host name, it will query its DNS server. The server attempts to resolve the client's query using several strategies:

If the query result is found in the local DNS zone, the server is supporting the host and can respond with an authoritative answer.

If the result is not found in the local zone, the server references its local cache for a recent query containing the desired name mapping.

If the local resources fail to provide the needed mapping, depending on its configuration, the DNS server will resolve the client's query in one of three ways:

- perform a recursive search for client's query

- forward the query to another DNS server to perform a recursive search

- refer another DNS server to client's query and let the client perform a recursive search

DNS Recursion

A recursively configured DNS server accepts queries from a client and follows referrals, using the DNS hierarchy, to resolve the client's request. It does so by sending an iterative request to the root "." DNS server. (An iterative request instructs a server to provide a best guess or referral to another server when the query is not known.) The root server then refers the local DNS server to the next authoritative name server in the query's namespace. For example, in order to resolve the FQDN name host.Entcert.com from the "clientcompanydomain.com", the client company's local DNS server will query the "." root DNS server and be referred to the ".com". DNS server (Figure 12.7). Since a record exists for the ".com" server in the "." (root) server's database, its response is considered authoritative. The local DNS server queries the "com". DNS server and is referred to the "EntCert.com". DNS server. This server offers an authoritative query response and returns the host.EntCert.com name-to-IP-address mapping to the local DNS server. The client company's DNS server then returns the response to the client. The client uses the IP address to establish a connection with the remote server.

STANDARD VERSUS DIRECTORY INTEGRATED ZONES

The Windows Server 2003 DNS server may store zone information in two distinct formats: Active Directory integrated and standard zone format as a text file. Active Directory integrated is available when you install the DNS server along with the Active Directory. When this option is installed on a domain controller, the DNS information is updated on other DNS servers on domain controllers using the Active Directory's multimaster update techniques. Secondary zones (used with the standard zone format to back up DNS information and offload client queries) are supported but not required with Active Directoryintegrated DNS server zones. Additional domain controllers installed with the Active Directoryintegrated DNS server also act as a primary source for the zone.

In order to back up or offload client requests to one Active Directoryintegrated server, simply install an Active Directoryintegrated DNS server on another domain controller. Active Directory replication will ensure that the two servers have equivalent DNS records, so clients may contact any of the domain controllers and receive up-to-date DNS information. Additionally, the Active Directoryintegrated zones support ACLs to restrict access to the zone container so that a particular client can be prevented from performing dynamic updates. For more information on dynamic updates, see the DHCP section.

The standard zone format does not support ACLs and requires secondary zones to offload client queries and back up the DNS database. Secondary zones support their own replication strategy, as discussed in the coming sections. The standard zone is stored in a text file in the %SystemRoot%\system32\dns folder.

INSTALLATION WITH THE ACTIVE DIRECTORY

Active Directory installation, demonstrated in Chapter 7, requires DNS installation. The Active Directory may be fully installed without DNS on the server by referencing another DNS server in the domain. DNS may be installed later on such a domain controller using the Configure Your Server tool.

Open the Configure Your Server tool by selecting Start Programs Administrative Tools Configure Your Server. Once the wizard appears, click Next. Click Next again to the Preliminary Steps window.

Select DNS server from the Server Role window and click Next. Click Finish.

The Configure a DNS Server Wizard should appear. Click Next.

In the Select Configuration Action window, select Create forward and reverse lookup zones, then click Next. (forward lookup zone now, then click Next.

Select Primary zone (Figure 12.9). Ensure that the Store the zone in Active Directory box is checked, then click Next. This will make the DNS server integrated with Active Directory.

Replicate to all domain controllers by selecting All domain controllers in the Entcert2.com Active Directory domain.

Enter the full DNS name for the new DNS zone and click Next. (Figure 12.10).

Select Allow only secure dynamic updates and click Next.

Select Yes, create the reverse lookup zone now and click Next.

Select Primary zone selection. Ensure that the Store the zone in Active Directory box is checked, then click Next.

Select All Domain Contollers selection and click Next.

Enter the network address of the zone for reverse lookup, then click Next. (Figure 12.11)

Select the Dynamic Update preference and click Next.

Do not permit query forwarding for this example and click Next.

Click Finish.

The new reverse lookup zone should be configured with the new DNS server as the only member. Add new members to both the forward and reverse zones by right-clicking the Forward Lookup Zone domain folder and selecting New Host (A). Check the Create associated pointer (PTR) record box to simultaneously create the reverse lookup entry (Figure 12.12). Or, add reverse lookup entries individually by right-clicking the reverse zone node and selecting New Pointer (PTR) (Figure 12.13). Once the host has been added to the DNS database, the host's DNS client must be configured to the new DNS server.

CLIENT CONFIGURATION

From the new client host, select Start Settings Network Connections and double-click the network interface to handle DNS requests.

Click Properties. Select Internet Protocol (TCP/IP) and click Properties. Enter the new DNS server's IP address in the Preferred DNS server field (nslookup host name.

The following should appear:

Server: servername.domainname
Address: xxx.xxx.xxx.xxx
Name: hostname.domainname
Address: xxx.xxx.xxx.xxx

DNS ZONES AND FAULT TOLERANCE

When the first DNS server is installed to manage a namespace, it is configured as the primary DNS server for the domain. The namespace it maintains defines the server's responsibility. As subdomain names are added, new zones may be created to maintain them. These new zones may be configured with new DNS servers to maintain each one's name-to-IP-address mapping information. For example, if the Enterprise Certified Corporation were to extend its namespace with new branches such as Engineering and Marketing, administration of the new branches could be delegated to new zones and respective servers. The Engineering.EntCert.com and Marketing.EntCert.com domain names could be used to define the two new zones, each of which would have its own database to maintain IP addresses mapped in its namespace (Figure 12.15).

Replication

Each zone may set up secondary servers to back up the primary server in the event of failure. The secondary server synchronizes its own DNS database by sending update requests to its master server, which may be the primary DNS server for the domain or another secondary server (Figure 12.16). The secondary server update request may be for either an incremental or an all-zones transfer. A brand-new secondary server will request an all-zones transfer to completely update its database. After initialization, the secondary server initiates only incremental transfers, which convey only zone changes to the database, cutting down on network traffic and system resource use.

A zone transfer is initiated for several reasons:

The secondary server's refresh timer expires (default 1 hour).

The master server notifies members of a zone change.

The secondary DNS service is started (during either bootup or installation).

A zone transfer is manually initiated from a DNS snap-in for a secondary server.

Secondary DNS Server Management

The secondary DNS server installation is similar to the primary installation. Here are the steps required:

Install the Windows Server 2003 DNS server from the Start Programs Administrative Tools Configure Your Server tool. You can also install it from Control Panel Add or Remove Programs. Start the Windows Components Wizard and select Networking Services. Click Details to bring up subcomponents for networking services. Select the Domain Name System (DNS) and click OK.

Once the Windows Server 2003 DNS server components have been installed, open the DNS snap-in tool from the new DNS server. Any other DNS server can be managed from one system's DNS snap-in by right-clicking the DNS node and selecting Connect to DNS Server. Enter the name of the desired server to administer and click OK. The new server should appear as a new node under the DNS node.

Right-click the Forward Lookup Zones node and select New Zone. Click Next to start the New Zone Wizard.

Select Secondary zone and click Next (Figure 12.17).

Enter the name of the DNS zone the secondary server is supporting and click Next.

Enter the IP address of the new secondary DNS server's master. A full DNS database transfer will be performed from the master server (Figure 12.18). Click Add and click Next. Click Finish to complete the secondary zone creation.

The finished forward lookup zones defined on the master DNS server should be replicated on the secondary DNS server. The easiest visual way to identify the newly created secondary zone is to right-click the new zone and select Properties. On the General tab, the Type field should read Secondary (Figure 12.19).

Notification

Secondary DNS servers must initiate the replication sequence to maintain current record sets. DNS notification, as defined by RFC 1996, allows master DNS servers to inform secondary servers that updates have been made to the DNS database. Once the secondary servers receive this notification, they may request zone transfers. Notification is available to primary DNS servers and may be configured as follows:

Right-click a primary zone and select Properties.

Select the Zone Transfers tab and click Notify.

Ensure that Automatically notify is checked.

Configure a notification list in either of the following ways (Figure 12.20):

- Select Servers listed on the Name Servers tab and add servers that require notification to the Name Servers tab.

- Select The following servers option and add IP addresses to this local list.

Both methods allow notifications to be designated to specific servers. The Zone Transfers tab (Figure 12.21) also permits restrictions to zone transfer to limit which DNS servers may be allowed to request zone transfers. Not only will the specified servers receive notification of record updates, but they also can be set as the only servers permitted to make transfer requests.

FORWARDING

Because the recursive search creates network traffic and consumes system resources, forwarding allows one DNS server to forward name queries to another DNS server. Thus, a network may offload name resolution responsibility to a particular server or set of servers with high bandwidth to the Internet, limiting intensive searches over slow or expensive connections. When requests are forwarded to one server, the system's cache becomes more extensive, enhancing its ability to resolve name queries locally. Ideally a company's ISP can provide a target for the network's forwarding DNS server and offload name query resolution to the Internet.

To forward a DNS server's name queries to another server, follow these steps:

Right-click the DNS server node from the DNS snap-in and select Properties.

Select the Forwarders tab. Type the IP address of the designated forwarder in the box under Selected domain's forwarder IP address list and click Add (Figure 12.22).

The Number of seconds before forward queries time out specifies how long the DNS server will wait for a response from the designated forwarder. If this forwarder does not respond, the server will try the next one on the list. For a forwarder to be attempted more than once, its IP address must be entered in the list multiple times. Once this list has been depleted, with no resolution, the server will attempt to resolve the query using recursion. To prevent this, select the Do not use recursion field. The server returns a failed name query when the forwarder list is depleted.

SCAVENGING

The Windows Server 2003 DNS server can scavenge zones and remove outdated DNS records. By default this feature is disabled and may involve careful planning to ensure that valid resource records are not removed. Scavenging can eliminate incorrect resource records, save disk space, and increase performance. It may be initiated manually or configured to run automatically. Statically configured resource records are configured by default to have a refresh time of zero, which removes them from the scavenging process. Dynamically configured resource records, established through DHCP, are configured with a non-zero timestamp, which exposes them to scavenging.

NOTEConfiguring scavenging can be complex, so see the Help pages for further explanation before enabling it.

Initiating Manual Scavenging

Manually initiate scavenging by right-clicking the DNS server from the DNS snap-in and selecting the Scavenge stale resource records option.

Initiating Automatic Scavenging

Configure automatic scavenging by following these steps:

Right-click the DNS server from the DNS snap-in and select Properties. Choose the Advanced tab and check the Enable automatic scavenging of stale records box.

Scavenging must be enabled at the zone node in addition to the server node. Right-click the desired zone and select Properties. Select the General tab and click Aging. Check the Scavenge stale resource records box.

A DNS server is required for all Active Directory implementations. The mapping between FQDNs and their respective IP addresses can be in constant flux. Windows Server 2003 offers two DNS implementations, the Active Directoryintegrated and the standard zone DNS server, which both support dynamic DNS updates.

The Dynamic Host Configuration Protocol

The Dynamic Host Configuration Protocol (DHCP) provides a convenient and centralized method to configure and assign IP addresses on systems throughout the network. Once that is done, the entire network may be configured to retrieve and renew these addresses whenever they boot to ensure correct IP configuration for the current network. This is especially useful for mobile users and dial-in clients.

NOTEWindows Server 2003 provides several DHCP enhancements that were not available in previous versions of the operating system. These enhancements include:

Classless Static Route Option.
DHCP clients can request this option to be supplied with a list of routes to add to their routing table. This allows Remote Access Service and virtual private network clients, as discussed in the next chapter, to perform split-tunneling when connecting to remote networks. This feature is integral to the operating system.

Classless Source Routing.
This feature allows DHCP to configure a client with multiple classless routes with the use of a subnetwork mask. This feature is configured from the MMC DHCP snap-in tool.

DHCP Database Backups.
This feature enables backups of a DHCP database while the service is running. The API takes a directory location on local disk excluding remote paths and the service will back up the current state of the database onto the specified location. If a directory does not exist, it will then create one. This feature is configured from the MMC DHCP snap-in tool under Backup and Restore.

DHCP Database NetShell Migrations.
This feature is a great advancement for administrators who use it for migration of a DHCP database from one server to another when it is imported into NetShell (NETSH). This eliminates most manual configurations including editing the Registry and recreating scopes. The command-line tool, NETSH, is used to locally configure remote access servers and routers. This feature is available from Start All Programs Accessories command prompt type NETSH.

Enhanced logging for DNS updates performed by DHCP servers.
This feature can help track down DDNS attacks.

SERVER-SIDE DHCP CONFIGURATIONS

To install the DHCP server, follow these steps:

Ensure that the DHCP server system is configured with a static IP address. Clients must be configured with a DHCP server address to obtain an IP address (and other information) when booting.

From the Start menu Administrative Tools Configure Your Server tool. Click Next twice and select DHCP server. Click Next. Click Finish.

The New Scope Wizard appears. Click Cancel.

Bring up the DHCP tool by selecting Start Program Administrative Tools DHCP (Figure 12.23).

DHCP Authorization

DHCP servers can be installed on domain controllers, member servers, or standalone servers. However, the first DHCP server must participate in the Active Directory and it must be a member server or domain controller. The Active Directory maintains a list of authorized DHCP servers, which a DHCP server participating in the domain can query. If the server finds itself on the list, it will provide DHCP services. If it does not, it will not initialize or provide services. A standalone server does not participate with the directory service and depends on the limited broadcast DHCP informational message on the local network to invoke responses from functional DHCP servers. These DHCP responses will contain the enterprise root for each DHCP server, which the standalone server queries to obtain the DHCP authorization list for the directory. If it finds its IP address in each list, it will proceed with initialization. Otherwise, the service is stopped.

To authorize a DHCP server for the Active Directory, follow these steps:

Open the DHCP tool by adding the snap-in or select Start Programs Administrative Tools DHCP.

Right-click the DHCP node and select Manage authorized servers.

The Manage Authorized Servers dialog appears (Figure 12.24). Click Authorize and enter the DHCP server's DNS name or an IP address. Preferably enter the FQDN or the Name box will remain empty. Click OK.

Scopes and Classes

Once the DHCP server has been authorized for the domain, scopes must be created to define IP addresses and lease durations for its clients. The scope will be applied to all clients who request dynamically assigned IP addresses within its subnet; it will also determine several other client properties:

Address range

Address exclusion ranges

Lease duration

DHCP options

Reservations

Classes

Let's look at these properties as we create a scope for the new DHCP server:

Right-click the DHCP server in the DHCP snap-in and select New Scope. The New Scope Wizard appears. Click Next to start scope creation.

Enter a name and description for the new scope and click Next.

Enter a contiguous address range for the new scope by entering a Start IP address and an End IP address (Figure 12.25). This address range defines the pool of IP addresses available for DHCP clients who request them. Always assign the entire range of IP addresses to be used for the subnet and then use exclusion ranges to remove addresses from the pool.

The subnet mask identifies which bits of the IP address identify the network or subnet address. If the subnet mask bits are contiguous, you can indicate in the Length box how many bits there are from left to right. Click Next.

Add exclusion ranges to remove IP addresses from the available pool to lease DHCP clients. All IP addresses that have been statically configured for network interfaces should be excluded from the scope address range. Obviously, router addresses and the DHCP server's statically configured IP address should be excluded as well. To create an exclusion range, enter beginning and ending addresses, then click Add (Figure 12.26). When finished click Next.

Enter a time interval for the duration of a DHCP client's lease of the IP address before it expires. Laptop and remote clients that regularly move networks should be assigned shorter lease periods to free up addresses sooner. More stable networks may benefit from longer lease periods (Figure 12.27).

The next wizard dialog allows you to configure DHCP options. Although many DHCP options are provided by the DHCP server and detailed in the DHCP standards document RFC 2132, five are supported by all Windows and MS-DOS client systems. Selecting Yes, I want to configure these options now (Figure 12.28) permits configuration of the options listed in Table 12.1.

Follow the next four screens and configure the DHCP options for clients leasing in the new scope

When you reach the Activate Scope dialog windows, you may choose to activate the scope and start DHCP service for it. In the last dialog box, click Finish to complete scope creation.

The DHCP tool should display the newly activated scope under the server's node (Figure 12.29). The previously configured parameters can be viewed and modified from here. Table 12.2 details the containers within a scope's node.

Each subcategory in the DHCP scope can be modified by right-clicking the desired node and selecting an action. For example, the exclusion ranges are added to the address pool by right-clicking the Address Pool node and selecting New Exclusion Range.

Reservations for clients are made by right-clicking Reservations and selecting New Reservation. The New Reservation dialog appears and requests a reservation name, IP address, and MAC address (Figure 12.30). The DHCP server may also selectively reserve IP addresses for DHCP, BOOTP, or both. When it receives a DHCP request message from a client with a source MAC address that matches a reservation, it assigns the reserved IP address to the client's lease.

The DHCP options can be modified by right-clicking the Scope Options node and selecting Configure Options. In the General tab of the Scope Options dialog box, options with a check mark will be sent to DHCP clients and may be configured by modifying their Data entry fields. The Advanced tab of the Scope Options dialog box presents several more opportunities to configure options for DHCP server clients (Figure 12.31).

VENDOR AND USER CLASSES

Vendor and user classes allow different DHCP options to be applied to different systems and users. The DHCP server will map the client's vendor class ID from the DHCP request message to the configured vendor class list. The administrator can customize DHCP options for each vendor class. The vendor ID is configured internally only in the DHCP client software and set by the software manufacturer. For example, the Microsoft Windows 98 vendor class is set on Windows 98 clients and cannot be modified. The administrator may point all Windows 98 clients to a certain DNS server, using the vendor class to set the DNS server option.

NOTEThe Windows Server 2003 vendor class offers the following additional DHCP options to configure clients:

Disable NetBIOS on a Windows Server 2003 client.

Configure the system to release a DHCP lease upon shutdown.

Define a default router metric for establishing the quickest and most reliable routes.

User classes, on the other hand, can be configured on the client using the ipconfig line command. From the command prompt on the client system, type

C:\>ipconfig /setclassid "Local Area Connection" "Second Floor Users"

The following should be displayed:

Windows Server 2003 IP Configuration
DHCP ClassId successfully modified for adapter "Local Area Connection"

When the client sends the DHCP request message to the DHCP server, the server looks for a user class identified by the "Second Floor Users" ASCII string.

To create the corresponding user class on the DHCP server:

Right-click the corresponding DHCP server name from the DHCP snap-in. Select Define User Classes.

The current user classes are displayed in the DHCP User Classes dialog box. Click Add to reveal the New Class dialog box (Figure 12.32).

Enter a name and description for the new user class. Enter the user class ID as either a text string in the ASCII box or a hexadecimal number in the binary box. Click OK.

The new user class has been created. Right-click the Scope Options node on the server with the new user class and select Configure Options.

Select the Advanced tab and click the pull-down arrow for the User Class field.

Select the new user class and check DHCP options under the Available Options field and configure them using the Data entry field.

All clients who request DHCP leases from this DHCP server, configured with the "Second Floor Users" class ID, will receive only DHCP options assigned to this user class.

SUPERSCOPES

The DHCP server must be configured and scoped with IP addresses for all subnets it intends to support. If a server receives a request from a subnet other than its pool of addresses, it cannot lease a meaningful IP address to the client. A DHCP server can be configured to support multiple logical IP networks within one physical subnet. In order to support multiple IP network ranges on the same Ethernet segment, a scope must be created for each network and then all scopes must be grouped under one superscope. The superscope allows one or more scopes to be applied to the local network. Also, when DHCP relays or BOOTP relays are supported, their corresponding requests will be forwarded through IP layer switches and routers. Because the DHCP server will receive requests from other networks, superscopes must be configured.

To create a superscope, follow these steps:

Right-click the DHCP server node from the DHCP snap-in and select New Superscope. The New Superscope Wizard starts. Click Next.

Enter a name for the new superscope, then click Next.

Select the scopes to include in the new superscope from the Available Scopes field. To select more than one scope, hold down the SHIFT key and click multiple scopes. Click Next.

Click Finish to complete the wizard.

The new superscope, Super Scope 1, contains Scope 1and Scope 2 and can now service clients requesting addresses for both networks 111.111.111 and 111.111.112 (Figure 12.33). See the Help pages for further superscope configurations.

DHCP AND BOOTP RELAY AGENTS

Both DHCP and BOOTP clients use broadcast addressing to initiate contact with their corresponding server. Routers do not normally permit this broadcast traffic to traverse networks by default, which means that a DHCP/BOOTP server must be allocated for every network in the enterprise, unless routers are configured as DHCP/BOOTP relay agents. Most routers can be configured in accordance with RFC 1542 and forward DHCP and BOOTP packets between network interfaces. Another option is to configure a dual-homed Windows Server with the DHCP relay agent. This server will then forward DHCP and BOOTP requests between the two networks. The DHCP relay agent must also be configured for dial-in/remote access clients. See the Remote Access section in Chapter 13 for details.

THE 80/20 RULE FOR FAULT TOLERANCE

Fault tolerance is most effectively handled by configuring two DHCP servers to lease IP addresses on a given network. One server is configured with 20 percent of the address range; the other is configured with the remaining 80 percent. For instance, to service the 111.111.111.0 network with two DHCP servers, the first server would be scoped with 80 percent of the address range:

Scope range: 111.111.111.5  111.111.111.254
Excluding: 111.111.111.204 - 111.111.111.254

The second server would be scoped with 20 percent of the address range:

Scope range: 111.111.111.5  111.111.111.254
Excluding: 111.111.111.5 - 111.111.111.203

If one of the servers were to fail, the other could renew and issue leases for the network.

Another option is to configure a second, standby server the same way that you have configured the active server. The scopes on the secondary server would remain inactive until the primary server failed. Then they could be activated manually to handle client requests.

CLIENT-SIDE CONFIGURATIONS

Configure DHCP on the Windows Server 2003 client system for a network or dial-up connection by selecting Start Settings Network and Dial-up Connections connection name click Properties. Select Internet Protocol (TCP/IP) and click Properties. Select Obtain an IP address automatically and Obtain DNS server address automatically (Figure 12.34).

Automatic Client Configuration

Windows Server 2003 DHCP clients automatically configure network interfaces when a DHCP server is unavailable. When a client boots up and cannot obtain a response from a DHCP server, it will be configured to boot with an IP address from the Microsoft Class B range 169.254.0.0 with the subnet 255.255.0.0. Automatic client configuration works well for small business and home networks. An ARP request will be used to test if another client on the network is using the selected IP address. If so, the client will continue to search for an available DHCP server every 5 minutes. When one is found, a new IP address is leased, with which the client silently reconfigures the interface. Automatic client configuration also comes into play when the client owns a validly leased IP address and cannot communicate with the DHCP server. The client will ping the default gateway assigned in the original lease. If the router responds, the client assumes it is on the same IP network, has not been moved, and continues to use the previously leased IP address. If no router responds to the request, the client assumes it has been moved off the network and chooses an IP address from the autoconfiguration network range (169.254.0.0).

Client/Server Communication

To understand how DHCP works, it's important to discuss the basic message exchange between client and server. The client approaches the DHCP server according to two scenarios: (1) it is new to a network or its leased IP address has expired, or (2) it is renewing a leased IP address.

In the first scenario (Figure 12.35), the client broadcasts a DHCP discovery message on the local segment/ring for a DHCP server. If the DHCP server responds with a DHCP offer message, the client obtains a new lease. If not, the client can autoconfigure (configure itself) or continue to send DHCP server requests every 5 minutes. Eventually the client will receive the DHCP offer message and choose to accept the lease by returning a DHCP request to the server. The server sends the client a DHCP acknowledgment message to confirm the lease along with DHCP option configuration information.

The second scenario involves DHCP renewal. The client usually waits until the IP address lease's lifetime is 50 percent spent. Then it attempts to renew the lease by sending a DHCP request to the server who issued the lease. If the client does not obtain a DHCP acknowledgment from the server, it waits until the lease time reaches the rebinding state. Once this occurs, the client will attempt to renew its lease with any DHCP server on the network. Unless another server renews the lease, the client terminates the current IP address and then resorts to the first scenario and attempts to locate a DHCP server with the discovery message.

DNS with DHCP

Domain DNS servers can be updated with dynamically leased IP addresses to support current name/IP address mapping. DHCP servers and clients have several strategies for implementing these DNS entry updates. Configuration on the DHCP client and server determines which one is used.

The Windows Server 2003 DHCP client supports the client Fully Qualified Domain Name (FQDN) option when communicating with the DHCP server. This allows it to instruct the DHCP on how to handle dynamic DNS updates. The Register this connection's address in DNS option is the default for Windows Server 2003 clients. It is set through the Local Area Connection Status Properties TCP/IP Properties Advanced DNS tab (Figure 12.36) and instructs the client to send a DNS update request to the primary domain DNS server. This update will contain only the client's forward lookup record ("A" recordhostname-to-IP mapping) update.

DHCP SERVER CONFIGURATION FOR DNS

The DHCP server is capable of updating both forward and reverse lookup zones on the DNS server for DHCP clients. Several DHCP server configuration options are accessible from the DHCP tool. To reach them, right-click the DHCP server node and select Properties. Then select the DNS tab to display dynamic DNS update properties (Figure 12.37).

To prevent the DHCP server from updating any DNS information, clear the Automatically update DHCP client information in DNS box. Otherwise, a choice must be made between two options: If Update DNS only if DHCP client requests is selected, the DHCP will attempt to configure the DNS server according to the client's suggestion; selecting Always update DNS will configure the DHCP server to always update both the forward and reverse lookup zones on behalf of the client.

Clients that do not support the client FQDN option (DHCP clients that do not use Windows Server 2003) will not update the forward lookup zone and must rely on the DHCP server to handle the DNS update request. Selecting Enable updates for DNS clients that do not support dynamic updates will configure the DHCP server to do this. Selecting Discard forward (name-to-address) lookups when lease expires instructs the DHCP server not to send updates for the forward (A) record when leases expire. As long as automatic DHCP updates are permitted, however, the server will still update the reverse lookup zone.

NOTEDHCP servers must be added to the DnsUpdateProxy security group to enable dynamic DNS update. This occurs when the DHCP server is authorized (see the "DHCP Authorization" section).

THE BACKUP AND RESTORE OPTIONS

If the active DHCP server were to crash, many IP addresses would still be leased out to network clients. DHCP server backup is paramount to smooth operation and will help prevent duplicate address leases. Use Windows Server 2003 Backup and Restore options or use the NETSH set DATABASERESTORE flag to load a copy of the DHCP dbs from the default backup directory. Use logs to determine if the database is corrupt, indicated by JET errors. Initially try using the Jetpack.exe to repair the database. If this doesn't work, resort to backups. See the Help pages for moving a DHCP server database to another system.

BOOTP

The BOOTP protocol allows diskless clients to obtain IP addresses and boot image (executable code) locations to download software for operation. The image is then retrieved using the Trivial File Transfer Protocol (TFTP). The BOOTP sequence is performed only when the client is rebooted. Dynamic BOOTP address assignment is supported under Windows Server 2003. To enable this feature, right-click a previously created scope node and select Properties. Select the Advanced tab and then either BOOTP only or Both to enable dynamic IP address assignment for both protocols (Figure 12.38). A separate lease period available for BOOTP clients is configurable under Lease duration for BOOTP clients. The same DHCP options discussed earlier are sent to the BOOTP clients.

In addition to address assignment, BOOTP clients may request file information. This is accomplished in two steps. First, a reservation is established for a BOOTP client, tying the client's MAC address to a single IP address in the same way that DHCP clients reserve IP addresses. Right-click the Reservations node on the appropriate scope and select New Reservation. Assign an IP address, a name, and a MAC address, and be sure to select either Both or BOOTP only (Figure 12.39).

Second, an entry is defined in the BOOTP table from the DHCP snap-in. Right-click the DHCP server node and select Properties. Check Show the BOOTP table folder. Right-click the BOOTP Table node and select New Boot Image. Enter the image name, directory path, and DNS server name or IP address for the TFTP that hosts the client's boot image (Figure 12.40).

The BOOTP client communicates to the file server using the Trivial File Transfer Protocol to retrieve code and continue booting. Current client images can easily be distributed throughout the network using BOOTP.

WINS

The Microsoft implementation for the Windows Internet Name Service (WINS) provides services similar to those of the DNS server discussed earlier. The WINS server maps NetBIOS names to IP addresses. This is required for older systems that do not support the DNS FQDN format. The new WINS server supports dynamic updates for IP addresses assigned via the DHCP server. Also, it has no need for troublesome IP broadcasts for internetwork updates. WINS is not the preferred name server; DNS integration with the Active Directory is the primary name-resolution model.

NOTEA new feature in Windows Server 2003 that is integral to the operating system is TCP/IP name resolution without WINS or DNS. This feature provides a NetBIOS over TCP/IP (NBT) gateway. This enables Remote Access Service clients to resolve TCP/IP names on a LAN. Either a DNS or WINS server needs to be in place. This is particularly useful for small home and office networks where DNS might be considered overkill. They do not have DHCP, DNS, or WINS on this LAN. The feature enables all the remote computers to access LAN computers by name.