Operational Notification: DNSSEC key deletion may create broken NSEC and NSEC3 chains and unnecessary RRSIGs
  • 30 Nov 2018
  • 3 Minutes to read
  • Contributors
  • Dark
    Light
  • PDF

Operational Notification: DNSSEC key deletion may create broken NSEC and NSEC3 chains and unnecessary RRSIGs

  • Dark
    Light
  • PDF

Article Summary

Posting date: 30 November 2018

Program Impacted: BIND

Versions affected: 9.9.13- > 9.9.13-P1, 9.10.8 -> 9.10.8-P1, 9.11.4 -> 9.11.5, 9.12.2 -> 9.12.3. Also versions 9.13.1 -> 9.13.4 of the 9.13 development branch.

Description

Code change #4964, intended to prevent double signatures when deleting an inactive zone DNSKEY in some situations, introduced a new problem during zone processing in which some delegation glue RRsets are incorrectly identified as needing RRSIGs, which are then created for them using the current active ZSK for the zone. In some, but not all cases, the newly-signed RRsets are added to the zone's NSEC/NSEC3 chain, but incompletely -- this can result in a broken chain, affecting validation of proof of nonexistence for records in the zone.

Impact: A version of BIND which is affected by this defect may cause several related problems when maintaining DNSSEC-signed zones. Note: the errors described here occur during the process of signature maintenance; only servers which are signing (or re-signing) DNSSEC-signed zones are directly affected.

  1. improper signing of glue records: we believe the unnecessary signatures generated for the glue records should not cause problems for validating resolvers (although some DNSSEC validity checkers may highlight them as an issue.) BIND pays no attention to these specific signatures and we believe that the same is likely true of other validating resolvers.
  2. broken NSEC/NSEC3 chains: in some (but not all) cases the improperly-signed glue records can be added to the zone's NSEC/NSEC3 chain, resulting in a broken chain. Any broken NSEC or NSEC3 chain may cause DNSSEC validation of negative responses from an affected zone to fail. For example, instead of returning an NXDOMAIN response which is properly validated, a resolver may instead return a SERVFAIL to the client.
  3. missing secure proof of insecure delegation when using NSEC3 opt-out: the impact of any broken NSEC3 chains can be more severe where NSEC3 is used with OPTOUT, in which case the negative responses that cannot be DNSSEC-validated may also include some that should prove non-existence of DS RRs. This can result in validating resolvers returning SERVFAIL responses to clients for entire subdomains whose delegation status cannot be verified, and thus are treated as bogus.

Workarounds: Until replacement versions of BIND are made available which contain a fix for the bug, we strongly recommend not removing any keys which are present for a zone, irrespective of whether they are currently active. If you are in the process of rolling keys we recommend that you deactivate any obsolete keys but do not delete them from the DNSKEY RRset.

Solution

ISC plans to release patched versions of BIND which correct the signature maintenance issues introduced in change #4964 but they must first be created, put through our internal testing, and only then released to public. In the meantime we have chosen to issue this Operational Notification to warn those who are signing their domains about the potential problem. Until the patched replacement releases are available we recommend following the advice in the "Workarounds" section.

Do you still have questions? Questions regarding this advisory should go to security-officer@isc.org. To report a new issue, please encrypt your message using security-officer@isc.org's PGP key which can be found here: https://www.isc.org/downloads/software-support-policy/openpgp-key/. If you are unable to use encrypted email, you may also report new issues at: https://www.isc.org/community/report-bug/.

Note: ISC patches only currently supported versions. When possible we indicate EOL versions affected. (For current information on which versions are actively supported, please see https://www.isc.org/downloads/).

ISC Security Vulnerability Disclosure Policy: Details of our current security advisory policy and practice can be found here: ISC Software Defect and Security Vulnerability Disclosure Policy.

This Knowledgebase article is the complete and official security advisory document.

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 implied. ISC expressly excludes and disclaims any warranties regarding this notice or materials referred to in this notice, including, without limitation, any implied warranty of merchantability, fitness for a particular purpose, absence of hidden defects, or of non-infringement. Your use 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 document URL is an uncontrolled copy. Uncontrolled copies may lack important information, be out of date, or contain factual errors.