Regarding allow-update: - We do try to avoid ‘breaking existing deployments’ with this sort of change. We do also have to balance maintaining existing deployments with making improvements in security and usability.
- When we ‘clarified’ behavior of BIND in 9.13.5 preventing the use of allow-update as an inherited option, apparently it was not entirely clear from code examination what the current behavior was. Therefore, we made a more invasive change than we would normally make on purpose, without a fair amount of public notice, and possibly even some sort of open poll. - We had no idea how common a configuration leveraging the inherited allow-update might be among users that we have no direct support relationship with. We have heard from several of you that this is an important feature for you: I think we were surprised at this. Thank you for the feedback. This is the purpose of having development releases, so that early adopters can try upcoming changes and give us feedback. - We have decided to treat this change as a regression bug, and to fix it in 9.14.1. Alan argued that we should hold 9.14.0 and fix it there: however we have decided to go ahead with 9.14.0 with the change we already made in allow-update, which we will highlight in the release notes as a ‘known issue'. People who rely on a global-allow-update will simply have to wait for 9.14.1 where we will attempt to restore the prior behavior. This is not a ’neat’ resolution, as it violates our normal policy of not changing configuration defaults in the middle of a stable branch, but it should be an adequate solution. - Reasonable people (some of my colleagues at ISC) feel that users may ’self-foot-shoot’ with an inherited allow-update, and that the inherited behavior may not be obvious (similar options such as update-policy are not inherited). At ISC we hear not infrequently from people who have inherited a BIND implementation after the original administrator left, and they are maintaining a configuration they don’t understand. This experience, coupled with a generally increasing concern about DNS security makes a reasonable argument for limiting opportunities to ‘accidentally’ allow updates when adding new zones. We may still implement this or a similar change in the future, but only after more discussion and communication and advance warning. We have noted the suggestions for some sort of zone templating, and for a log of the full zone configuration, reflecting inherited options as well as explicitly configured options. Regards, Vicky Risk Product Manager for BIND
_______________________________________________ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
