Windows DNS Client Service: Evil

That’s right. I’m calling out Microsoft’s DNS Client Service as evil. An image, analysis and solution after the jump.

red-lectroids

OK. So the DNS Client Service was probably not invented by Red Lectroids from Planet 10, but after struggling with how poorly Microsoft implemented DNS caching in Windows 7, I finally came to the conclusion that it needed to be killed, and killed dead, on the family laptop. Over a period of several months, and many dozens of network client restarts, ifconfig /dnsflushes and other tactics I was tired of fooling around.

Just to be clear, the DNS Client Service is not needed to resolve host names using the Domain Name System (DNS). That’s something that Windows computers have been able to do out of the box since Windows 95. Instead, the sole mission in life of the DNS Client Service is to cache responses to DNS queries made by the client to DNS servers for the purported purpose of reducing network traffic.

That’s pretty absurd when you consider the tsunami-like torrent of packets flooding local networks from Microsoft’s legacy NetBIOS, LAN Manager and WINS protocols that continue to be kept around for “backward-compatibility” purposes at least a decade after there wasn’t any real reason to.

Of course we have our own version of this in the Unix world, nscd, the Name Service Cache Daemon made popular by Netscape and Sun. Although it now ships with every Linux distribution, it has been acknowledged by many that nscd isn’t necessary unless you’re using network authentication services like NIS or LDAP (or services that assume caching of user and host names like SMB or NFS). See reply by “Ressu” to dns queries not using nscd for caching.

The fundamental problem with client-side caching of DNS results is that it actually defeats the whole point of using a dynamic naming service to begin with.

And although we’re told that it improves performance and reduces network traffic, I’ve been involved in enough incidents where the fault lay with DNS caching to have come to the conclusion that it’s actually counter-productive to the ultimate mission of a network infrastructure: Getting clients where they need to go. When I think about how many times I’ve recommended that users be told to run “ipconfig /flushdns”, and then hear “everything is working now” — I want to scream.

Microsoft, of course, has good reasons for shipping DNS Client Service with every copy of Windows. One of those is that it makes file sharing (using the SMB protocol) more efficient on big networks. But the main reason is its important role in supporting authentication within Active Directory domain by caching host, service and user names. Without the DNS Client Service the Active Directory’s hybrid LDAP/Kerberos authentication services would be significantly more chatty, and over slow networks (you know, the typical DSL speeds of most remote office links), noticeably more unreliable.

Having said all that, if you’re not authenticating to a Windows or and other kind of central authentication service you can probably shut down the DNS Client Service and not notice any difference in performance or reliability. In fact, freed from the vagaries of Microsoft’s implementation of DNS caching, you may find your network experience improves.

Shutting down the DNS Client Service and Keeping it that way

There are a couple of ways to do this. The easiest is to fire up the Services control tool (Start… Run… services.msc… DNS Client… Stop… Disabled).

Here are some related articles you may want to peruse:

How to Disable Client-Side DNS Caching in Windows XP and Windows Server 2003

Consider disabling the DNS Client Service if you have a dodgy Internet Connection

The DNS Client service riddle

(i swear, the guy looks like Steve Ballmer with five o’clock shadow)