It seems the cat might be out of the bag regarding Dan Kaminsky's upcoming presentation at Blackhat.

Since this now means the bad guys have access to it at will -I found the speculations using Google, I'm sure they have done so already-, the urgency of patching your recursive DNS servers just increased significantly. There seems to be some effort underway to put the cat back in the bag, but I strongly doubt that'll work.

To describe it for defensive use by those operating recursive DNS servers: The descriptions I found would make you look for signs of attack using this technique in DNS queries for significant amounts of nonexistent subdomains that try to poision the parent using a glue record.
Those operating authoritative servers should be able to monitor for increased/excessive queries into nonexistent names from a single source, but there's little they can do beyond trying to warn the operator of the recursive server.

Since I wasn't briefed by Dan Kaminsky, I've no way of knowing if the theories that are out there are in fact what was going to be presented at Black Hat, so it might still be different.

Still, while fixing this might not be so trivial, an upgrade or patch of all recursive DNS servers is what's really needed at this point. So if you were still waiting for an excuse, this one is it: PATCH NOW.
Take care as performance issues exist in e.g. BIND with some of the patched versions, and e.g. ISP operated recursive servers do take quite a bit of load ...

UPDATE 1:

• Please, do not jump to conclusions for every DNS problem out there, many more things can and do go wrong beyond this problem.
• The CVE name for this has many more links:  CVE-2008-1447
• There is a problem with recursive servers behind a NAT gateway: a good caching nameserver hidden behind a firewall or a router that's undoing the port randomisation leaves your server vulnerable.
• A test for nameservers is available, you can test those you run yourself or those given to you by your ISP to use as forwarders (if they are GOOD, use them!)
  e.g.:
  $ dig @IP-of-GOOD +short porttest.dns-oarc.net TXT
  z.y.x.w.v.u.t.s.r.q.p.o.n.m.l.k.j.i.h.g.f.e.d.c.b.a.pt.dns-oarc.net.
  "IP-of-GOOD is GOOD: 26 queries in 2.0 seconds from 26 ports with std dev 17685.51"
  
  $ dig @IP-of-BAD +short porttest.dns-oarc.net TXT
  z.y.x.w.v.u.t.s.r.q.p.o.n.m.l.k.j.i.h.g.f.e.d.c.b.a.pt.dns-oarc.net.
  "IP-of-BAD is POOR: 26 queries in 4.0 seconds from 1 ports with std dev 0.00"
   
• If seeking good forwarders when your ISP doesn't provide them, consider those of OpenDNS. Be aware it comes with other features as well.
• Using SSL (e.g. HTTPS) can be beneficial as it can detect man-in-the-middle but you must teach and train users to NEVER accept bad certificates, not even after they "validated" them manually (most of them won't be able to do the math to verify a digital signature in mental math (well at least I can't), and verifying the readable part isn't worth anything as that's the part where the signature failed on ...)
  The only "validation" to be done is to contact the other side out of band and verify the fingerprint of a self-signed certificate, but most users will just press "next" ... and feel the false sense of comfort by a lock and/or green bar.

UPDATE 2:

• Jacob mentioned dig might not be the easiest on windows users. They can use nslookup from the command line to do the test of e.g. their ISPs servers:
  
  $ nslookup -type=txt -timeout=30 porttest.dns-oarc.net
  $ nslookup -type=txt -timeout=30 porttest.dns-oarc.net IP-of-SERVER
  
  The output will be a bit more messy, just look for the word GOOD, FAIR or POOR (the statistics are still right behind that)

UPDATE 3:

• Increasing the urgency to patch even more: There is now a publicly available metasploit module that appears to be capable to exploit this vulnerability.
  
  Thanks to all who wrote this in.

UPDATE 4:

• A second module has been released for domains, which replaces the nameservers of the target domain. Unlike the first module which will not replace a cached entry, this exploit will do cache overwrites.
  
  See http://blog.wired.com/27bstroke6/2008/07/dns-exploit-in.html

UPDATE 5:

• Matt wrote in to announce Emerging Threats is offering a freely available snort signature for DNS servers. As always, test before using in critical production environments.

UPDATE 6:

• A reader wrote in regarding the signature from Emerging Threats: "For some reason it conflicts with the emerging-exploit fgdump rule so it was removed from the repo. Snort errors with a message about a conflict in a previous rule of a different protocol." So do take extra care ...
• A snort rule should already be available to those who subscribe to Sourcefire's VRT.

--
Swa Frantzen -- Section 66