You are currently offline, waiting for your internet to reconnect

DNS/DHCP/WINS Release Notes for Windows NT 4.0 Service Pack 4 Update

IMPORTANT: This article contains information about editing the registry.Before you edit the registry, make sure you understand how to restore it ifa problem occurs. For information on how to do this, view the "Restoringthe Registry" online Help topic in Regedit.exe or the "Restoring a RegistryKey" online Help topic in Regedt32.exe.

Domain Name System (DNS)

This service pack update release includes several fixes to correct knownDomain Name System (DNS) problems reported for Microsoft Domain NameSystem (DNS) Server and DNS Manager.

These fixes address specific problems fully described in the followingarticles in the Microsoft Knowledge Base:

Article-ID: 129047
Title : Synchronizing DNS Information in Registry with Boot Files

Article-ID: 142047
Title : Bad Network Packet May Cause Access Violation (AV) on DNS Server

Article-ID: 154984
Title : DNS Server May Not Recursively Resolve Some Names

Article-ID: 154985
Title : DNS Registry Key Not Updated When Changing Zone Type

Article-ID: 159310
Title : Updated Version of Dns.exe Fixes Several Problems

Article-ID: 164300
Title : DNS Registry Parameter - AddressAnswerLimit

Article-ID: 167629
Title : Predictable Query IDs Pose Security Risks for DNS Servers

Article-ID: 169461
Title : Access Violation in DNS.EXE Caused by Malicious Telnet Attack

Article-ID: 170518
Title : DNS Admin Fails When Managing Large Number of Zones

Article-ID: 173676
Title : Client Cannot Resolve MX Record via Microsoft DNS Server

Article-ID: 182227
Title : DNS Server Does Not Check for Delegations Before Forwarding

Article-ID: 182713
Title : Multiple Entries in Zone File Cause Memory Leak in Dnsadmin.exe

Article-ID: 184881
Title : Reverse Lookups with BIND Earlier Than 4.8.3 Fail

Article-ID: 185734
Title : DNS Server Access Violation in Dns!sendNbstatResponse Routine

Article-ID: 185816
Title : DNS Server Event Log IDs Incorrect After Applying SP4

Article-ID: 186820
Title : DNS Server Returns Wrong Response When WINS Lookup Is Enabled

Article-ID: 187800
Title : NSLOOKUP Fails to Return DomainName Option for DHCP Client

Dynamic Host Configuration Protocol (DHCP)

This service pack update release includes several quality improvement fixesto correct known Dynamic Host Configuration Protocol (DHCP) problemsreported for Microsoft DHCP Server, the DHCP Manager administration tool,and for Microsoft DHCP-enabled clients running under earlier releasedversions of Windows NT 4.0.

These fixes address specific problems fully described in the followingarticles in the Microsoft Knowledge Base:

Article ID: 194424
Title : DHCP Server May Fail to Record Lease

Article-ID: 141496
Title : DHCP Client Comment Disappears When Obtaining IP Address

Article-ID: 163055
Title : DHCP Client May Fail With WinNT 4.0 SP2 Multinetted DHCP Server

Article-ID: 167708
Title : BOOTP Client Names Disappear in DHCP Manager

Article-ID: 173753
Title : Duplicate IP Addresses After Upgrading Clients to SP2

Article-ID: 175035
Title : Diskless Workstations Cannot Find BOOTP Server With DHCP

Article-ID: 177357
Title : DHCP Client Does Not Immediately Renew Address

Article-ID: 182047
Title : DHCP Server Performance Degraded By Large Number of Scopes

Article-ID: 183875
Title : DHCP Server Leases Excluded Addresses if the Scope Is Expanded

Article-ID: 187802
Title : DHCP Assigns "Bad_Address" to "Host Unreachable"

Article-ID: 188027
Title : Performance, Audit Logging, and Fixes to the DHCP Service

Article-ID: 184353
Title : DHCP ALT+H Shortcut Key for HELP Is Not Available

Article-ID: 189283
Title : No More Than About 570 Reservations Visible in a DHCP Scope

Article-ID: 193436
Title : DHCP Client Shuts Down After Two Declines

Article-ID: 190552
Title : WinNT 4.0 DHCP Client Modified to meet RFC 2131

Article-ID: 184744
Title : DHCP Server Leaks Registry Quota on Alpha Version of Windows NT

Article-ID: 184344
Title : Reconcile on DHCP Scope Does Not Work Correctly for BOOTP Client

Article-ID: 169291
Title : Using Scopes with Different Subnet Masks in a Superscope

You can obtain the specific article from Microsoft Support Online(

Windows Internet Name Service (WINS)

Windows NT Server includes the following added features for this serviceupdate release to Windows Internet Name Service (WINS) and WINS Manager:

  • Manual removal of dynamic WINS database records.
  • Multi-select operations for WINS database records.
  • Burst mode handling for WINS servers.

WINS Manager

WINS Manager now provides improved database management through support forrecord multi-selection and the ability to remove dynamic-type WINS recordsfrom the WINS server database.

Manual Removal of Dynamic WINS Database Records

The ability to manually delete dynamically-registered names mappings fromthe WINS database is now a part of WINS Manager. Because this support wasnot provided in previous versions of WINS Manager, deletion was difficult,requiring the advanced use of certain command line tools, such asWinscl.exe, a tool provided by the previous Windows NT Server resourcekits.

NOTE: Dynamic mappings are added to the WINS database when clients startand register their names in WINS before joining the network. Staticmappings are administratively added to the WINS database by a networkadministrator and can be edited or removed in the same manner.

Deletion is a useful practice for clearing up problems where dynamic WINSrecords are not fully consistent with currently stored mappings that havebeen replicated to other remote WINS servers. In addition, by allowingdeletion of dynamic WINS mappings, WINS administrators can eliminate thepractice of using static WINS mappings to correct name resolution problemswhich can create further problems for WINS.

NOTE: The use of static WINS mappings is not recommended for clients thatcan directly perform dynamic registration of their names in WINS. Wherestatic mappings are used to resolve connectivity issues and provide domainlogon support for WINS clients, these mappings can cause additionalproblems or be difficult to fully remove from large WINS installations withmultiple points of replications.

You can delete records in two ways: simple deletion or tombstoned deletion.With simple deletion, the selected WINS records are only removed from theselected WINS server that is actively being managed using WINS Manager.With simple deletion, records that are deleted are not removed or modifiedon other WINS servers. This method can be useful for making a "quickdeletion" of selected records on a single WINS server. For this method ofdeletion to be effective, you must make certain that the deleted records donot still appear on other WINS servers used in replication.

NOTE: If records are removed from a server using simple deletion but stillexist in WINS data on other servers, the deleted records may reappear onthe server where deletion was made when replication next occurs with otherWINS servers.

Perform the following steps to use simple or tombstoned deletion:

  1. Start WINS Manager.
  2. Click Mappings, and then click Show Database.
  3. Select the records you want to delete or tombstone.
  4. Click Delete Mapping. The Confirm Deletion dialog box appears.
  5. For Operation, click Delete to perform simple deletion of the records on the selected WINS server or Tombstone to tombstone the records for eventual deletion of the records on all WINS servers.
  6. If a single record is selected, click Yes to delete. If multiple records are selected, click Yes to All to delete all selected records.

How Tombstoning Works

With tombstoning, the "tombstoned" records are marked as extinct on theWINS server and immediately removed from active use by the server for WINSname resolution. However, these mappings are not immediately deleted fromthe server's database. Instead, the tombstoned records remain present forreplication purposes so that other WINS servers are notified as well thatthese records are inactive in WINS. After the deleted records are marked astombstoned on all WINS servers where they have been replicated, the recordswill then be removed during subsequent scavenging operations performed oneach server.

To use tombstoning effectively, you should only tombstone WINS records onthe WINS server that is the original owner for the records to be deleted.

IMPORTANT: In most cases, WINS records should be tombstoned at the originalowning WINS server to prevent deleted records from reappearing in WINSafter subsequent replication with other servers. Where a WINS server is nolonger active on the network, this is not a problem. For inactive ownerservers, you can use tombstoning effectively from other active WINS serversto remove records owned by the inactive servers that are still present inWINS.

The owner of a given WINS server record is typically the first servercontacted by the WINS client during the registration process and the actualserver first used to register the client's local names in WINS. In mostcases, the WINS server that owns a client's name records in WINS willcorrespond to the primary WINS server as configured on the WINS clientcomputer. Where the configured primary WINS server is not available duringclient registration, a configured secondary WINS server may be used insteadto perform the actual registration of the client's names and become theowner. To verify the exact owner server for a WINS record, view ownerinformation in the Show Database dialog box using WINS Manager.

Tombstoning uses the following sequence of events to remove the selectedrecords from all WINS servers that share and replicate the records to betombstoned.

  1. The owner WINS server marks and changes the status of selected WINS records from Active to Tombstoned in its local WINS server database.

    WINS then treats the records as inactive and released from use. After these records are tombstoned locally, the owner WINS server will not respond or resolve NetBIOS name queries for these names from other WINS clients and WINS servers unless the records are registered again by the WINS client.
  2. The owner WINS server replicates the selected records as tombstoned to other WINS servers during subsequent replication cycles.

    The records are not forcibly and immediately removed from WINS, but are flagged or marked for eventual deletion. The exact replication cycle (or Extinct Interval) is set in the server's WINS database properties. The records are not removed from WINS data until the extinction interval has actually expired. This allows other WINS servers to be notified that these records are no longer in use, update their replicated mappings for these records, and further replicate this updated WINS data to other servers.
  3. Records become extinct on all replicated WINS servers and are eventually removed physically from all WINS servers.

    After all WINS servers that participate in replication have completed a full replication cycle and arrived at a consistent state, the tombstoned records expire and are removed from each server's WINS database when it performs the next database scavenging operation. After scavenging occurs on all servers, the records no longer appear in WINS Manager and are no longer physically stored in the WINS database.

Multi-select Operations for WINS Database Records

WINS Manager now provides support for deletion or removal operations tomultiple records in the Show Database dialog box. In previous versions ofWINS Manager, only one record could be selected at a time.

Burst Mode Handling for WINS Servers

WINS servers can now support handling of high-volume, or burst serverloads, where a large number of WINS clients actively seek to register theirlocal names in WINS at the same time. With burst mode support, the WINSserver can respond positively to clients that submit registration requestsbefore it has processed and physically entered these updates in the WINSserver database.

Burst mode uses a burst queue size as a threshold value to determine howmany name registration and name refresh requests sent by WINS clients willbe processed normally before burst mode handling is started. By default,the burst queue is sized to allow 500 requests before burst handling isused.

How Burst Handling Works

Burst handling is enabled for any WINS server running under Windows NTServer 4.0 with the current service pack update release applied. Where aWINS server supports burst handling, the server will initiate bursthandling once the number of WINS client registration requests exceeds theburst queue size.

Burst handling is used to temporarily achieve a steady and gradualregistration state for the WINS server when the server is first startedwith a clean database or when many WINS clients come online for the firsttime. Either situation can cause a large amount of name registration andname refresh traffic to occur.

For burst handling, additional client requests beyond the amount specifiedby the burst queue size are immediately answered with a positive successresponse by the WINS server. The response also includes a varied time-to-live (TTL) to clients to help regulate the client registration load anddistribute processing of the requests over time.

The purpose of using TTLs in the success responses is to slow the refreshand retry rate for new WINS clients and regulate the burst of WINS clienttraffic. For example, if the default burst queue size (500 entries) isused, the WINS server will reply immediately to the next 100 WINS clientregistration requests by sending early success responses that use astarting TTL value of 5 minutes.

For each additional round of 100 client requests, the TTL is incremented bythe WINS server to add 5 minutes (such as 10, 15, 20 minutes, and so on)until a maximum of 50 minutes is used as the response TTL value. If WINSclient traffic is still arriving at bursted levels after the maximum TTLhas been used to answer clients, the next round of 100 client requests willbe answered starting over with the initial TTL value of 5 minutes and theentire process for incrementing the response TTL is repeated.

This behavior will continue until the WINS server reaches its maximumintake level of 25,000 name registration and refresh queries. At thispoint, the WINS server will begin dropping queries.

Configuring Burst Mode Support

You may use these additional registry values to further configure ordisable burst mode support where desired.

NOTE: By default, the following WINS registry values are not present andmust be manually added to reconfigure or disable burst mode support on theWINS server. However, if you plan to use the default server behavior (whichenables burst mode handling at the WINS server using a default burst queuesize of 500 entries), you will not need to add these Registry values ormake any additional configuration changes to the WINS server.

WARNING: Using Registry Editor incorrectly can cause serious problems thatmay require you to reinstall your operating system. Microsoft cannotguarantee that problems resulting from the incorrect use of Registry Editorcan be solved. Use Registry Editor at your own risk.

For information about how to edit the registry, view the "Changing Keys AndValues" online Help topic in Registry Editor (Regedit.exe) or the "Add andDelete Information in the Registry" and "Edit Registry Data" online Helptopics in Regedt32.exe. Note that you should back up the registry beforeyou edit it.

  • BurstQueSize

    You can add this registry value to adjust the maximum number of WINS client request entries that will be queued at the WINS server before it begins using burst handling.
    HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services \Wins\Parameters\BurstQueSi

    NOTE: The above registry key is one path; it has been wrapped For readability.

    Type: REG_DWORD Default: 500 Range: Valid values are 50-50

    Description: Sets the maximum number of name registration and refresh queries that are stored in the server's intake queue before burst handling is activated by the WINS server. This value has no effect where burst handling is disabled (for example, if the BurstHandling key has been added and set to a value of 0).
  • BurstHandling

    You can add this registry value to disable the use of burst mode handling by the WINS server.
    HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Wins\Parameters \BurstHandli

    NOTE: The above registry key is one path; it has been wrapped for readability.
    Type: REG_DWORD Default: 1 Range: 0 (disabled) or 1 (enable

    Description: This key determines whether the WINS server will use burst handling to send success responses to the clients in the queue. If the value of this entry is 0, the WINS server does not support burst handling or send early success responses to WINS clients. If the value of this entry is 1, the WINS server supports burst handling and sends early success responses to WINS clients.

Article ID: 184693 - Last Review: 06/22/2014 18:54:00 - Revision: 4.0

  • kbfea kbfix kbinfo KB184693