Windows 2000 DNS
Windows 2000 DNS |
|
This section describes the Windows 2000 implementation of dynamic update. For information about the dynamic update standard specified in RFC 2136, see "Introduction to DNS" in this book.
Note
Dynamic updates can be sent on behalf of different services such as the DHCP client, the DHCP server, Netlogon, and cluster services. The following sections describe only dynamic updates performed by the DHCP client and server.
In Windows 2000, clients can send dynamic updates for three different types of network adapters: DHCP adapters, statically configured adapters, and remote access adapters. Regardless of which adapter is used, the DHCP client service sends dynamic updates to the authoritative DNS server. The DHCP client service runs on all computers regardless of whether they are configured as DHCP clients.
By default, the dynamic update client dynamically registers its A resource records and possibly all of its PTR resource records every 24 hours or whenever any of the following events occur:
By default, the dynamic update client automatically deregisters name–to–IP address mappings whenever the DHCP lease expires. You can configure the client not to register its name and IP address in DNS. If you configure the client not to automatically register name–to–IP address mappings and the DHCP server is running Windows 2000, and it is configured to register DNS resource records on behalf on clients that are running versions of Windows earlier than Windows 2000, the DHCP server attempts to update the mappings instead.
To prevent the client from registering name–to–IP address mappings
You can force a re-registration by using the command-line tool Ipconfig. For Windows 2000–based clients, type the following at the command prompt:
ipconfig /registerdns
For Windows NT 4.0–based clients, type the following:
ipconfig /release
ipconfig /renew
For Microsoft® Windows® 98–based and Microsoft® Windows® 95–based clients, type the following:
winipcfg /renew
In a dynamic update, the following events occur:
Figure 6.17 shows a typical dynamic update process.
Figure 6.17 Dynamic Update Process
Updates can fail for the following reasons:
The primary server might not respond if it is down or if the local name server has an incorrect or outdated name server listed in its SOA resource record. DNS servers with standard zones (including secondary servers for Active Directory–integrated zones) can cause problems by sending incorrect or outdated SOA records when dynamic update clients request them. However, DNS servers with Active Directory–integrated zones always include their name in the SOA records, so DNS servers with Active Directory–integrated zones do not send incorrect or outdated SOA records.
If the primary server does not respond but the zone is replicated through multimaster replication, the client attempts to register the name with the other primary DNS servers that are authoritative for the name.
If the update fails because the server is not available, the client logs a message in the event log, which you can view by using Event Viewer. You can also configure the server log, Dns.log, to show a failure. For more information about Event Viewer, see "Troubleshooting" later in this chapter.
For more information about secure dynamic update, see "Secure Dynamic Update" later in this chapter.
The following sections describe the dynamic update process for adapters configured by DHCP, statically configured adapters (adapters for which a user or administrator has manually entered the IP address), and remote access adapters.
Windows 2000 DHCP clients are dynamic update–aware and can initiate the dynamic update process. A DHCP client negotiates the process of dynamic update with the DHCP server when the client leases an IP address or renews the lease, determining which computer will update the A and PTR resource records of the client for the FQDN (which can contain a connection-specific DNS suffix). Depending on the negotiation process, the DHCP client, the DHCP server, or both, update the records by sending a dynamic update request to a primary DNS server that is authoritative for the name that is to be updated.
Clients and servers that are running versions of Windows earlier than Windows 2000 do not support dynamic update. However, Windows 2000 DHCP servers can perform dynamic updates on behalf of clients that do not support the FQDN option (which is described in the following section). For example, clients that are running Windows 95, Windows 98, and Windows NT do not support the FQDN option. To enable this functionality, in the DNS tab of the server properties for the DHCP console, select the option Enable updates for DNS clients that do not support dynamic updates. The DHCP server first obtains the name of legacy clients from the DHCP REQUEST packet. It then appends the domain name given for that scope and registers the A and PTR resource records.
For information about how security for clients that do not support the FQDN option is implemented through secure dynamic update, see "Secure Dynamic Update" later in this chapter.
In some cases, stale PTR or A resource records can appear on DNS servers when the lease of a DHCP client expires. For example, when a Windows 2000 DHCP client tries to negotiate a dynamic update procedure with a Windows NT 4.0 DHCP server, the Windows 2000 DHCP client must register both A and PTR resource records itself. Later, if the Windows 2000 DHCP client is improperly removed from the network, the client cannot deregister its A and PTR resource records; thus, they become stale.
If a stale A resource record appears in a zone that allows only secure dynamic updates, no person or computer is able to use the name in that A resource record.
To prevent problems with stale PTR and A resource records, you can enable the aging and scavenging feature. For more information about the aging and scavenging feature, see "Aging and Scavenging" later in this chapter.
To provide fault tolerance, consider integrating with Active Directory those zones that accept dynamic updates from Windows 2000–based clients. If you want to speed up the discovery of authoritative servers, you can configure each client with a list of preferred and alternate DNS servers that are authoritative for that directory-integrated zone. If a client fails to update with its preferred server because the server is unavailable, the client can try an alternate server. When the preferred server becomes available, it loads the updated, directory-integrated zone that includes the update from the client.
To negotiate the dynamic update process, the DHCP client sends its FQDN to the DHCP server in the DHCPREQUEST packet by using the FQDN option. The server then replies to the DHCP client by sending a DHCP acknowledgment (DHCPACK) message by using the FQDN option.
Table 6.6 lists the fields of the FQDN option of the DHCPREQUEST packet.
Table 6.6 Fields in the FQDN Option of the DHCPREQUEST Packet
| Field | Explanation |
|---|---|
| Code | Specifies the code for this option (81). |
| Len | Specifies the length of this option (minimum of 4). |
| Flags | Can be one of the following values::
0. Client wants to register the A resource record and requests that the server update the PTR resource record. 1. Client wants server to register the A and PTR resource records. 3. DHCP server registers the A and PTR resource records regardless of the request of the client. |
| RCODE1 and
RCODE 2 |
The DHCP server uses these fields to specify the response code from an A resource record registration performed on the client's behalf and to indicate whether it attempted the update before sending DHCPACK. |
| Domain Name | Specifies the FQDN of the client. |
As Figures 6.18 and 6.19 show, the conditions under which DHCP clients send the FQDN option and the action taken by DHCP servers depend on the operating system that the client and server are running and how the client and server are configured.
Figure 6.18 Windows 2000-based Client
Figure 6.19 Client That Does Not Perform Dynamic Updates
Whether the client requests dynamic update depends on whether the client is running Windows 2000 or another version of Windows. It also depends on and how the client is configured. Clients can take any of the following actions:
Depending on what the client requests, the server can take different actions. If the DHCP client sends a DHCPREQUEST message without the FQDN option, what happens depends on the type of server and how the server is configured. The server can update both records anyway. The server does so if it is configured to update records on behalf of clients that do not support the FQDN option.
Alternatively, the server might do nothing. In the following cases, the server does nothing:
If the Windows 2000–based DHCP client requests that the server updates the PTR resource record but not the A resource record, what happens depends on the type of server and how it is configured. The server can perform any of the following actions:
By default, Windows 2000 DHCP clients are configured to send the FQDN option with the Flags field set to 0, to request that the client register the A resource record and the server register the PTR resource record. The name used in the DNS registration is a concatenation of the host name and the primary DNS suffix of the computer. You can change this default from within the TCP/IP properties of your network connection.
Note
From this page, you can specify whether to use the connection-specific DNS suffix in DNS registration and whether to register the connection's IP address at all.
To change the dynamic update defaults on the dynamic update client
To configure the client to register the connection-specific DNS suffix as well as the primary DNS suffix, select Use this connection's DNS suffix in DNS registration.
To configure the client not to register its IP address in DNS, deselect Register this connection's addresses in DNS.
You can configure the Windows 2000 DHCP server to do one of the following: update whichever records the client requests that it update; always update both A and PTR resource records, regardless of the request of the client; or to not update any DNS records.
To configure dynamic update for the Windows 2000 DHCP server
Caution
If you have any multihomed dynamic update clients and at least one adapter is using DHCP, select the option Update according to client request (the default). If the DHCP server is configured to register both A and PTR resource records, the DHCP server replaces all A resource records for the name it attempts to register.
To update A or PTR resource records, the DHCP server sends a dynamic update request to the DNS server. If the DHCP server updated an A or PTR resource record, it removes that record when the lease of the client expires. You can also configure the server to remove the A resource record of the client when the lease of the client expires, even if the DHCP client and not the server registered the A resource record. When the DHCP lease is renewed, DHCP clients re-register their resource records.
To configure the Windows 2000 DHCP server to remove A resource records when the lease expires
For more information about the FQDN option and integration between DNS and DHCP, see the Internet Engineering Task Force (IETF) link on the Web Resources page at http://windows.microsoft.com/windows2000/reskit/webresources. Search for the IETF Internet-Draft "Interaction Between DHCP and DNS."
Statically configured clients and remote access clients do not rely on the DHCP server for DNS registration. Statically configured clients dynamically update their A and PTR resource records every time they start, or every 24 hours if the computer stays up longer than a day, in case the records become corrupted or need to be refreshed in the DNS database. Remote access clients dynamically update A and PTR resource records when a dial-up connection is made. They also attempt to deregister the A and PTR resource records when the user closes down the connection. However, if a remote access client fails to deregister a resource record within four seconds, it closes the connection, and the DNS database will contain a stale record. If the remote access client fails to deregister a resource record, it adds a message to the event log, which you can view by using Event Viewer. The remote access client never deletes stale records. However, the RRAS server attempts to deregister the PTR resource record when the client is disconnected.
If a dynamic update client is multihomed (has more than one adapter and associated IP address), by default it registers the first IP address for each adapter. If you do not want it to register these IP addresses, you can configure it to not register IP addresses for one or more adapters from the properties page for the network connection.
To prevent the computer from registering an IP address for an adapter
The dynamic update client does not register all IP addresses with all DNS servers. For example, Figure 6.20 shows a multihomed computer, client1.noam.reskit.com, that is connected to both the Internet and the corporate intranet. Client1 is connected to the intranet by adapter A, a DHCP adapter with the IP address 172.16.8.7. Client1 is also connected to the Internet by adapter B, a remote access adapter with the IP address 10.3.3.9. Client1 resolves intranet names by using a name server on the intranet, NoamDC1, and resolves Internet names by using a name server on the Internet, ISPNameServer.
Figure 6.20 Dynamic Update for Multihomed Clients
Notice that although Client1 is connected to both networks, the IP address 172.16.8.7 is reachable only through adapter A, and the IP address 10.3.3.9 is reachable only through adapter B. Therefore, when the dynamic update client registers the IP addresses for Client1, it does not register both IP addresses with both name servers. Instead, it registers the name–to–IP address mapping for adapter A with NoamDC1 and the name–to–IP address mapping for adapter B with ISPNameServer.
By default, the computer registers a concatenation of the host name and primary DNS suffix. You can also configure the computer to register the domain name that is a concatenation of the host name and the connection-specific DNS suffix. For example, if you have a client that is connected to two different networks, and you want it to have a different domain name on each network, you can configure it to do so. For more information about configuring multiple domain names, see "Connection-Specific Domain Names" earlier in this chapter.
Whenever a dynamic update client registers in DNS, the associated A and PTR resource records include the TTL, which by default is set to 20 minutes. You can change the default setting by modifying the DefaultRegistrationTTL entry in the following registry subkey:
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services
\Tcpip\Parameters
The entry has a DWORD value and lists the TTL in seconds. A small value causes cached entries to expire sooner, which increases DNS traffic but decreases the risk of entries becoming stale. Expiring entries quickly is useful for computers that frequently renew their DHCP leases. A large value causes cached entries to be retained longer, decreasing DNS traffic but increasing the risk of entries becoming stale. Long retention times are useful for computers that renew their DHCP leases infrequently.
Caution
Do not use a registry editor to edit the registry directly unless you have no alternative. The registry editors bypass the standard safeguards provided by administrative tools. These safeguards prevent you from entering conflicting settings or settings that are likely to degrade performance or damage your system. Editing the registry directly can have serious, unexpected consequences that can prevent the system from starting and require that you reinstall Windows 2000. To configure or customize Windows 2000, use the programs in Control Panel or Microsoft Management Console (MMC) whenever possible.
If during dynamic update registration a client determines that its name is already registered in DNS with an IP address that belongs to another computer, by default the client attempts to replace the registration of the other computer's IP address with the new IP address. This means that for zones that are not configured for secure dynamic update, any user on the network can modify the IP address registration of any client computer. For zones that are configured for secure dynamic update, however, only authorized users are able to modify the resource record.
You can change the default setting so that instead of replacing the IP address, the client backs out of the registration process and logs the error in Event Viewer. To do so, add the DisableReplaceAddressesInConflicts entry with a value of 1 (DWORD) to the following registry subkey:
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services
\Tcpip\Parameters
The entry can be 1 or 0, which specify one of the following:
Caution
Do not use a registry editor to edit the registry directly unless you have no alternative. The registry editors bypass the standard safeguards provided by administrative tools. These safeguards prevent you from entering conflicting settings or settings that are likely to degrade performance or damage your system. Editing the registry directly can have serious, unexpected consequences that can prevent the system from starting and require that you reinstall Windows 2000. To configure or customize Windows 2000, use the programs in Control Panel or Microsoft Management Console (MMC) whenever possible.
