On Thu, Feb 24, 2011 at 9:51 AM, Michael Sinatra <span dir="ltr"><<a href="mailto:michael@rancid.berkeley.edu">michael@rancid.berkeley.edu</a>></span> wrote:<br><div class="gmail_quote"><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
BIND 9.7.3 correctly fixes an issue not currently related to the CVE that has just been released.  This issue involves case-sensitivity issues in secondary zones, which can cause validation problems for NSEC records if the zone in question is DNSSEC-signed.  The problem manifests itself when the secondary's named.conf has a different case versus the original zone when it was signed, e.g. br vs. BR.  It can cause unsigned delegations to fail since the nonexistence of the DS record can't be proven.  It's a pretty small corner-case, but it can affect zones with several secondaries and many signed and unsigned delegations (e.g. signed ccTLDs).<br>

<br></blockquote><div><br>As an illustration, here is the impact that this had on insecure delegations from <a href="http://berekeley.edu">berekeley.edu</a>:<br><br><a href="http://dnsviz.net/d/cs.berkeley.edu/1297818000000000/dnssec/">http://dnsviz.net/d/cs.berkeley.edu/1297818000000000/dnssec/</a><br>
<br>Note that two distinct NSEC RRs were returned by the collective set of servers authoritative for <a href="http://berkeley.edu">berkeley.edu</a> for proving non-existence of <a href="http://cs.berkeley.edu/DS">cs.berkeley.edu/DS</a>.  Two of the six servers were serving an NSEC RR that had a name mixed case in the "next" field, and the others all had only lower case.  However, all servers were serving the same RRSIG covering the NSEC.  Since the RRSIG was made from the NSEC with lower case, the RRSIG didn't validate against the NSEC served by the two servers.<br>
<br>Casey<br><br></div></div>