JavaScript must be enabled in order for you to use Knowledgebase Manager Pro. However, it seems JavaScript is either disabled or not supported by your browser. To use Knowledgebase Manager Pro, enable JavaScript by changing your browser options, then try again.
Learn more.

About This Document

For up to date information on this vulnerability, patches, and other operational information, please see the official vulnerability announcement. This
article is intended to supplement the information in that announcement
and will be updated as needed to further describe the operational impact
of this vulnerability.

Am I vulnerable?

Recursive
servers are vulnerable if they query zones which you do not directly
control (for example, if they query zones on the internet.)

You are potentially vulnerable if you resolve
queries for data provided by a third party. Examples could include
addresses in email, html links in web pages, or queries submitted by
users.

Resolving queries through a forwarder does not prevent exposure to this vulnerability.

Authoritative servers may be vulnerable if they receive and serve zone data that is maintained by third parties - this includes records created by dynamic updates or provided via zone transfer.

How was this vulnerability discovered and why hasn't it been seen before now?

The problem was uncovered by researchers experimenting with new DNS record types. Since they're undefined by the DNS protocol, BIND does not have any built-in validation of the RRsets when loading the zones. These recent experiments with undefined DNS record types exposed the problem for the first time.

What are experimental record types?

These are record types that are (currently) unknown. The type field has values that are documented in the DNS Protocol RFCs, including many newer types.

Are these packets that cause the problem malformed?

No - they are not malformed - they're constructed correctly per DNS protocol.

Can I accidentally create and load zone data with records that cause my authoritative server to have problems?

This is extremely unlikely because BIND validates zone files before loading them. You should not be able to create and load records that expose the problem using well-known DNS record types.

What does 'disclose some portion of memory to the
client' mean?

Under this defect if a server holds this type of record, the internal data structures can be processed incorrectly with the result that a client query response might sometimes include information from portions of memory that were not part of that resource record.

Can I protect my servers using firewalls or packet filtering techniques?

It might be possible to filter on inbound DNS protocol traffic (for example on query responses, dynamic updates and zone transfers) but this would require deep inspection of the individual Resource Records within the packets. Most filtering tools and firewalls have insufficient granularity of control. This type of approach also creates a potential traffic bottleneck. Upgrading BIND is the recommended solution.

It is also not recommended to deploy filtering to limit inbound traffic to packets containing known DNS record types because such filters may in the future prevent the correct operation of new protocols or applications.

Are earlier versions of BIND vulnerable?

We have not tested (and do not intend to test) BIND8 and BIND4 for this vulnerability since they are EOL (End of Life), vulnerable to other security weaknesses already, and their use is not recommended. However our knowledge of the internals of the BIND8 and BIND4 products leads us to believe that they would both be vulnerable to CVE-2012-1667.