BIND 10 Alpha Program Announcement
BIND 10 Alpha Is Here! https://www.isc.org/wordpress/bind-10-alpha-is-here/ BIND 10 is ISC's next generation of BIND, the most widely used DNS server on the internet. Now in its fourth year, BIND 10 has reached a major milestone: the /Alpha Release/ of our authoritative nameserver. BIND 10 alpha is available now, with the Beta being released toward the end of 2012. The DHCP implementation and recursive resolver are both planned to enter user test later in 2013. It is critical to the success of BIND 10 that we gather feedback from DNS experts, BIND vendor partners, and others who have a strong interest in BIND 10 as early as possible. General purpose and end users are also most welcome to test BIND 10 during the alpha phase, but the real end user push will be for the beta program timeframe. We really do need your feedback... and those who register for the alpha and provide feedback will get not just our undying gratitude, but thanks in the form of the opportunity to win spiffy ISC swag.BIND 10 Alpha is a fully featured authoritative nameserver, focusing on: * Supporting all major DNS protocol standards, including DNSSEC and DDNS * Generic DB backend framework (currently with SQLite3) * Fast and memory efficient in-memory backend * Modular architecture for better customization and resilience For more information, to register for the alpha program and download bind10, please visit , http://www.isc.org/bind10or http://bind10.isc.org Thank you so much for your support, -- Larissa Shapiro Internet Systems Consortium Product Manager Technology Leadership for the Common Good +1 650 423 1335 www.isc.org ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
ISC Security Advisory: Handling of zero length rdata can cause named to terminate,unexpectedly
ISC Security Advisory: Note: This email advisory is provided for your information. The most up to date advisory information will always be at: http://www.isc.org/software/bind/advisories/cve-2012-1667 please use this URL for the most up to date advisory information. Title: Handling of zero length rdata can cause named to terminate unexpectedly Processing of DNS resource records where the rdata field is zero length may cause various issues for the servers handling them. CVE: CVE-2012-1667 Document Version: 1.0 Posting date: 4 June 2012 Program Impacted: BIND Versions affected: 9.0.x - 9.6.x, 9.4-ESV-9.4-ESV-R5-P1, 9.6-ESV-9.6-ESV-R7, 9.7.0-9.7.6, 9.8.0-9.8.3, 9.9.0-9.9.1 Severity: Critical Exploitable: Remotely Description: This problem was uncovered while testing with experimental DNS record types. It is possible to add records to BIND with null (zero length) rdata fields. Processing of these records may lead to unexpected outcomes. Recursive servers may crash or disclose some portion of memory to the client. Secondary servers may crash on restart after transferring a zone containing these records. Master servers may corrupt zone data if the zone option auto-dnssec is set to maintain. Other unexpected problems that are not listed here may also be encountered. Impact: This issue primarily affects recursive nameservers. Authoritative nameservers will only be impacted if an administrator configures experimental record types with no data. If the server is configured this way, then secondaries can crash on restart after transferring that zone. Zone data on the master can become corrupted if the zone with those records has named configured to manage the DNSSEC key rotation. CVSS Score: 8.5 CVSS Equation: (AV:N/AC:L/Au:N/C:P/I:N/A:C) For more information on the Common Vulnerability Scoring System and to obtain your specific environmental score please visit: http://nvd.nist.gov/cvss.cfm?calculatoradvversion=2vector=(AV:N/AC:L/Au:N/C:P/I:N/A:C) Workarounds: Workarounds are under investigation, but none are known at this time. Solution: Upgrade to one of the following versions: https://www.isc.org/software/bind/96-esv-r7-p1 https://www.isc.org/software/bind/976-p1 https://www.isc.org/software/bind/983-p1 https://www.isc.org/software/bind/991-p1 Exploit Status: No known active exploits but a public discussion of the issue has taken place on a public mailing list. Acknowledgment: Dan Luther, Level3 Communications, for finding the issue, Jeffrey A. Spain, Cincinnati Day School, for replication and testing. *Document Revision History: * 1.0 Released to Public 4 June, 2012 1.1 Updated Severity to Critical References: - Do you have questions? Questions regarding this advisory should go to security-offi...@isc.org. - ISC Security Vulnerability Disclosure Policy: Details of our current security advisory policy and practice can be found here: https://www.isc.org/security-vulnerability-disclosure-policy See our BIND Security Matrix for a complete listing of Security Vulnerabilites and versions affected. Note: ISC patches only Currently supported versions. When possible we indicate EOL versions affected. Legal Disclaimer: Internet Systems Consortium (ISC) is providing this notice on an AS IS basis. No warranty or guarantee of any kind is expressed in this notice and none should be inferred. ISC expressly excludes and disclaims any warranties regarding this notice or materials referred to in this notice, including, without limitation, any inferred warranty of merchantability, fitness for a particular purpose, absence of hidden defects, or of non-infringement. Your use of, or reliance on, this notice or materials referred to in this notice is at your own risk. ISC may change this notice at any time. A stand-alone copy or paraphrase of the text of this document that omits the distribution URL in the following section is an uncontrolled copy. Uncontrolled copies may lack important information, be out of date, or contain factual errors. -- === Larissa Shapiro BIND and DHCP Product Manager, Internet Systems Consortium laris...@isc.org +1 650 423 1335 http://www.isc.org Need BIND or DHCP support? Look to the experts! ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Invitation to help ISC out with BIND10 command line tool testing
Dear BIND User Community, The BIND 10 engineering team and are looking for BIND 9 users or other DNS users who would be interested in helping us do some requirements gathering and prototype testing. We're asking a select group of customers to apply to be in a user test project for the command line tool. _What you would need to commit to_: Several 1/2 hr to 1 hr sessions with Shane and Larissa where we walk through command line tool scenarios, later test out the actual tool and provide feedback. _Benefits to you_: Opportunity to make sure their requirements get into the next generation of BIND. Hopefully make their lives easier in the long run. Love, admiration, and probably a free t-shirt. _Benefits to ISC_: Making sure the tool actually meets our users requirements. Hopefully reducing support overhead in the future as a result. Developing and strengthening relationships with our users. If you cannot help out but someone within your group/team is interested, please let me know as soon as possible! We're finalizing participants Wednesday, May 9th. Thank you for your consideration. Larissa Larissa Shapiro BIND and DHCP Product Manager Internet Systems Consortium +1650 423 1335 ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
BIND Security Advisory May 2011: Large RRSIG RRsets and Negative Caching can crash named
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 *Summary:* A BIND 9 DNS server set up to be a caching resolver is vulnerable to a user querying a domain with very large resource record sets (RRSets) when trying to negatively cache a response. This can cause the BIND 9 DNS server (named process) to crash. *Document ID:* CVE-2011-1910 *Document Status:* Draft *Posting date:* 26 May 2011 *Program Impacted:* BIND *Versions affected:* 9.4-ESV-R3 and later, 9.6-ESV-R2 and later, 9.6.3, 9.7.1 and later, 9.8.0 and later *Severity:* High *Exploitable:* Remotely *CVSS Score:* Base 7.8 (AV:N/AC:L/Au:N/C:N/I:N/A:C) For more information on the Common Vulnerability Scoring System and to obtain your specific environmental score please visit: http://nvd.nist.gov/cvss.cfm?calculatoradvversion=2 *Description:* DNS systems use negative caching to improve DNS response time. This will keep a DNS resolver from repeatedly looking up domains that do not exist. Any NXDOMAIN or NODATA/NOERROR response will be put into the negative cache. The authority data will be cached along with the negative cache information. These authoritative ?Start of Authority? (SOA) and NSEC/NSEC3 records prove the nonexistence of the requested name/type. In DNSSEC, all of these records are signed; this adds one additional RRSIG record, per DNSSEC key, for each record returned in the authority section of the response. In this vulnerability, very large RRSIG RRsets included in a negative cache can trigger an assertion failure that will crash named (BIND 9 DNS) due to an off-by-one error in a buffer size check. The nature of this vulnerability would allow remote exploit. An attacker can set up an DNSSEC signed authoritative DNS server with a large RRSIG RRsets to act as the trigger. The attacker would then find ways to query an organization?s caching resolvers, using the negative caches and the ?trigger? the vulnerability. The attacker would require access to an organization?s caching resolvers. Access to the resolvers can be direct (open resolvers), through malware (using a BOTNET to query negative caches), or through driving DNS resolution (a SPAM run that has a domain in the E-mail that will cause the client to do look up a negative cache). *Workarounds:* Restricting access to the DNS caching resolver infrastructure will provide partial mitigation. Active exploitation can be accomplished through malware or SPAM/Malvertizing actions that will force authorized clients to look up domains that would trigger this vulnerability. *Solution:* Upgrade to: 9.4-ESV-R4-P1, 9.6-ESV-R4-P1, 9.7.3-P1 or 9.8.0-P2 ftp://ftp.isc.org/isc/bind9/9.8.0-P2 ftp://ftp.isc.org/isc/bind9/9.7.3-P1 ftp://ftp.isc.org/isc/bind9/9.6-ESV-R4-P1 BIND 9.4 is less vulnerable than other versions, and a patched version will be available on May 27th at ftp://ftp.isc.org/isc/bind9/9.4-ESV-R4-P1 *Exploit Status:* High. This issue has caused un-intentional outages. US CERT is tracking this issue with INC00152411. *Credits:* Thanks to Frank Kloeker and Michael Sinatra for getting the details to this issue to the DNS Operations community and to Michael Sinatra, Team Cmyru, and other community members for testing. Questions regarding this advisory shoud go to security-offi...@isc.org mailto:security-offi...@isc.org. Questions on ISC's Support services or other offerings should be sent to i...@isc.org mailto:dhcp-b...@isc.org More information on ISC's support and other offerings are available at:http://www.isc.org/community/blog/201102/BIND-support - -- Larissa Shapiro Internet Systems Consortium Product Manager Technology Leadership for the Common Good +1 650 423 1335 www.isc.org -BEGIN PGP SIGNATURE- Version: GnuPG/MacGPG2 v2.0.14 (Darwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQEcBAEBAgAGBQJN3zgqAAoJEBOIp87tasiU0RgH/1eOHonKvvh3gcAfzzhWezNr 0X+ERXldJnylLYUrVPoVdzFXCsKkReY6qrTDUJnO6qvB62oYQNfZnO21fkM17m6Z wA/HTnnu5YlnmHZQVabCJptLWsJ7nGwFygKdwgJbu/npWmSaEoKgNWIdcWbnVlm6 xk9XXdjc25rJLIqTgXXWWnyAsFc0SvNomOFd2zkuPsa7vuJczpdWw1Rdn9TP1vOo BF1gS2GR7O9ewghTQGXCAcNNdezconkE7moxTZx6y8qGGyP8nvfRwGWneXKjy49r 8rY1ABo92rly60E8uCs4S8tiFQxTlwWsGBfyREk0SClvT1PFDM+Yz11U/FmBG2E= =QKvu -END PGP SIGNATURE- ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Updated Security Advisory: BIND 9.4-ESV-R4-P1 is now available.
Change: BIND 9.4-ESV-R4-P1 is now available. Title: Large RRSIG RRsets and Negative Caching can crash named. Summary: A BIND 9 DNS server set up to be a caching resolver is vulnerable to a user querying a domain with very large resource record sets (RRSets) when trying to negatively cache a response. This can cause the BIND 9 DNS server (named process) to crash. Document ID: CVE-2011-1910 Posting date: 26 May 2011 Program Impacted: BIND Versions affected: 9.4-ESV-R3 and later, 9.6-ESV-R2 and later, 9.6.3, 9.7.1 and later, 9.8.0 and later Severity: High Exploitable: Remotely CVSS Score: Base 7.8 (AV:N/AC:L/Au:N/C:N/I:N/A:C) For more information on the Common Vulnerability Scoring System and to obtain your specific environmental score please visit: http://nvd.nist.gov/cvss.cfm?calculatoradvversion=2 Description: DNS systems use negative caching to improve DNS response time. This will keep a DNS resolver from repeatedly looking up domains that do not exist. Any NXDOMAIN or NODATA/NOERROR response will be put into the negative cache. The authority data will be cached along with the negative cache information. These authoritative Start of Authority (SOA) and NSEC/NSEC3 records prove the nonexistence of the requested name/type. In DNSSEC, all of these records are signed; this adds one additional RRSIG record, per DNSSEC key, for each record returned in the authority section of the response. In this vulnerability, very large RRSIG RRsets included in a negative cache can trigger an assertion failure that will crash named (BIND 9 DNS) due to an off-by-one error in a buffer size check. The nature of this vulnerability would allow remote exploit. An attacker can set up an DNSSEC signed authoritative DNS server with a large RRSIG RRsets to act as the trigger. The attacker would then find ways to query an organization's caching resolvers, using the negative caches and the trigger the vulnerability. The attacker would require access to an organization's caching resolvers. Access to the resolvers can be direct (open resolvers), through malware (using a BOTNET to query negative caches), or through driving DNS resolution (a SPAM run that has a domain in the E-mail that will cause the client to do look up a negative cache). Workarounds: Restricting access to the DNS caching resolver infrastructure will provide partial mitigation. Active exploitation can be accomplished through malware or SPAM/Malvertizing actions that will force authorized clients to look up domains that would trigger this vulnerability. Solution: Upgrade to: 9.4-ESV-R4-P1, 9.6-ESV-R4-P1, 9.7.3-P1 or 9.8.0-P2 ftp://ftp.isc.org/isc/bind9/9.8.0-P2 ftp://ftp.isc.org/isc/bind9/9.7.3-P1 ftp://ftp.isc.org/isc/bind9/9.6-ESV-R4-P1 ftp://ftp.isc.org/isc/bind9/9.4-ESV-R4-P1 Exploit Status: High. This issue has caused unintentional outages. US CERT is tracking this issue with INC00152411. Credits: Thanks to Frank Kloeker and Michael Sinatra for getting the details to this issue to the DNS Operations community and to Michael Sinatra, Team Cmyru, and other community members for testing. Revision History: Added the 9.4-ESV-R4-P1 download. 2011-May-27 Questions regarding this advisory should go to security-offi...@isc.org. Questions on ISC's Support services or other offerings should be sent to sa...@isc.org. More information on ISC's support and other offerings are available at: http://www.isc.org/community/blog/201102/BIND-support -- Larissa Shapiro Internet Systems Consortium Product Manager Technology Leadership for the Common Good +1 650 423 1335 www.isc.org ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
DNS BIND Security Advisory: RRSIG Queries Can Trigger Server Crash When Using Response Policy Zones
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Note: https://www.isc.org/CVE-2011-1907 is the authoritative source for this Security Advisory. Please check the source for any updates. Summary: When a name server is configured with a response policy zone (RPZ), queries for type RRSIG can trigger a server crash. CVE: CVE-2011-1907 Posting date: 05 May 2011 Program Impacted: BIND Versions affected: 9.8.0 Severity: High Exploitable: remotely Description: This advisory only affects BIND users who are using the RPZ feature configured for RRset replacement. BIND 9.8.0 introduced Response Policy Zones (RPZ), a mechanism for modifying DNS responses returned by a recursive server according to a set of rules which are either defined locally or imported from a reputation provider. In typical configurations, RPZ is used to force NXDOMAIN responses for untrusted names. It can also be used for RRset replacement, i.e., returning a positive answer defined by the response policy. When RPZ is being used, a query of type RRSIG for a name configured for RRset replacement will trigger an assertion failure and cause the name server process to exit. Workarounds: Install 9.8.0-P1 or higher. Active exploits: None. However, some DNSSEC validators are known to send type=RRSIG queries, innocently triggering the failure. Solution: Use RPZ only for forcing NXDOMAIN responses and not for RRset replacement. CVSS Score: Base 6.1, adjusted for lack of targets, score is 1.5 (AV:N/AC:L/Au:N/C:N/I:N/A:C/E:P/RL:O/RC:C/TD:L) For more information on the Common Vulnerability Scoring System and to obtain your specific environmental score please visit: http://nvd.nist.gov/cvss.cfm?calculatoradvversion=2 Thank you to Mitsuru Shimamura at Internet Initiative Japan for finding this defect. For more information on support and other services for ISC's software products, please visit https://www.isc.org/community/blog/201102/BIND-support For more information about DNS RPZ, please check security advisory @ https://www.isc.org/CVE-2011-1907 Questions about this Security Advisory should be sent to the ISC Security Officer security-offi...@isc.org. -BEGIN PGP SIGNATURE- Version: GnuPG/MacGPG2 v2.0.14 (Darwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQEcBAEBAgAGBQJNwzttAAoJEBOIp87tasiU48AH+wXeeHyJbcwzjRmnRfdQuCAW SavRo+SIV9uxf9ya+5n2YeBVf1b0zShTta1XlY29FuEwB775YLiTHUgPlABoXgz0 Kc2zBUSS5Bx2mbfujMTN8u0AUTTIr3HMGCJtNpN4yygdg0jNF3dTfuRC++Mx9uwg zJ0U1mQlnCKV5pCAjWTuukc8dHeI2tWXrUwECd6NiFV+wPZ7ekf+cnXIuEQu0eEA sZ5ggsEnFZGVODBwsFe/wAnmo6xWHYpU6oXyeZ1SRZ/T3eDX0PO4ZaaQYBebwQbh tTtnFBrUGjfCoZi8RaKfiaK+ZvLlyG77zgAq87jC5ZUZ+MWfpv8fgYOiDGa4t1M= =LFc6 -END PGP SIGNATURE- ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Security Advisory: Server Lockup Upon IXFR or DDNS Update Combined with High Query Rate
Internet Systems Consortium Security Advisory Title: Server Lockup Upon IXFR or DDNS Update Combined with High Query Rate (http://www.isc.org/software/bind/advisories/cve-2011-0414) CVE-2011-0414 VU#559980 CVSS: 7.1 (AV:N/AC:M/Au:N/C:N/I:N/A:C) for more information on the Common Vulnerability Scoring System and to obtain your specific environmental score please visit: http://nvd.nist.gov/cvss.cfm?calculatoradvversion=2 http://nvd.nist.gov/cvss.cfm?calculatoradvversion=2 Posting date: 2011-02-22 Program Impacted: BIND Versions affected: 9.7.1-9.7.2-P3 Severity: High Exploitable: Remotely Description and Impact: When an authoritative server processes a successful IXFR transfer or a dynamic update, there is a small window of time during which the IXFR/update coupled with a query may cause a deadlock to occur. This deadlock will cause the server to stop processing all requests. A high query rate and/or a high update rate will increase the probability of this condition. Workaround: Depending on your performance requirements, a work-around may be available. ISC was not able to reproduce this defect in 9.7.2 using -n 1, which causes named to use only one worker thread, thus avoiding the deadlock. If your server is powerful enough to serve your data with a single processor, this option may be fast to implement until you have time to perform an upgrade. Active exploits: None known, but a description of the issue is available in the release notes for BIND 9.6.3 and 9.7.3. Solution: If you run BIND 9.7.1 or 9.7.2, upgrade to BIND 9.7.3. Earlier versions are not vulnerable. If you run BIND 9.6.x, 9.6-ESV-R?, or 9.4-ESV-R4, you do not need to upgrade. BIND 9.5 is End of Life and is not supported by ISC. BIND 9.8 is not vulnerable. Credits: Thank you to Neustar for finding the initial defect and JPRS for further testing and analysis. Questions regarding this advisory or ISC's Support services should be sent to bind9-b...@isc.org mailto:bind9-b...@isc.org For more information on ISC's support, consulting, training, and other services, visit http://www.isc.org/community/blog/201102/open-source-software-unsupported-isnt-it ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: Security Advisory: Server Lockup Upon IXFR or DDNS Update Combined with High Query Rate
Hi Dennis, Thank you for getting 9.7.3 out on Solaris, that is a huge help in getting this important update out there. I do not know the answer to your question about the NIST CVE listings, but I will inquire. Our CVE numbers actually come to us from Carnegie-Mellon CERT, not NIST, but NIST does keep an up to date list generally. I'll also post here if/when I find out more. Best, Larissa On 2/22/11 8:26 PM, Dennis Clarke wrote: Sorry for the top post but there is no data yet at http://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2011-0414. I'll assume that is coming along. I have 9.7.3 ready for relase on Solaris 8 and 9 and 10 however I wanted to refer to the various security info sites. Do you know if the folks at nist are doing an update ? ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Public Advisory on DNSSEC Failures with New DS Records
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Colleagues, ISC has issued a public advisory regarding the DNSSEC issue raised on this list earlier this week. All operators who use or plan to use DNSSEC should take careful note, prior to the addition of .com to the signed root at the end of March. The full advisory is located at: https://www.isc.org/announcement/bind-9-dnssec-validation-fails-new-ds-record Please do not hesitate to contact us directly with any questions regarding this matter. Larissa Larissa Shapiro ISC Product Manager laris...@isc.org +1 650 423-1335 -BEGIN PGP SIGNATURE- Version: GnuPG/MacGPG2 v2.0.14 (Darwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQEcBAEBAgAGBQJNTJWUAAoJEBOIp87tasiUcJUH/0ojZQGLCB2bI31fo7U2OBW3 Ft00kxiMH/bM+EnO+l2aM9SVsPAZBPv9vsP3zvJYOpYPLgxMyap/HwIXmrwu37de gh7cpPAFD48dWK5Txby5F/GMDobbT1UiTTr3BtTGdCHY744siR4w0fNIEbnRLtKB RNUxXRrt/csMs1YQNn05bI4HIooZ8VgNc9pt7c0YcP5+ZWfMJRRnqFGcNxgGxDMt wD5oZ7bej5F035WZhdRpB+rFYvbJ/pKRj3GBYH0yQgI1wRmk92KozPOtGfa0Gjj8 yEJ8Cg1jgGHLtZcjCxqEqaX3XkKWL5D1l0mkt8uq7ut9WWOgIPDpqaF/6aToOnU= =zNed -END PGP SIGNATURE- ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Update to CVE 2010-3613
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 ISC has updated CVE 2010-3613 and the associated operational guidance based on feedback from one of our forum members. The update changes affected versions to include versions of BIND 9 back to 9.0.x. Please review carefully and respond appropriately if you are running an affected version. Best Regards, Larissa Larissa Shapiro ISC Product Manager - -- Updated CVE: BIND: cache incorrectly allows a ncache entry and a rrsig for the same type Summary: Failure to clear existing RRSIG records when a NO DATA is negatively cached could cause subsequent lookups to crash named. CVE: CVE-2010-3613 CERT: VU#706148 Posting date: 01 Dec 2010 Revision: 14 December 2010 Program Impacted: BIND Versions affected: 9.0.x to 9.7.2-P2, 9.4-ESV to 9.4-ESV-R3, 9.6-ESV to 9.6-ESV-R2 Severity: High Exploitable: remotely Description: Adding certain types of negative signed responses to cache doesn't clear any matching RRSIG records already in cache. A subsequent lookup of the cached data can cause named to crash (INSIST). CVSS Base Score: 7.8 - (AV:N/AC:L/Au:N/C:N/I:N/A:C) For more on CVSS scores and to calculate your environment's specific risk, please visit: http://nvd.nist.gov/cvss.cfm?version=2vector=(AV:N/AC:L/Au:N/C:N/I:N/A:C) Impact and Risk Assessment: The INSIST crashes the server. This vulnerability affects recursive nameservers irrespective of whether DNSSEC validation is enabled or disabled. Workarounds: none Active exploits: None known at this time. Solution: The versions listed below are supported by ISC. All other versions are End of Life, and will not be patched. If you are running a version not listed below, you should upgrade as soon as possible. 9.4.x: upgrade to 9.4-ESV-R4, or newer 9.6.x: upgrade to 9.6.2-P3 or newer 9.6-ESV: upgrade to 9.6-ESV-R3 or newer 9.7.x: upgrade to 9.7.2-P3 Acknowledgment: Shinichi Furuso Revision History: 24 November 2010: Corrected/Updated: Versions affected, CVSS Score, Impact, Risk Assessment and Solution 14 December 2010: Updated Versions Affected, Solution and Acknowledgment For more information please contact bind9-b...@isc.org - --- Updated Guidance Text: CVE: CVE-2010-3613 CERT: VU#706148 BIND: cache incorrectly allows a ncache entry and a rrsig for the same type Although the defect is very unlikely to be encountered in normal operation, if your recursive resolver is being used to query public Internet zones and you cannot readily restrict your client queries then there is the potential for a remote attacker to cause your nameserver to crash. Note particularly that disabling DNSSEC validation is NOT an effective workaround. * We recommend that you plan to upgrade immediately if ALL of the following apply to your BIND installation: a) You are operating a recursive server which obtains answers from public Internet zones. b) You are running any version of BIND 9 including or prior to: 9.6.2 - 9.6.2-P2, 9.4-ESV - 9.6-ESV-R2, 9.7.0 - 9.7.2-P2 c) The DNS clients accessing your resolver constitute a large pool and are not under you control or you can not limit access only to machines with full trust. * We suggest that you put this upgrade in your plans for 2011 if you are not operating recursive DNS servers. -BEGIN PGP SIGNATURE- Version: GnuPG/MacGPG2 v2.0.14 (Darwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQEcBAEBAgAGBQJNB5RCAAoJEBOIp87tasiUZcMH/jFqkwCA1QBj8utQ13690aIF VIGZfDAriYyFx/nUxu0B67ZbTKcjWxbPr1MBlPKh911Hy7ZmPRYAsu3YWPFLsUTd +zzoKI7u3T8jrSp9TdgKdjzJPJIhOTABJoUNoZaJIjVM3VhUN0ha/RupGDXNz8tB J7nv0q8AiTOZlWFOGP8LzLxCI7SQxevmNBmaeOVbvrNJt8Bla4MMQhJss01qxmBa aq5FXPFZ9BQKHIZacspbeVrKjtOW1nU0FVZHBUwVK3CbnYGTAW9vVvVo3qBcb5vT h0rRHoa5R8QQfG4mVHmreZIBdpRs/3BtXUAGhnN0a3KVR2QQl7wOFDkXSYhKi64= =WvDz -END PGP SIGNATURE- ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
BIND 10 Operational Requirements Survey: Help shape the future of BIND
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Dear User Community - BIND 10 is now in its second year of development, and we would like to hear more from current BIND 9 users about operational needs for BIND 10 as we move toward the more user-facing aspects of BIND 10 development. This survey will ask about your specific business and operational environment, what works well for you in BIND 9 and what does not, and then what aspects of BIND 9 would be critical for you to maintain in migrating to BIND 10. This data will be used to develop user-facing aspects of BIND 10 including but not limited to the command line interface. Your responses will be kept confidential. We would like to contact some respondents by phone for further discussion, so please indicate if this is an option for you. Participants in the follow on phone call will receive a BIND 10 t-shirt as a thank you. Thank you for your time, and for your support of ISC and BIND. The survey is at: http://www.isc.org/announcement/give-your-input-future-bind Best, Larissa Larissa Shapiro BIND and DHCP Product Manager -BEGIN PGP SIGNATURE- Version: GnuPG/MacGPG2 v2.0.14 (Darwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQEcBAEBAgAGBQJM2uvGAAoJEBOIp87tasiULTMIAJrt2WxQrJG2mwFwUc0a5kPJ b/YlFgHuDyO4eMwnbMzFllhGFWLfeePu60chU81AxcVP7Pxs8JC5bX6idLUVK0Y3 vVfETsze4iK3YBLkpSL23oN61f6b31oypn+gdYoIVU13EO1VUG3Dy5CsE0CG95DP tjcwXYdC04da/L/oeQwfCTvwppusfzzvWG92JaABpgmFmy7DkmvWaleq6TZrbqIV orn8ruWVvuZ9S1XfXYkLhLYwus00KG62sJfm9VQQSWng1/W/iA3kHvr5/EUjir50 xUE4NJkmZfi5+GniNhm2el9LjrP3heRtSOA56wlsNLtoNIUO4ib0Y5dp5MV3bzI= =hlIJ -END PGP SIGNATURE- ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Notice regarding BIND 9.7.2
Dear User Community, ISC has learned of a late-breaking bug in the BIND 9.7.2 code base, so we have removed it from our website and ftp site as it is not currently recommend for deployment. BIND 9.7.1-P2 is our current recommended release for Production. We will provide more information on these developments early next week, as soon as they are available. Larissa Shapiro ISC Product Manager ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: rndc reconfig delays
Probably. I'd like to get Michael's feedback... I have not heard of this from anyone else have either of you? On Aug 26, 2010, at 3:22 PM, Rob Foehl wrote: I've been experimenting with loading a large number of master zones (on the order of 250,000) in a single BIND instance, and have noticed that 'rndc reconfig' with this many zones loaded can take a very long time to determine that it has little or nothing to do. Worse, the server stops answering other requests for the duration, in both threaded and non-threaded builds -- I'm testing with 64 bit builds of both 9.7.0-P1 and 9.7.1-P2. In the best case, a reconfig will take about 40 seconds to complete, and stalls the server for most of that time. Loading zones in bulk is substantially slower, but is less of an issue for the intended use, and is more or less limited by the speed of the storage. My next step is going to be to experiment with the rndc addzone/ delzone feature in the 9.7.2 betas, which hopefully should avoid any need to attempt a reconfig during normal use. That aside, is there anything else I could be doing to speed things up? -Rob ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
BIND 9.7.1-P1 Release Announcement
BIND 9.7.1-P1 is now available. BIND 9.7.1-P1 is a maintenance release for BIND 9.7. BIND 9.7.1-P1 addresses two backwards compatibility issues introduced in BIND 9.7.0: 1) BIND 9.7.x expected negative responses to be in a certain format, one that matches what BIND generates. However, some non-BIND servers (including custom-created servers and load balancers) did not include everything BIND expected, so BIND returned SERVFAIL to the client. 2) BIND 9.6.x and earlier accepted authoritative answers, even if the AA (authoritative data) bit was not set. This was done to work around TLD servers that were not correctly setting this bit. In BIND 9.7.0, answers without the AA bit set resulted in SERVFAIL, even if there was an answer. BIND 9.7.1-P1 fixes the bug in issue #1 and backs out the code in issue 2 (AA bit strictness), restoring the pre-9.7.x behavior. See this article for more details: http://www.isc.org/community/blog/201007/compatibility-issues-bind-970-and-971 BIND 9.7.1-P1 can be downloaded from ftp://ftp.isc.org/isc/bind9/9.7.1-P1/bind-9.7.1-P1.tar.gz The PGP signature of the distribution is at ftp://ftp.isc.org/isc/bind9/9.7.1-P1/bind-9.7.1-P1.tar.gz.asc ftp://ftp.isc.org/isc/bind9/9.7.1-P1/bind-9.7.1-P1.tar.gz.sha256.asc ftp://ftp.isc.org/isc/bind9/9.7.1-P1/bind-9.7.1-P1.tar.gz.sha512.asc The signature was generated with the ISC public key, which is available at https://www.isc.org/about/openpgp. A binary kit for Windows XP and Window 2003 is at ftp://ftp.isc.org/isc/bind9/9.7.1-P1/BIND9.7.1-P1.zip ftp://ftp.isc.org/isc/bind9/9.7.1-P1/BIND9.7.1-P1.debug.zip The PGP signature of the binary kit for Windows XP and Window 2003 is at ftp://ftp.isc.org/isc/bind9/9.7.1-P1/BIND9.7.1-P1.zip.asc ftp://ftp.isc.org/isc/bind9/9.7.1-P1/BIND9.7.1-P1.zip.sha256.asc ftp://ftp.isc.org/isc/bind9/9.7.1-P1/BIND9.7.1-P1.zip.sha512.asc ftp://ftp.isc.org/isc/bind9/9.7.1-P1/BIND9.7.1-P1.debug.zip.asc ftp://ftp.isc.org/isc/bind9/9.7.1-P1/BIND9.7.1-P1.debug.zip.sha256.asc ftp://ftp.isc.org/isc/bind9/9.7.1-P1/BIND9.7.1-P1.debug.zip.sha512.asc Changes since 9.7.1. --- 9.7.1-P1 released --- 2926. [rollback] Temporarily rollback change 2748. [RT #21594] 2925. [bug] Named failed to accept uncachable negative responses from insecure zones. [RT# 21555] --- 9.7.1 released --- ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: BIND 9.7.1-P1 planned to address issues in BIND 9.7.0 and 9.7.1
All, Michael Graff, BIND 9 Engineering Manager, posted a blog entry today addressing questions around the upcoming BIND 9.7.1 patch release. The entry can be found at: https://www.isc.org/community/blog/201007/compatibility-issues-bind-970-and-971 Please feel free to contact us if you have further questions. Best Regards, Larissa === Larissa Shapiro ISC Product Manager laris...@isc.org http://www.isc.org ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
BIND 9.7.1-P1 planned to address issues in BIND 9.7.0 and 9.7.1
Dear Users, We have received reports that BIND 9.7.0 and 9.7.1 are failing to resolve certain zones. These zones are resolved correctly by earlier versions of BIND. BIND 9.7.0 and 9.7.1 follows the DNS protocol more strictly than earlier versions. We felt that this change created added safety for certain types of responses from potentially misconfigured servers, but now believe it is hurting more than helping. We are planning a patch release to revert to previous behavior. We hope to get BIND 9.7.1-P1 released to our forum members this week and to the public shortly after. This patch will also include an unrelated compatibility fix for responses from some non-BIND servers. The strictness checking may be added again in a future version, with ample notification and any backwards-compatibility support that may be required. Please do not hesitate to contact me with any questions or concerns. Best Regards, Larissa Larissa Shapiro ISC Product Manager +1 650 423 1335 laris...@isc.org http://www.isc.org ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
BIND 9.7.1 is now available
BIND 9.7.1 is now available. BIND 9.7.1 is a maintenance release for BIND 9.7. BIND 9.7.1 can be downloaded from ftp://ftp.isc.org/isc/bind9/9.7.1/bind-9.7.1.tar.gz The PGP signature of the distribution is at ftp://ftp.isc.org/isc/bind9/9.7.1/bind-9.7.1.tar.gz.asc ftp://ftp.isc.org/isc/bind9/9.7.1/bind-9.7.1.tar.gz.sha256.asc ftp://ftp.isc.org/isc/bind9/9.7.1/bind-9.7.1.tar.gz.sha512.asc The signature was generated with the ISC public key, which is available at https://www.isc.org/about/openpgp. A binary kit for Windows XP and Window 2003 is at ftp://ftp.isc.org/isc/bind9/9.7.1/BIND9.7.1.zip ftp://ftp.isc.org/isc/bind9/9.7.1/BIND9.7.1.debug.zip The PGP signature of the binary kit for Windows XP and Window 2003 is at ftp://ftp.isc.org/isc/bind9/9.7.1/BIND9.7.1.zip.asc ftp://ftp.isc.org/isc/bind9/9.7.1/BIND9.7.1.zip.sha256.asc ftp://ftp.isc.org/isc/bind9/9.7.1/BIND9.7.1.zip.sha512.asc ftp://ftp.isc.org/isc/bind9/9.7.1/BIND9.7.1.debug.zip.asc ftp://ftp.isc.org/isc/bind9/9.7.1/BIND9.7.1.debug.zip.sha256.asc ftp://ftp.isc.org/isc/bind9/9.7.1/BIND9.7.1.debug.zip.sha512.asc Changes since 9.7.0. --- 9.7.1 released --- --- 9.7.1rc1 released --- 2909. [bug] named-checkconf -p could die if update-policy local; was specified in named.conf. [RT #21416] 2908. [bug] It was possible for re-signing to stop after removing a DNSKEY. [RT #21384] 2907. [bug] The export version of libdns had undefined references. [RT #21444] 2906. [bug] Address RFC 5011 implementation issues. [RT #20903] 2905. [port] aix: set use_atomic=yes with native compiler. [RT #21402] 2904. [bug] When using DLV, sub-zones of the zones in the DLV, could be incorrectly marked as insecure instead of secure leading to negative proofs failing. This was a unintended outcome from change 2890. [RT# 21392] 2903. [bug] managed-keys-directory missing from namedconf.c. [RT #21370] --- 9.7.1b1 released --- 2902. [func] Add regression test for change 2897. [RT #21040] 2901. [port] Use AC_C_FLEXIBLE_ARRAY_MEMBER. [RT #21316] 2900. [bug] The placeholder negative caching element was not properly constructed triggering a INSIST in dns_ncache_towire(). [RT #21346] 2899. [port] win32: Support linking against OpenSSL 1.0.0. 2898. [bug] nslookup leaked memory when -domain=value was specified. [RT #21301] 2897. [bug] NSEC3 chains could be left behind when transitioning to insecure. [RT #21040] 2896. [bug] rndc sign failed to properly update the zone when adding a DNSKEY for publication only. [RT #21045] 2895. [func] genrandom: add support for the generation of multiple files. [RT #20917] 2894. [contrib] DLZ LDAP support now use '$' not '%'. [RT #21294] 2893. [bug] Improve managed keys support. New named.conf option managed-keys-directory. [RT #20924] 2892. [bug] Handle REVOKED keys better. [RT #20961] 2891. [maint] Update empty-zones list to match draft-ietf-dnsop-default-local-zones-13. [RT# 21099] 2890. [bug] Handle the introduction of new trusted-keys and DS, DLV RRsets better. [RT #21097] 2889. [bug] Elements of the grammar where not properly reported. [RT #21046] 2888. [bug] Only the first EDNS option was displayed. [RT #21273] 2887. [bug] Report the keytag times in UTC in the .key file, local time is presented as a comment within the comment. [RT #21223] 2886. [bug] ctime() is not thread safe. [RT #21223] 2885. [bug] Improve -fno-strict-aliasing support probing in configure. [RT #21080] 2884. [bug] Insufficient valadation in dns_name_getlabelsequence(). [RT #21283] 2883. [bug] 'dig +short' failed to handle really large datasets. [RT #21113] 2882. [bug] Remove memory context from list of active contexts before clearing 'magic'. [RT #21274] 2881. [bug] Reduce the amount of time the rbtdb write lock is held when closing a version. [RT #21198] 2880. [cleanup] Make the output of dnssec-keygen and
