The Internet Systems Consortium [http://www.isc.org] has released an update for all supported BIND 9.x versions today (2009-Jan-07) containing a security patch to address a potential DNS poisoning vector.  *NOTE*  This patch release does not appear to be an emergency situation requiring immediate updates for all.  The bug appears to affect only specific BIND configurations where DNSSEC has been enabled.  Updates will be made if this is not the case.

If you or your organization is responsible for the operational management of any supported version of BIND 9.x and have explicitly enabled and utilize DNSSEC features, it may be time to consider planning your upgrade.  Patch deployment would appear most critical among recursive name resolvers.  The flaw affects all actively developed and supported versions prior to and resolved with today's release of BIND 9.3.6-P1, 9.4.3-P1, 9.5.0-P2(-W2), 9.5.1-P1 and 9.6.0-P1.  No detail is available to support the identification of affected versions within vendor specific package management systems that use back ported versioning.  In this latter case, check with your vendor.

From the BIND "RELEASE NOTES" relative to each specific supported version:

BIND 9.6.0-P1 is a SECURITY patch for BIND 9.6.0.  It addresses a bug in which return values from some OpenSSL functions were left unchecked, making it theoretically possible to spoof answers from some signed zones.

If you are not entirely certain whether your organization is running DNSSEC enabled configurations, especially among recursive resolver deployments which is where I understand would be the most logical target for most DNS cache poisoning attacks. <ashamed> I myself was not certain if my org was running DNSSEC. </ashamed>.   I leaned heavily on my buddy Mark, whom I consult on just about every DNS related issue.  It was he who helped me identify how others could remotely query for DNSSEC enablement among their BIND (recursive) server infrastructure.

How can I check my BIND deployments remotely?

The following validation steps make the assumption that you will use a recent version of the dig client for dnssec query support. 

• Command line followed by query results for a recursive DNSSEC enabled resolver configuration:

  $ dig @IP_OR.YOUR_RECURSIVE_HOSTNAME.c0m ANY_OLD_DOMAIN.c0m +dnssec | grep flags
;; flags: qr aa rd; QUERY: 1, ANSWER: 4, AUTHORITY: 4, ADDITIONAL: 5
; EDNS: version: 0, flags: do; udp: 4096   

       The presence of the 'do' flag above implies that DNSSEC is enabled in the recursive name server.

• Command line followed by query results for a recursive resolver without DNSSEC support:

  $ dig @IP_OR.YOUR_RECURSIVE_HOSTNAME.c0m ANY_OLD_DOMAIN.c0m +dnssec | grep flags
;; flags: qr rd ra; QUERY: 1, ANSWER: 4, AUTHORITY: 4, ADDITIONAL: 5
; EDNS: version: 0, flags:; udp: 4096

       An empty flag set, or a missing 'do' flag implies that DNSSEC is not supported by the resolver.
  
  No claims are made as to the actual security posture or to the presence of a potential poisoning vulnerability based on either result set.  Do your homework.

• Command line to query for BIND version:

  $ dig @IP_OR.YOUR_RECURSIVE_HOSTNAME.c0m chaos txt version.bind.
.
;; ANSWER SECTION:
version.bind.           0       CH      TXT     "9.x.x"
.
     It is considered very "impolite" to version query name servers you do not manage.
  
  Please note that the version which is sent back from a resolver may not be valid as this is a commonly modified field.  Often found among version query results are smarmy remarks, insults and occasionally the preferred contact method for establishing communications with the appropriate operational management team.  If you receive a version string value and suspect that this value is indeed accurate, consider implementing some best practices in minimizing your attack surface while contemplating whether you really want to advertise versioning elements of your critical infrastructure.
  
  If you are feeling especially cheeky and do not mind enticing future attacks against your infrastructure, one might consider configuring in a version string of, hmmm.. say "8.2.3"?.  Ok, the latter is NOT a recommendation for anyone!

Refer to the ISC BIND Server software Index

https://www.isc.org/downloadables/11

William Salusky
Handler on Duty (heh-heh)