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.

   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.


   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 response 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.


   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.


   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 the 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 To report a new issue, please
encrypt your message using's PGP key which
can be found here:
If you are unable to use encrypted email, you may also report new
issues at:


   ISC patches only currently supported versions. When possible we
   indicate EOL versions affected. (For current information on which
   versions are actively supported, please see

ISC Security Vulnerability Disclosure Policy:

   Details of our current security advisory policy and practice can
   be found here:

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.
bind-announce mailing list

Reply via email to