|
BIND 9 has a lot of configuration options. Some have lost value over the years, but the policy was to keep the options to not break old configurations.
|
|
BIND 9 has a lot of configuration options. Some have lost value over the years, but the policy was to keep the options to not break old configurations.
|
|
|
|
|
|
:question: Does this policy apply only to named.conf options, or to, e.g. algorithms, builds, etc?
|
|
|
|
|
|
|
|
:exclamation: Short answer is yes, only to named.conf options. The longer answer is that for builds this is something that may affect the package maintainer more than the named operator and likely does not require a lengthy procedure. Deprecating option values (like algorithms) may affect users too, and should also be considered similar as deprecating the complete option.
|
|
|
|
|
|
|
|
However, we also want to clean up the code at some point. Keeping these options increases the number of corner cases and makes maintenance more cumbersome. It can also be confusing to new users. We are trying to establish an orderly, staged process that gives existing users ample time to react and adapt to obsoleted options.
|
|
However, we also want to clean up the code at some point. Keeping these options increases the number of corner cases and makes maintenance more cumbersome. It can also be confusing to new users. We are trying to establish an orderly, staged process that gives existing users ample time to react and adapt to obsoleted options.
|
|
|
|
|
|
This policy describes the procedure for removing named.conf options.
|
|
This policy describes the procedure for removing named.conf options.
|
... | @@ -12,15 +8,19 @@ This policy describes the procedure for removing named.conf options. |
... | @@ -12,15 +8,19 @@ This policy describes the procedure for removing named.conf options. |
|
|
|
|
|
We certainly don't want to remove any options that are still in widespread use. Before making the decision to go ahead with removing an option, we plan to post a notice on the bind-users mailing list to solicit feedback. Depending on the level of concern from the list, we may move ahead or decide to defer deprecating the option.
|
|
We certainly don't want to remove any options that are still in widespread use. Before making the decision to go ahead with removing an option, we plan to post a notice on the bind-users mailing list to solicit feedback. Depending on the level of concern from the list, we may move ahead or decide to defer deprecating the option.
|
|
|
|
|
|
|
|
This policy applies only to `named.conf` options, including their values (for example in case of enumeration or range changes).
|
|
|
|
|
|
## 1. Deprecating
|
|
## 1. Deprecating
|
|
|
|
|
|
A configuration option that is candidate for removal will be deprecated first. During this phase the option will still work, but we will be communicating to users that the option is going to be removed soon. A user that has deprecated options configured will see **warnings in their logs** and needs to take action to get rid of those log messages. The **named-checkconf** utility will also report that there are options included that are deprecated. (Request- for a 'configuration file beautifier' mode that would strip out the options that are deprecated and deliver a usable named-conf. This would be useful only if it could also preserve the comments in the file, which currently are stripped by -checkconf.) Configuration options that are deprecated will be identified in the **Release Note** for the release they are deprecated in. A list of deprecated options will also be included as an appendix in the **ARM** and in the **Knowledgebase article** describing [Significant features by Release](https://kb.isc.org/docs/aa-01310).
|
|
A configuration option that is candidate for removal will be deprecated first. During this phase the option will still work, but we will be communicating to users that the option is going to be removed soon. A user that has deprecated options configured will see **warnings in their logs** and needs to take action to get rid of those log messages. The **named-checkconf** utility will also report that there are options included that are deprecated.
|
|
|
|
|
|
|
|
Configuration options that are deprecated will be identified in the **Release Note** for the release they are deprecated in. A list of deprecated options will also be included as an appendix in the **ARM** and in the **Knowledgebase article** describing [Significant features by Release](https://kb.isc.org/docs/aa-01310).
|
|
|
|
|
|
Deprecating an option can be done at any time, but preferably before the next ESV release. For example, an option that you want to deprecate before the ESV 9.16 will need to go in the 9.15 development or the 9.14 stable release.
|
|
Deprecating an option can be done at any time, but preferably before the next ESV release. For example, an option that you want to deprecate before the ESV 9.16 will need to go in the 9.15 development or the 9.14 stable release.
|
|
|
|
|
|
## 2. Removing
|
|
## 2. Removing
|
|
|
|
|
|
A user that has a removed option configured will be unable to start `named` because the configuration option is no longer known. (Request - If there are multiple statements in the configuration that are removed, please run the whole configuration through the parser and spit out the whole list of issues, rather than requiring multiple fixes and retries.) Configuration options that are removed from BIND 9 will be noted in the Release Note for the first version they are removed from.
|
|
A user that has a removed option configured will be unable to start `named` because the configuration option is no longer supported. Configuration options that are removed from BIND 9 will be noted in the Release Note for the first version they are removed from.
|
|
|
|
|
|
We plan to remove options first in an annual stable release, so that we will learn what the impact is of removing a certain option before the change hits the more popular ESV release. An option that is deprecated in an ESV release should be removed from the code base in a successor stable release. For example, an option that has been marked as deprecated before 9.16 should be removed in the 9.17 development release (that will become the stable ESV release, 9.18). If it is not removed in the stable release it should also not be removed in the following ESV release. Following the example, it thus should stay in 9.19/9.20.
|
|
We plan to remove options first in an annual stable release, so that we will learn what the impact is of removing a certain option before the change hits the more popular ESV release. An option that is deprecated in an ESV release should be removed from the code base in a successor stable release. For example, an option that has been marked as deprecated before 9.16 should be removed in the 9.17 development release (that will become the stable ESV release, 9.18). If it is not removed in the stable release it should also not be removed in the following ESV release. Following the example, it thus should stay in 9.19/9.20.
|
|
|
|
|
... | | ... | |