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.
When these records were not found in the message, we would “fall off the end of the list” and return a “not found” error, which was treated as a hard failure by the upper-layer code, and SERVFAIL was returned to the client.
The second issue was a protocol strictness issue. The versions of BIND mentioned above require a much more strict message response from servers. Specifically, 9.6 and earlier would allow messages without the AA bit (authoritative data) set to be accepted as answers if the rest of the message appeared to be an answer. This was done as a work-around for some TLD servers which mis-handled the AA bit.
When the TLD servers were fixed to correctly set or not set the AA bit, BIND 9 was told to start paying attention to it as the protocol specifies. However, it appears other servers (once again, many custom servers as well as load balancers) also do not properly set the AA bit. This caused those domains to fail, and SERVFAIL returned to the client.
The BIND 9.7.1-P1 release addresses these two issues. There is no configuration knob for the “missing records” issue as it is a bug in BIND. We are not including a tunable option for the strictness check in the 9.7.1-P1 release.
We may re-introduce the “AA bit strictness” check back into a BIND 9 release. However, should we do so, it would be done with more notice, more testing, and it will be an option at that time. Because this follows the “be gracious in what you receive” principle we may choose to not require strict protocol compliance instead.
If people see the need (not desire, but need) for the “AA bit strictness check” to be an option sooner, we could consider it for 9.7.2, which is scheduled for release in September. However, at this time, with 9.7.1-P1, we feel reverting to previous behavior is easier to test and less disruptive for a patch release.