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 _______________________________________________ bind-announce mailing list bind-announce@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-announce
