New BIND beta releases are available

Michael McNally mcnally at isc.org
Wed Feb 7 21:16:32 UTC 2018


Today ISC has published three new development releases of BIND,
betas for the upcoming maintenance releases in the 9.9, 9.10, and 9.11
branches.  They can be downloaded from https://www.isc.org/downloads

 9.9.12b1 release notes
 https://kb.isc.org/article/AA-01560/81/BIND-9.9.12b1-Release-Notes.html

 9.10.7b1 release notes
 https://kb.isc.org/article/AA-01559/81/BIND-9.10.7b1-Release-Notes.html

 9.11.3b1 release notes
 https://kb.isc.org/article/AA-01558/81/BIND-9.11.3b1-Release-Notes.html

We would like to draw your attention to one of the changes included in
these maintenance releases.  When these maintenance versions go to final
release in a few weeks we will issue an official Operational Notification
but for those testing them in the meantime -- you may need to know about
a behavior change in a Dynamic DNS feature.

> Previously, 'update-policy local;' accepted updates from any source so
> long as they were signed by the locally-generated session key. This
> has been further restricted; updates are now only accepted from
> locally configured addresses. [RT #45492]

As the name suggests, "update-policy local;" was originally intended
to cover DDNS updates from the locally configured server addresses.
However, due to an oversight on our part this intention was not actually
enforced.  In the ordinary course of operations you still needed the
locally-generated session key in order to submit an update under this
policy but this was effectively the only restriction.

However in 2017 ISC learned of (and subsequently disclosed) CVE-2017-3143
("An error in TSIG authentication can permit unauthorized dynamic updates")
which was very dangerous when combined with the failure of "update-policy
local;" to enforce a restriction barring updates under the policy when
received from remote addresses.  We advised about that risk of
"update-policy
local;" at the time of CVE-2017-3143 but are now also taking the additional
step of changing the behavior of this policy to reduce future risk.

Usually we prefer not to change the behavior of a feature in mid-branch
in order not to cause disruption for operators who may be relying on a
particular behavior.  In this case we have decided that (1) we believe
very few operators will be relying on this unexpected behavior of the
local update policy, and (2) the improvement in security to those using
the feature normally is significant enough to warrant the change.

If you are among the very small number of operators who may be
relying on this previous behavior of 'update-policy local;" please
be aware that beginning with these maintenance releases you will need
to use any of the alternate methods BIND provides for declaring and
permitting a key for authenticating DDNS updates.

Thanks in advance for the feedback you provide on our development
releases,

Michael McNally
ISC Support


More information about the bind-announce mailing list