On Tuesday, July 9th, 2008, a exploit patch was released for all major DNS server systems. This was a major event. Nearly every DNS server is impacted by this exploit. If you are a rackAID management client, we have already rolled out the patch for your system (provided they are available from the vendor).
I will post more about this once the dust settles but for the curious, you can check out this AFP article. And also check out DoxPara Research for details behind this patch event. Major companies have been working behind closed doors for months getting this ready.
The check my dns tool on that site just checks your provider’s DNS not your servers. We have already checked your server.
On some Plesk systems, there were issues with applying the patch. Plesk runs DNS in a /var/named/run-root folder while the default Red Hat location is /var/named/chroot. This caused several issues with DNS properly restarting. The update even replaced some DNS files that we had to rebuild.
For those of you trying to fix up your Plesk boxes on your own, you can enable and disable the DNS for a domain. This will rebuild the named.conf and DNS files with information from the database.
If you are on a management contract and have DNS issues, please open a ticket. Include the domain names impacted. We will get them fixed as soon as possible.
Update:
I should restate the impact of the exploit. The exploit only impacts DNS caches. This is true of any server permitting recursive DNS. On shared hosting platforms, cPanel and Ensim both permit DNS recursion lookups to anyone. Plesk now has the ability to limit recursive lookups. So in short, if you are running cPanel or Ensim and have not modified your bind packages since the updates on Tuesday, your server is likely vulnerable. With Plesk, you can use the control panel to limit recursion to the localhost or localnets only.
The way that this works is that an attacker can poison your DNS cache. This basically means the attacker could populate your cache with incorrect DNS information. If you pull in RSS feeds, connect to credit card processors, and route email with sensitive contents, and attacker could use this exploit to redirect that traffic. Say that your server calls www.paymentprocessor.net to get a credit card approved. An attacker could trick your DNS cache to call their server instead of the normal one. This could be quite severe if all data is not encrypted.