Revert to bind-9.16.11 due to regressions

[Douglas R. Reno]

This morning, I received a message from oss-security titled '[oss-security] BIND Operational Notification: Enabling the new BIND option "stale-answer-client-timeout" can result in unexpected server termination'.

Since we have 9.16.12, we need to apply a patch. First, the contents of the email:

To the packagers and redistributors of BIND --

Regrettably, a problem has been discovered in two of the three public
release versions of BIND we issued yesterday (17 February).  A change
to the serve-stale feature in BIND 9.16.12 and BIND 9.17.10 can cause
the server to exit unexpectedly when that feature is in use.

Below is a message we shared with subscribers to our bind-announce
public list, and I reproduce it here in case any of you did not see
it there.

To most users we are recommending the use of one of the workarounds
listed in the Workarounds section of the accompanying Operational
Notification document.  As packagers and redistributors of BIND,
however, you are generally not in a position to choose your users'
config options.

We have a couple of recommendations:

1)  BIND 9.17.10 is an experiment development release and probably
not widely used for building packages.  But if you are packaging
and/or redistributing BIND 9.16.x and have not yet issued updated
packages based on 9.16.12 you might wish to hold off..  HOWEVER,
you will have also seen that yesterday we disclosed a vulnerability
in that version (CVE-2020-8625.)  You might prefer to issue a
package based on 9.16.11, since the serve-stale bug is not yet
present in that version, but with the patch diff found in
https://downloads.isc.org/isc/bind9/9.16.12/patches/CVE-2020-8625.patch
applied to correct the CVE-2020-8625 vulnerability.

2)  If you already have packages based on 9.16.12, we expect to have
a patch ready well before the next maintenance release.  A candidate
patch is under review now and can be delivered after review and
quality assurance testing.  If you wish to receive updates on the
progress of this patch, please e-mail your request to security-officer@isc.org

We're sorry for the mess this creates.

Michael McNally
(for ISC Security Officer) 

The patch itself can be found here: ​https://gitlab.isc.org/isc-projects/bind9/-/merge_requests/4714/diffs?commit_id=26d950a3bd44e8a904186d323e41cddbb75918e2

[Douglas R. Reno]

To the packagers and redistributors of BIND --

To our great embarrassment and sincere regret, another serious problem
has been found affecting servers upgrading to BIND 9.16.12.

If you have not already distributed packages based on 9.16.12 but
planned to do so, we recommend that you change your plans and instead
issue an updated package based on 9.16.11 plus the CVE-2020-8625 patch
found at
https://downloads.isc.org/isc/bind9/9.16.12/patches/CVE-2020-8625.patch.

If you already HAVE distributed packages based on BIND 9.16.12 -- we are
really sorry, and here is what you will need to know.

Cathy Almond
(for ISC Security Officer)

-----

Operational Notification: Zone journal (.jnl) file incompatibility
after upgrading to BIND 9.16.12 and 9.17

Posting date:        19 February 2021
Program impacted:    BIND
Versions affected:   BIND 9.16.12, BIND 9.16.12-S1 (Supported Preview
                     Edition) and versions 9.17.0 -> 9.17.10 of the 9.17
                     development branch.

Description:

   All changes made to a zone using dynamic updates or inbound
   incremental zone update (IXFR) are stored in the zone's journal file.
   This journal (.jnl) file is automatically created and maintained by
   named, and will be used when named is re-started after a shutdown or
   crash to roll-forward (replay) any zone updates that were not yet in
   the version of the zone on disk when named stopped. A zone's journal
   file is also used to provide incremental updates (IXFRs) to other
   servers. DNSSEC-signed zones using inline-signing will also have
   journal files associated with the signed version of the zone.

   In BIND 9.17.0, we introduced the max-ixfr-ratio option, which is a
   percentage representing the ratio of IXFR size to the size of the
   entire zone. This sets the size threshold (expressed as a percentage
   of the size of the full zone) beyond which named chooses to use an
   AXFR response rather than IXFR when answering zone transfer requests.
   This feature has now been back-ported to BIND 9.16, making its debut
   in the 9.16.12 releases.

   Unfortunately, one feature of this change escaped our notice, both
   when writing the release documentation for BIND 9.17.0, and then
   later on, adding the max-ixfr-ratio option to BIND 9.16.12. A small
   change was required to the format of the journal (.jnl) file format
   in order to support the calculation of an IXFR size during its
   preparation. The old format .jnl file is incompatible with the
   versions of BIND that support the new max-ixfr-ratio option.

   When BIND is upgraded to 9.16.12, 9.16.12-S1 or 9.17 (any version)
   and then started with journal (.jnl) files present that were created
   by earlier versions, then the zone load will fail because the journal
   roll-forward step will not recognise the older format.

Impact:

   This problem can affect BIND servers whose authoritative zones are
   maintained via dynamic updates, or by editing the zone file and
   reloading on a server with option 'ixfr-from-differences' enabled.
   Secondary zones that are maintained using incremental updates (IXFR)
   are similarly at risk. The 'ixfr-from-differences' option may also be
   used in some environments to generate journal files following an
   inbound AXFR.

Workarounds:

   We do not have a tool available to convert the journal files to the
   new format, therefore on upgrading, it is necessary to start named
   with the old format journal files removed.

   (Options if you have not yet upgraded:)

   1.  Before upgrading, ensure that named is stopped using rndc stop.
   This will ensure that all zones are written to disk during the
   shutdown processing. After named has stopped, delete or relocate all
   the associated .jnl files so that they are not accessed when named is
   restarted. named will generate new .jnl files as needed.

   Warning: Do not stop named using rndc halt before upgrading
   --
     Using rndc halt instead of rndc stop will stop the server
     immediately.  Recent changes made through dynamic update or
     IXFR are not saved to the zone files on disk first (and will
     need to be rolled-forward from the journal files when named is
     restarted; this is what you need to prevent so that you can
     delete them before upgrading).
   --

   2.  For a provisioning/primary authoritative server, you have another
   option for ensuring that the zones are written to disk and that the
   journal files are removed. First, ensure that all dynamic updates are
   paused, then issue command:

      rndc sync -clean

   Then stop named as normal (you should not need to remove the .jnl
   files manually as the 'rndc sync -clean' will have taken care of this
   step).

   (Options if you have already upgraded:)

   3.  If named was stopped before you upgraded using rndc stop and you
   know that this completed successfully, then removing or relocating
   the .jnl files will be all that you need to do.

   4.  If you are not sure if your zone files on disk were updated when
   you stopped named and you have a large number of zones to recover,
   then it may be easiest to back-out the update, start named to do the
   roll-forward and load, and then shutdown again (rndc stop) before
   following option 1. above.

   5.  If you have only a small number of zones to recover, then you may
   prefer to recover (or build) named-checkzone from your pre-upgrade
   version of BIND and use that to regenerate the zone files from
   the .jnl files.

   For example, to create a new zone file 'example.com.new' for zone
   'example.com' by rolling forward from 'example.com.jnl' and
   'example.com', you would type:

      named-checkzone -jD -o example.com.new example.com example.com

   And then you would:

   - remove files 'example.com.jnl' and 'example.com'
   - rename 'example.com.new' to 'example.com'.

   Note: Use -f and -F options if your zone files are not in text
   format. BIND supports several formats of zone file - check which
   format you need first.

   Hint: Make backup copies of the zone and .jnl files before you run
   named-compilezone.  The named-checkzone utility, when run with the
   -jD  options, will apply the journal file changes to the zone and
   then delete it afterwards. If you make a mistake with the options,
   you may want to start again; having a backup copy in that situation
   is essential!

Solution:

   Code changes to support roll-forward from the older format of .jnl
   files are planned for the March 2021 maintenance releases (due
   17 March 2021) but until then the measures suggested in the
   "Workarounds" section should prevent or resolve post-upgrade zone
   loading problems for Authoritative BIND server operators.

Do you still have questions?
Questions regarding this notification 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/pgpkey/. If you are unable to use encrypted email,
you may also report new issues at: https://www.isc.org/reportbug/.

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/download/.)

ISC Security Vulnerability Disclosure Policy:

   Details of our current security advisory policy and practice can be
   found in the ISC Software Defect and Security Vulnerability
   Disclosure Policy at https://kb.isc.org/docs/aa-00861.

This Knowledgebase article, found at
https://kb.isc.org/v1/docs/operational-notification-zone-journal-jnl-file-incompatibility-after-upgrading-to-bind-91612-and-917
is the complete and official
operational notification 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.

I would like to discuss reverting to BIND 9.16.11 with the proper security patches applied.

[Douglas R. Reno]

After talking to Bruce, we're going to revert to 9.16.11.

[Douglas R. Reno]

This is the sed that I devised since it's a one-line patch:

sed -i '851 s/len/(len + 1)/' lib/dns/spnego.c

Working on this now, will get it in before I call it a night.

[Douglas R. Reno]

Fixed at r24263