DNS Server Reserves 2500 Ports.
After applying the patch for MS08-037 - KB 953230 (the multi-OS DNS flaw found by Dan Kaminski), you may notice your Windows Server 2003 machine gets a little greedy. At least, mine sucks up 2500 - yes, that's two thousand five hundred - UDP sockets sitting there apparently waiting for incoming packets.
This is, apparently, one of those behaviours sure to be listed in the knowledge base as "this behavior is by design" - a description that graces some of the more entertaining elements of the Microsoft KB.
Why does this happen? I can only guess. But here's my best guess.
The fix to DNS, implemented across multiple platforms, was to decrease the chance of an attacker faking a DNS response, by increasing the randomness in the DNS requests that has to be copied back in a response.
I don't know how this was implemented on other platforms, but I do know that it's already been reported that BIND's implementation is slower than it used to be (hardly a surprise, making random numbers is always slower than simply counting up) - and maybe that's what Microsoft tried to forestall in the way that they create the random sockets.
Instead of creating a socket and binding it to a random source port at the time of the request, Microsoft's patched DNS creates 2500 sockets, each bound to a random source port, at the time that the DNS service is started up. This way, perhaps they're avoiding the performance hit that BIND has been criticised for.
There are, of course, other services that also use a UDP port. ActiveSync's connection to Exchange, IPsec, IAS, etc, etc. Are they affected?
Sometimes.
Randomly, and without warning or predictability. Because hey, the DNS server is picking ports randomly and unpredictably.
[Workaround: HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters\ReservedPorts is a registry setting that lists multiple port ranges that will not be used when binding an ephemeral socket. The DNS server will obey these reservations, and not bind a socket to ports specified in this list. More explanation in the blog linked above, or at http://support.microsoft.com/kb/812873]
DNS, you see, is a fundamental underpinning of TCP/IP services, and as such needs to start up before most other TCP/IP based services. So if it picks the port you want, it gets first pick, and it holds onto that port, preventing your application from binding to it.
This just doesn't seem like a fix written by someone who 'gets' TCP/IP. Perhaps I'm missing something that explains why the DNS server in Windows Server 2003 works this way, but I would be inclined to take the performance hit of binding and rebinding in order to find an unused random port number, rather than binding before everyone else in an attempt to pre-empt other applications' need for a port.
There are a couple of reasons I say this:
- Seriously, how many Windows Server 2003 users out there have such a high-capacity DNS server that they will notice the performance hit?
- Most Windows Server 2003-based DNS servers are small caching servers for businesses, rather than Internet infrastructure servers responsible for huge numbers of requests per second - even if you implement this port-stealing method, it shouldn't be the default, because the majority of users just don't need that performance.
- If you do need the performance, get another server to handle incoming requests. Because the cost of having your DNS server's cache poisoned is considerably greater than the cost of increasing the number of servers in your pool, if you're providing major DNS service to that many customers.
- A major DNS service provider will be running fewer services that would pre-empt a DNS server request to bind to a random port, whereas systems running several UDP-based services are going to need less performance on their outgoing DNS requests.
I'd love to know if I'm missing something here, but I really hope that Microsoft produces a new version of the DNS patch soon, that doesn't fill your netstat -a output with so many bound and idle sockets, each of which takes up a small piece of nonpaged pool memory (that means real memory, not virtual memory).