Patches to quash a critical DNS bug have slowed servers running BIND, the Internet's most popular DNS software, and crippled some systems versions of Windows Server.

Paul Vixie, who heads the Internet Systems Consortium (ISC), the group responsible for the BIND software, acknowledged issues with the 8 July fix that was rolled out as part of a multi-vendor update meant to patch a cache poisoning flaw discovered months before by researcher Dan Kaminsky.

"During the development cycle we became aware of a potential performance issue on high-traffic recursive servers, defined as those seeing a query volume of greater than 10,000/queries per second," said Vixie in a message posted on a BIND mailing list. "Given the limited time frame and associated risks we chose to finish the patches ASAP and accelerate our work on the next point releases that would address the high-volume server performance concerns.

"Our immediate goal was to make patches publicly available as soon as possible," Vixie explained.

Vixie wasn't specific about the extent of the performance problems facing high-volume DNS servers, but said that a second round of patches, due later this week, will remedy port allocation issues and "allow TCP queries and zone transfers while issuing as many outstanding UDP queries as possible."

Versions of the second update, which will be designated P2 when they're released, are currently available in beta form for BIND 9.4.3 and BIND 9.5.1.

However, Vixie stressed that administrators shouldn't roll back the 8 July patched editions even if their servers were running slowly. "Until the release of the -P2 code, it is imperative that you run a -P1 version of BIND on your caching resolvers," he said. "The vulnerability is of more concern than a slow server."

The flaw Kaminsky uncovered in February makes it much easier than originally thought to insert bogus information into the Internet's routing infrastructure. A successful attack would let criminals silently redirect requests for a legitimate site to a bogus one set up to skim personal information, such as passwords to online banking accounts, from duped users.

Earlier this month, when Kaminsky announced that the vulnerability had been patched by several vendors, including ISC, Microsoft and Cisco, he applauded their quick co-operation. "I want to get a lot of credit to the vendors here," he added in an interview last week. "The vendors were everything that the security community ever could have asked for," he said, referring to the resources they allocated to the problem and the speed with which they cranked out patches.

Patching the DNS flaw became more important last week after hackers took exploit code public.
ISC wasn't the only vendor involved in first-round DNS patching that has issued a mea culpa. Two weeks ago, Microsoft confirmed that the 8 July update, tagged as MS08-037, was crippling machines running Windows Small Business Server, a suite based on, among other programs, Windows Server 2003.

"Some customers have reported seeing random problems with services after installing MS08-037," reported several Microsoft engineers in a post to the Small Business Server (SBS) blog.

One SBS component that might fail to start, said Microsoft, was the IPSEC service, which would knock the server off the network.

Last Friday, the company released two documents that spelled out the patch's unintended side effects, but also added Exchange Server 2003 and Internet Security and Acceleration (ISA) Server to the affected list.

A second issue involves every supported version of Windows, ranging from Windows 2000, XP and Vista to Server 2003 and Server 2008. "You may experience issues with UDP-dependent network services after you install the Domain Name System (DNS) Server service security update 953230 (MS08-037) and then restart the computer," Microsoft said.

In both instances, Microsoft offered workarounds in the support documents but did not say whether, or when, the original DNS patch would be re-released. A company spokesman did not know of any plans to re-issue MS08-037, but was unable to immediately verify that with the team at the Microsoft Security Response Center (MSRC).