|
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?
|
|
: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.
|
|
: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.
|
... | | ... | |