In response to our customers and colleagues, ISC has chosen to remove the RTT Banding feature from BIND 9, starting with BIND 9.8.0. Other supported versions will have RTT Banding removed in their next releases.
BIND 9.8.0 is scheduled to go out on March 1st, 2011. 9.8.1 will follow around a month later.
Prior to deploying DNSSEC it has been possible to perform something I'm calling "lazy delegation." This is when a parent and direct child are served from the same name servers, so NS records in the parent are unnecessary in practice.
While consulting with various clients about how to best deploy their DNSSEC, this is a common discovery. Often times someone just forgot to add NS records, or their tools do not add them. No one notices because their DNS worked.
ISC has been working with Tridge from the Samba team to make it easier to configure BIND 9 to use GSS-TKEY. GSS-TKEY is used to allow Windows clients to securely update DNS zones using dynamic DNS, primarily in an Active Directory environment.
These changes may be coming as early as BIND 9.8.0, which is scheduled to be released in late January, 2011. They were proposed and written by the Samba team in order to more easily integrate BIND 9 with Samba 4.
Yesterday I blogged about how ISC has been changing our internal development practices for BIND 9. Today, with the release of several security patches, I wanted to talk a bit on how they have helped us already.
In many projects, and previously in BIND 9, tests were written after the code was working. This left writing automated tests as an afterthought at best, and meant our tests were not as robust. One common problem was that the test didn’t actually test what we thought it did.
ISC has begun implementing several methodology changes relating to BIND 9 development. The goals of these changes is to increase our software quality and relevance to you, our customers. Some of these are more internal, but we hope the outcome of these changes are that the effects are positive and noticed by those outside of ISC.
As with all changes, we’ll get some of it right and some we’ll have to revisit and modify as we learn. We welcome any feedback about where we are now, where you would like us to be, and as we progress along our path.
To use the signed root zone in DNSSEC validation in your BIND 9 resolvers, you must be running BIND 9.6.2 or higher. Earlier versions do not support the required algorithms to enable validation using the root zone's key. It is strongly recommended you run BIND 9.7 to use the automatic key updating functionality.
Now that the root zone has been officially signed, what happens with ISC's DNSSEC Look-aside Validation Registry? The short answer is, it gets smaller, but does not go away, at least not today.
While having the root signed is a critically important step in the DNSSEC deployment effort, it is not the final step. It's the one that enables a lot of other zones such as Top Level Domains (TLDs) to be signed usefully. It removes the need for many stop-gap measures like certain TARs, and the need for TLD entries in ISC's DLV system.
ISC has announced that there were some backwards compatibility problems in the 9.7.1 release. Here is a bit more information on the topic. These problems were also in 9.7.0.
The first issue was a problem in how those versions of BIND 9 processed certain formats of negative responses. In particular, BIND 9's internal logic expected certain records to be present because that is what BIND 9 generated. Some other types of servers (many were custom-created it appears) did not include everything we expected to find, and sometimes those had to be queried for.
BIND 9.7.0 introduced automatic in-server signature re-freshing and automatic key rollover. This allows BIND 9.7, if provided with the DNSSEC private key files, to sign records as they are added to the zone, or as the signatures need to be refreshed. This refresh happens periodically to spread out the load on the server and to even out zone transfer load.
The DNS community is buzzing with activity around the implementation of the DNS Security Extension, DNSSEC. In simple terms, DNSSEC provides a "chain of trust" within the DNS hierarchy and the authentication of DNS responses. Once deployed across the DNS, DNSSEC will render the infamous man-in-the-middle attack a thing of the past.