Any client attempt to update succeeds. For Active Directory-integrated zones, updates are secured and performed using directory-based security settings. Dynamic updates are sent or refreshed periodically. By default, computers send an update every twenty-four hours. If the update causes no changes to zone data, the zone remains at its current version, and no changes are written.
Updates that cause actual zone changes or increased zone transfers occur only if names or addresses actually change. Names are not removed from DNS zones if they become inactive or if they are not updated within the update interval of twenty-four hours.
DNS does not use a mechanism to release or to tombstone names, although DNS clients do try to delete or to update old name records when a new name or address change is applied. This value determines how long other DNS servers and clients cache a computer's records when they are included in a query response.
Scope clients can use the DNS dynamic update protocol to update their host name-to-address mapping information whenever changes occur to their DHCP-assigned address. This mapping information is stored in zones on the DNS server. This enables the client to notify the DHCP server as to the service level it requires. In this case, the option is processed and interpreted by Windows Server-based DHCP servers to determine how the server initiates updates on behalf of the client.
This is the default configuration for Windows. To configure the DHCP server to register client information according to the client's request, follow these steps:. By default, updates are always performed for newly installed Windows Server-based DHCP servers and any new scopes that you create for them. The following examples show how this process varies in different cases. For these DHCP clients, updates are typically handled in the following manner:.
After you integrate a zone, you can use the access control list ACL editing features that are available in the DNS snap-in to add or to remove users or groups from the ACL for a specific zone or for a resource record.
For more information, search for the "To modify security for a resource record" topic or the "To modify security for a directory integrated zone" topic in Windows Server Help. By default, dynamic update security for Windows Server DNS servers and clients is handled in the following manner:. Windows Server-based DNS clients try to use nonsecure dynamic updates first. If the nonsecure update is refused, clients try to use a secure update.
Also, clients use a default update policy that lets them to try to overwrite a previously registered resource record, unless they are specifically blocked by update security. By default, when you use standard zone storage, the DNS Server service does not enable dynamic updates on its zones. For zones that are either directory-integrated or use standard file-based storage, you can change the zone to enable all dynamic updates.
This enables all updates to be accepted by passing the use of secure updates. The secure dynamic updates functionality can be compromised if the following conditions are true:.
For more information, see the "Security considerations when you use the DnsUpdateProxy group" section. The secure dynamic update functionality is supported only for Active Directory-integrated zones. If you configure a different zone type, change the zone type, and then integrate the zone before you secure it for DNS updates. If you use secure dynamic updates in this configuration with Windows Server-based DNS servers, resource records may become stale.
In some circumstances, this scenario may cause problems. For example, if DHCP1 fails and a second backup DHCP server comes online, the backup server cannot update the client name because the server is not the owner of the name. In another example, assume that the DHCP server performs dynamic updates for legacy clients.
If you upgrade those clients to a version supporting dynamic updates, the upgraded client cannot take ownership or update its DNS records. To solve this problem, a built-in security group named DnsUpdateProxy is provided.
If all DHCP servers are added to the DnsUpdateProxy group, the records of one server can be updated by another server if the first server fails. Also, all the objects that are created by the members of the DnsUpdateProxy group are not secured. Therefore, the first user who is not a member of the DnsUpdateProxy group and that modifies the set of records that is associated with a DNS name becomes its owner.
When legacy clients are upgraded, they can take ownership of their name records at the DNS server. If every DHCP server that registers resource records for legacy clients is a member of the DnsUpdateProxy group, many problems are eliminated. If you are using multiple DHCP servers for fault tolerance and secure dynamic updates, add each server to the DnsUpdateProxy global security group.
Although this configuration remarkably reduces administrative overhead, this setting is not recommended for the organizations that have highly sensitive information available in the computers. Secure only — When this type of dynamic update is selected, only the computers that are members of the DNS domain can register themselves with the DNS server. The DNS server automatically rejects the requests from the computers that do not belong to the domain.
None — When this option is selected, the DNS server does not accept any registration request from any computers whatsoever. On the desktop screen, click Start. From the expanded list, double-click Forward Lookup Zones. From the displayed zones list, right-click the DNS zone on which secure only dynamic updates are to be configured.
Removal of stale records is done according to record timestamps. When working with scavenging, two intervals can be configured: no-refresh and refresh both by default are set to seven days.
The no-refresh interval indicates how long the DNS server should wait before refreshing a record. The refresh interval indicates how long the DNS server should wait after the timestamp refresh is allowed before it may attempt to scavenge a record.
Clients coming online and regenerating their registrations automatically cause the timestamp to be updated as well; they more or less let DNS server know that they are still online.
Combined with the DNS server's attempts to refresh these records after seven days by default , chances that stale records will remain in the system indefinitely are reduced to practically zero. By default, records created prior to enabling scavenging, and static manual registrations, do not have timestamps, which excludes them from the scavenging process if it is enabled later on.
To turn on scavenging for manually created records, you have to enable the "Delete this record when it becomes stale" option in the "A" or PTR record properties. Note that some options are displayed only when you select the Advanced submenu from the View menu in the DNS management console.
To enable scavenging , click the Aging button on the General tab in zone properties this will open the property page shown in Figure , and choose Scavenge Stale Resource Records.
0コメント