On 3/18/19 1:32 PM, Victoria Risk wrote:
- 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.
From my naive point of view, this seems perfectly reasonable. I hoist my drink to the global community and the ISC community for the the efforts and discussions that have ensued over this.
- 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.
As I was reading this, I found myself wondering if there is (I'll go look in a few minutes) an ability to have BIND dump the config it has read in. Or conversely dump what it thinks the effective config is. The difference being an (inadvertent) global option { allow-update {…}; }; could be omitted from the global options {…}; section but included in each zone {…}; section.
Perhaps something like this would help people identify what the effective config is. I think it would help people produce config files that match (or approach) the output of such a utility.
I would be tempted to have said utility omit comments, at least by default. After all, that's not the config in memory. Perhaps an option to pass comments from config file(s) through unmodified and possibly out of context would be of value.
-- Grant. . . . unix || die
smime.p7s
Description: S/MIME Cryptographic Signature
_______________________________________________ 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
