Issue
A Windows server hangs, reboots, becomes unresponsive or network
clients disconnect due to Dns.exe consuming a large amount of nonpaged
pool memory and file handles.
Solution:
Log on to the server using the local or domain
Administrator account, open an elevated command prompt and perform the following steps.
1. Press the Windows Logo+R, type
runas /user:administrator@domain.local cmd where
domain.local is replaced by the name of the Active Directory domain or local server name and press
Enter. The same task can be accomplished using the
Command Prompt and
Run as Administrator.
2. Type the
Administrator account password when prompted and press
Enter.
3. Type
dnscmd.exe /config /socketpoolsize 1000 and press
Enter.
4. Type net stop dns && net start dns and press Enter.
Additional Information:
This information pertains to Windows Server 2003, Windows Server 2003
R2, Windows Server 2008, Windows Server 2008 R2, Windows Server 2012 and
Windows Server 2012 R2.
Microsoft released security bulletin MS08-037 in July of 2008 for
Windows Server 2003. The bulletin contains important information about
vulnerabilities in the Windows Domain Name System (DNS) that could allow
spoofing specifically those posed by the Kaminsky vulnerability.
Windows DNS now uses source port randomization instead of a predictable
and known port. The ports are configurable through registry settings and
the pool size is configurable through a registry setting or using
Dnscmd.exe.
Windows servers already experiencing heavy loads of non-paged pool
memory may be impacted further by the installation of the Windows 2003
updates listed below or Windows servers running newer versions of
Windows.
DNS Client (951748)
DNS Server (951746)
The installation of the updates in Windows 2003 causes
Dns.exe
file handles to climb above 5000 and increased non-paged pool memory
consumption. This can cause servers to hang, reboot or become
unresponsive and often client computers lose network connectivity to the
server. A reboot will resolve the issue for periods or time, but the
issue will generally resurface in two to seven days. The workaround is
to reduce the number of sockets thereby reducing the number of file
handles and nonpaged pool memory consumption. 32-bit operating systems
are more prone to the negative affects of this issue. Refer to this
KB article for further information.
Article ID: 1151, Created On: 11/7/2019, Modified: 11/7/2019