2015 ISC Open Source Accomplishments

We are proud of another year of solid, responsible maintenance of our three core software products, BIND, ISC DHCP and Kea.

BIND

2015 Releases

We issued four BIND9 maintenance releases and twelve security patch releases. In addition we made five releases of our -S edition for subscribers and two experimental releases. The last two types of releases incorporate both features and bug fixes.

• Maintenance releases: 9.9.7 & 9.9.8; 9.10.2 & 9.10.3
• Security releases: 9.9.6-P2, 9.9.7-P1, 9.9.7-P2, 9.9.7-P3, 9.9.8-P2, 9.10.1-P2, 9.10.1-P2, 9.10.2-P1, 9.10.2-P2, 9.10.2-P3, 9.10.2-P4, 9.10.3-P2
• Subscription releases (incorporate both features and bug fixes): 9.9.6-S3, 9.9.7-S1, 9.9.7-S6, 9.9.8-S1, 9.9.8-S3
• Experimental releases (for testing the Resolver DDOS mitigation features): 9.9.6-EXP1, 9.9.6-EXP2

New Feature Development

• In BIND 9.10.3 we released two significant new features, ‘fetches per zone’ and ‘fetches per server’ which enable resolver rate limiting. These features have proven useful for mitigating DDOS attacks effects on resolvers. (/blogs/tldr-resolver-ddos-mitigation/)
• We worked on the new features which will be released in the upcoming BIND 9.11 version, incorporating a significant dyndb driver patch submitted by RedHat. Other features developed include dnstap support, nxdomain-redirect, two features addressing IPv6 bias, a message-compression option, transfer-message-size and miscellaneous improved statistics counters.
• We published an IETF draft on the design for Catalog Zones, a significant feature we are adding in BIND 9.11. We previously published requirements documents for these features in Google Docs to solicit feedback from users.

Other Accomplishments

• We finalized the BIND DNSSEC Guide and added a very concise DNSSEC for BIND Quick Reference Guide.
• We updated our root hints file to reflect the new addresses for H Root, which was renumbered in December, 2015.
• We began giving accounts on our issue tracking system to open source packagers, giving them access to their own reports in our system. This is a fairly limited step towards greater openness, but we need to also preserve the privacy of issue reporters who sent in reports to a closed system with a reasonable expectation that it would remain closed.

Maintenance & QA

• We opened 625 new issues in BIND. We resolved 55% of the new issues opened, for a total of 486 (including some older issues). The result was we added to our backlog of issues. We don’t have an accurate breakdown of the proportion of these issues that are feature requests vs defect reports, but we know that at least 12% of the reports are enhancement requests.
• However, when you focus on the most important issues, those rated as Severity 0 (critical) or 1 (High), we resolved many more than were opened. We opened 50 new issues and resolved 70 existing issues. 16% of the tickets we resolved were high severity.
• We use the free Coverity open source static analysis extensively and display the current Coverity status of each of our major software packages on the ISC website. As of February 1, 2016, the Coverity open source scan was showing 0 BIND defects. We fixed 40 Coverity-identified defects in BIND in 2015.
• After we received a reported security vulnerability uncovered using the AFL fuzz testing tool, we developed our own tests using the AFL tool and have made it a regular part of our regression process. Despite this, we subsequently got at least one additional bug report someone outside ISC discovered, again using the AFL tool.
• Four new system test groups were added to BIND 9; (ednscompliance, fetchlimit, rpzrecurse, and statschannel). Approximately 194 new system tests were introduced.
• We did extensive testing of 5011 DNSSEC Key rollovers with BIND, in preparation for a possible root key rollover.

Security

• We issued seven BIND CVEs.
• Several organisations have asked us whether the “GHOST” vulnerability in the glibc library has an impact in BIND. After examining the code, we think that the core BIND is immune to the problem; however, the contributed MySQL DLZ driver is vulnerable.
• We were also asked about some OpenSSL vulnerabilities. We tested and verified an updated version of OpenSSL and recommended users update.
• We had several security vulnerabilities reported just as we entered the holiday period. The release dates of the fixes were the subject of considerable internal discussion because we know that holiday freeze periods are common. In 2016 we are planning to publish a policy on security announcement timing during holiday periods.

ISC DHCP

2015 Releases

We issued five DHCP maintenance releases in 2015.

• Maintenance releases: DHCP 4.1-ESV-R11 & DHCP 4.1-ESV-R12, DHCP 4.2.8, DHCP 4.3.2 & 4.3.3 (plus 10 beta and release candidate versions)
• We discontinued support for ISC DHCP version 4.2 after publishing DHCP 4.2.8

Development

• The 4.3.3 release incorporated over two dozen changes to the contributed LDAP code. Although reviewing and integrating all of these patches was a significant job for us, we appreciate the community contributions.
• In release 4.3.3 we added a compile time option that we believe will improve performance significantly for most users.
• We also fixed an issue that caused the lease queues to be incorrect. This could manifest during failover as an inconsistency between the two servers causing one of them to appear to run out of addresses.
• We published an article on DHCPv4 server performance, explaining where the bottlenecks are, and suggesting some ways to improve performance.

Maintenance & QA

• The backlog of DHCP issues shrank modestly in 2015. We opened 124 new issues and resolved 50% of them, resolving 133 issues in total. At least 18% of these issues were feature requests, the remainder being defect reports.
• We also reduced the backlog of the most severe (S0 & S1) issues, we opened 14 new issues and resolved 17 existing issues.
• As of January 22nd, 2016, ISC DHCP had 22 defects listed in Coverity Scan, for a low defect density of .18. We fixed 14 Coverity defects in 2015.
• We transitioned our on-going continuous integration testing from Robie to the newer Jenkins system. This has enabled us to add a number of additional operating systems to our regular regression, and will eventually allow us to provide public visibility to our build status. We are now running continuous regressions against: Centos 6.x (32 bit), 7.x (64 bit), Debian 7.x (64 bit), Fedora 20 (32 & 64 bit), FreeBSD 10.1 (32 & 64 bit), HPUX11 (64 bit), RHEL 6.s (64 bit), Solaris 11 (32 bit), Ubuntu 14.04 LTS (32 & 64 bit).

Security

We did not have any significant security vulnerabilities in ISC DHCP to report in 2015, although we got one at the end of the year which was disclosed in early 2016. We checked DHCP for the GHOST problem (see above) and do not believe that it poses any security vulnerability.

Kea

2015 Releases

• We issued two Kea feature releases in 2015, Kea 0.9.2 and Kea 1.0.

New Feature Development

• Kea 0.9.2 added statistics, logging and a remote control channel, features required for ISC to provide technical support for production deployments.
• Kea 1.0 was a major update, adding lease expiration, basic client classification, DECLINE support in both DHCPv4 and DHCPv6, PXE and iPXE boot support, and limited support for storing DHCPv4 host reservation information in MySQL.

Other Accomplishments

• We began offering professional technical support subscriptions for Kea, and got our first customer, a large ISP who used Kea in a public wifi service offering.
• We created a prototype Secure DHCP implementation with the ISC DHCP client which was demonstrated at the IETF Hackathon in Prague.
• We received a significant community contribution, not yet complete, implementing DHCPv4 over DHCPv6.
• Facebook did another public presentation on how using Kea to virtualize DHCP services for their massive internal datacenter simplified operations. (https://www.isc.org/blogs/how-facebook-is-using-kea-in-the-datacenter/)
• At the end of 2015, with the release of Kea 1.0, we changed the open source license agreement. We decided to move to the Mozilla Public License (MPL 2.0)(https://www.isc.org/blogs/kea-license-2-0/). Our goal was to ensure that Kea development will be supported in the future by those people who use and extend it.

Maintenance & QA

Unlike our other software, Kea uses an open bug database that anyone can review.

• 204 defects were identified in 2015, and 143 were closed. We closed a total of 346 tickets in 2015, including 124 enhancements and 70 tasks, in addition to the defects.
• As of February 1, 2016, Coverity Scan showed 121 defects in Kea. This equates to a defect density of .47, average for a project of Kea’s size. The Kea team fixed 96 defects identified by Coverity in 2015.
• The Kea continuous integration testing is done using Jenkins automation. The current test status is always visible at https://jenkins.isc.org

Security

We did not have any significant security vulnerabilities in Kea to report in 2015, although we got one at the end of the year which was disclosed in early 2016.

Summary Statistics