Microsoft KB Archive/187709

From BetaArchive Wiki
Knowledge Base


Windows NT 4.0 Domain Name Resolver Caches Responses Regardless of Registry Setting

Article ID: 187709

Article Last Modified on 11/1/2006



APPLIES TO

  • Microsoft Windows NT Server 4.0, Terminal Server Edition
  • Microsoft Windows NT Workstation 4.0 Developer Edition
  • Microsoft Windows NT Server 4.0 Standard Edition



This article was previously published under Q187709


SYMPTOMS

When a Windows Sockets application uses DNS to resolve a hostname to an IP address by means of the gethostbyname API, the Domain Name Resolver (DNR) on a computer running Windows NT 4.0 caches the response for the TTL (Time to Live) specified in the response on a per-process basis. This means that if there is a change in the IP address of the host computer, the client application continues to try connecting to the old address. It also means that the same IP address will be used each time, until the TTL expires, if the response contains multiple IP addresses.

CAUSE

Winsock2 support was introduced in Windows NT 4.0. Previous versions of Windows NT supported a MaxHostentCacheSize registry value, which you could set to zero to disable caching. Support for this parameter was not included in Winsock2.

RESOLUTION

To resolve this problem, obtain the latest service pack for Windows NT 4.0 or Windows NT Server 4.0, Terminal Server Edition. For additional information, click the following article number to view the article in the Microsoft Knowledge Base:

152734 How to Obtain the Latest Windows NT 4.0 Service Pack



Support for the MaxHostentCacheSize registry value has been added to Winsock2. The registry value controls the number of cache entries that are available to the process. If you set the value to zero, no caching will be done.
HKLM\SYSTEM\CurrentControlSet\Services\Tcpip\ServiceProvider \MaxHostentCacheSize

NOTE: The above link is one path; it has been wrapped for readability.
Value type: REG_DWORD Default value: 10

STATUS

Microsoft has confirmed that this is a problem in Windows NT 4.0 and Windows NT Server 4.0, Terminal Server Edition. This problem was first corrected in Windows NT 4.0 Service Pack 4.0 and Windows NT Server 4.0, Terminal Server Edition Service Pack 4.

Keywords: kbbug kbfix kbqfe KB187709