Re: A policy for removing named.conf options.
On 13-Jun-19 06:46, Matthijs Mekking wrote: > Dear BIND 9 users, > > 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. > > 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 deprecated options. > > The policy below describes our proposal for the procedure for removing > named.conf options. We would like to hear your feedback. > > Thanks, best regards, > > Matthijs > [Snip] Slowly catching-up from being off-line, I've reviewed the discussion on this. A couple of observations: So far, the suggestions have included logging & making sure that named-checkconf flags deprecated syntax. While helpful, these all suffer from a timing problem: notice is only provided after the new software is installed. For advance notification, they require someone to look at "the" log file (or proactively run named-checkconf). But if it isn't going to bite now, there's a good chance that won't happen. And if it does bite now, the software has been installed - best case in a test environment, worst case in production. [The last may be more likely with packaged distributions than with build-from source sites.] Further, "the" log file varies by startup mechanism (sysVinit, systemd, named's logs, consoles, ...) - and in embedded cases, logs may be remote and/or hard to access. One approach to notification that hasn't been mentioned would be to include a deprecation notice and scan of the default configuration file in 'make install'. This should be a separate script called from install, that can also be used stand-alone. This has limitations, but covers some interesting cases: Advantages: Proactive: can stop install if obsolete directives/syntax is detected - before starting the test (or for the adventurous, production) environment. Does not depend on logging, or on anyone reading the logs. Does not depend on which startup mechanism is in use. Should be caught by the packagers' build. They are generally responsible enough to pass on the deprecations to their users. The packagers can run the check script in their package's 'install' mechanism. Works for most people who build from source. Limitations: Does not work for installations who use a non-default configuration file. (e.g. named -c ...) May be messy for chroot and enhanced security (selinux,apparmor,...) environments Will not inspect dynamic configurations (e.g. rndc addzone, modzone...) Notes: In all cases, make install could include a short notice of the form "See DEPRECATIONS for changes that may require changes in your configuration files". The README can also refer to this file to avoid duplication. Why install? Eventually, even packaged distributions use install - it may be buried in an RPM's spec file, but it's run somewhere. Install allows the newly built(or distributed) version to check before the new version is activated. "configure" is too soon - you don't have the new images, and with packaged (and cross-compiled) distributions, it's never run on the target. Probably, running the check should be the default (maximum coverage), but a make install-nocheck target would probably be necessary. Another mechanism would be to add a --fix option to named-checkconf. This would generate a new file(s), commenting out options that no longer serve a purpose - with an easily detectable marker (e.g. '# OBSOLETE - named-checkconf V19.2'). For options that are simply renamed, it can insert the new, equivalent syntax. For options that can't be automatically updated, create a marker "# ATTENTION: named-checkconf V19.2 - The 'use-Klingon-names' option is not supported, see DEPRECATIONS section 659.712 for details" - and don't comment out the option! A log file listing all files modified should be produced. --fix would shift the burden of finding the affected options from the user to software - making it (a) more likely to happen (b) easier - especially for configurations that span dozens (or hundreds) of 'include'd files. I don't think there's a single universal solution to handling deprecations, but I hope that these observations are helpful. Timothe Litt ACM Distinguished Engineer -- This communication may not represent the ACM or my employer's views, if any, on the matters discussed. signature.asc Description: OpenPGP digital 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
Re: A policy for removing named.conf options.
On 13 Jun 2019, at 13:37, Lightner, Jeffrey wrote: I'd suggest also giving warnings for deprecated options when running named-checkconf (and named-checkzone if applicable). You mention the logs but not the commands. Jeffrey C. Lightner Sr. UNIX/Linux Administrator With named-checkconf and named-checkzone warning about future deprecation ahead of time, startup scripts could perhaps implement checks. Perhaps an exit code could signify the issue, and or have the messages follow a standard format for easy testing of output. Allowing SMF / systemd to then show the service as degraded. ESV release could have the tools updated in micro release to provide early warnings; for those that update to the later releases at least. Mr. Stacey Marshall - Principal Software Engineer - Oracle UK Oracle Systems, SPARC & Solaris System Software Engineering. ___ 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
Re: A policy for removing named.conf options.
On 13 Jun2019, at 17:48, Browne, Stuart via bind-users wrote: > For options that have passed their warning phase and have been removed, I'm > all for BIND failing to start and named-checkconf erroring out , rather than > quietly ignoring them. Yes, I think this is the best way, otherwise there will be useless kruft getting in the way forever. -- The only way of discovering the limits of the possible is to venture a little way past them into the impossible. ___ 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
RE: A policy for removing named.conf options.
> -Original Message- > From: bind-users [mailto:bind-users-boun...@lists.isc.org] On Behalf Of > Evan Hunt > Sent: Friday, 14 June 2019 5:40 AM > To: Warren Kumari > Cc: Ondřej Surý; comp-protocols-dns-b...@isc.org > Subject: Re: A policy for removing named.conf options. > > On Thu, Jun 13, 2019 at 02:52:34PM -0400, Warren Kumari wrote: > > all sorts of annoyance -- if I'm running low on space for cache, and > > spend much time twiddling the "max-acache-size" knob before > > discovering that someone has simply snipped the wires to it, I'd be > > super-grumpy. > > But hopefully in this scenario you're paying attention to log messages, > and would have seen the "obsolete option" warning. > > The question is, should your nameserver complain and keep running, or > should it reufse to run? And for "max-acache-size", enh, I'd probably > be okay with it. > > But a standard policy that covers all deprecated options would need > to be stricter than "enh". For options that have passed their warning phase and have been removed, I'm all for BIND failing to start and named-checkconf erroring out , rather than quietly ignoring them. Usless cruft is useless. You're going to the trouble of doing a major-version-upgrade, take the time to tune the config to suit it. If you're using automation tools, hopefully you've run it through at least one test system before hitting production, yes? Stuart ___ 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
Re: A policy for removing named.conf options.
On Thu, Jun 13, 2019 at 02:52:34PM -0400, Warren Kumari wrote: > all sorts of annoyance -- if I'm running low on space for cache, and > spend much time twiddling the "max-acache-size" knob before > discovering that someone has simply snipped the wires to it, I'd be > super-grumpy. But hopefully in this scenario you're paying attention to log messages, and would have seen the "obsolete option" warning. The question is, should your nameserver complain and keep running, or should it reufse to run? And for "max-acache-size", enh, I'd probably be okay with it. But a standard policy that covers all deprecated options would need to be stricter than "enh". -- Evan Hunt -- e...@isc.org Internet Systems Consortium, Inc. ___ 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
Re: A policy for removing named.conf options.
One of the Tesla easter-eggs is that the radio volumes goes to 11... :-P W On Thu, Jun 13, 2019 at 3:27 PM Lightner, Jeffrey wrote: > > But if the knob goes to 11 you'll know it is superior to those that only go > to 10. :-) > > > -Original Message- > From: bind-users On Behalf Of Warren Kumari > Sent: Thursday, June 13, 2019 2:53 PM > To: Evan Hunt > Cc: Ondřej Surý ; comp-protocols-dns-b...@isc.org > Subject: Re: A policy for removing named.conf options. > > On Thu, Jun 13, 2019 at 2:43 PM Evan Hunt wrote: > > > > > > Is it really much of a hassle to leave the obsolete options in the > > > > parser, but just ignore them? > > > > IMHO, it depends on the option. For something like "managed-keys" and > > "trusted-keys", there are clear security implications. Once those are > > no longer effective, it would be dangerous to have named ignore them - > > even with a logged warning. Operators who didn't notice the log > > message wouldn't realize they were running without the security they'd > > configured. > > > > For something like "cleaning-interval" or "max-acache-size", IMHO it > > would be safe to let it slide. With "dnssec-enable" or > > "queryport-pool-ports", maybe those fall somewhere in between, I could see > > arguments either way. > > I personally think that while it may or may not be a hassle to have the > parser ignore them, it would be a significant operational risk / annoyance. > Having knobs which you can twiddle which don't do anything leads to all sorts > of annoyance -- if I'm running low on space for cache, and spend much time > twiddling the "max-acache-size" knob before discovering that someone has > simply snipped the wires to it, I'd be super-grumpy. > > I'm expecting some issues when knobs get deprecated (and I'm likely to run > into a few lurking in old configs which have grown over time), but I'd rather > have named not start just after I've upgraded it than be running in some > partially undefined state. > > W > > > > > In any case, if we're going to make a policy that covers the whole > > range of possibilities, then it needs to address the case when an > > option must removed, and how to ensure operators aren't blindsided by that. > > > > -- > > Evan Hunt -- e...@isc.org > > Internet Systems Consortium, Inc. > > ___ > > 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 > > > > -- > I don't think the execution is relevant when it was obviously a bad idea in > the first place. > This is like putting rabid weasels in your pants, and later expressing regret > at having chosen those particular rabid weasels and that pair of pants. >---maf > ___ > 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 -- I don't think the execution is relevant when it was obviously a bad idea in the first place. This is like putting rabid weasels in your pants, and later expressing regret at having chosen those particular rabid weasels and that pair of pants. ---maf ___ 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
RE: A policy for removing named.conf options.
But if the knob goes to 11 you'll know it is superior to those that only go to 10. :-) -Original Message- From: bind-users On Behalf Of Warren Kumari Sent: Thursday, June 13, 2019 2:53 PM To: Evan Hunt Cc: Ondřej Surý ; comp-protocols-dns-b...@isc.org Subject: Re: A policy for removing named.conf options. On Thu, Jun 13, 2019 at 2:43 PM Evan Hunt wrote: > > > > Is it really much of a hassle to leave the obsolete options in the > > > parser, but just ignore them? > > IMHO, it depends on the option. For something like "managed-keys" and > "trusted-keys", there are clear security implications. Once those are > no longer effective, it would be dangerous to have named ignore them - > even with a logged warning. Operators who didn't notice the log > message wouldn't realize they were running without the security they'd > configured. > > For something like "cleaning-interval" or "max-acache-size", IMHO it > would be safe to let it slide. With "dnssec-enable" or > "queryport-pool-ports", maybe those fall somewhere in between, I could see > arguments either way. I personally think that while it may or may not be a hassle to have the parser ignore them, it would be a significant operational risk / annoyance. Having knobs which you can twiddle which don't do anything leads to all sorts of annoyance -- if I'm running low on space for cache, and spend much time twiddling the "max-acache-size" knob before discovering that someone has simply snipped the wires to it, I'd be super-grumpy. I'm expecting some issues when knobs get deprecated (and I'm likely to run into a few lurking in old configs which have grown over time), but I'd rather have named not start just after I've upgraded it than be running in some partially undefined state. W > > In any case, if we're going to make a policy that covers the whole > range of possibilities, then it needs to address the case when an > option must removed, and how to ensure operators aren't blindsided by that. > > -- > Evan Hunt -- e...@isc.org > Internet Systems Consortium, Inc. > ___ > 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 -- I don't think the execution is relevant when it was obviously a bad idea in the first place. This is like putting rabid weasels in your pants, and later expressing regret at having chosen those particular rabid weasels and that pair of pants. ---maf ___ 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 ___ 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
Re: A policy for removing named.conf options.
On Thu, Jun 13, 2019 at 2:43 PM Evan Hunt wrote: > > > > Is it really much of a hassle to leave the obsolete options in the > > > parser, but just ignore them? > > IMHO, it depends on the option. For something like "managed-keys" and > "trusted-keys", there are clear security implications. Once those are no > longer effective, it would be dangerous to have named ignore them - even > with a logged warning. Operators who didn't notice the log message wouldn't > realize they were running without the security they'd configured. > > For something like "cleaning-interval" or "max-acache-size", IMHO it would > be safe to let it slide. With "dnssec-enable" or "queryport-pool-ports", > maybe those fall somewhere in between, I could see arguments either way. I personally think that while it may or may not be a hassle to have the parser ignore them, it would be a significant operational risk / annoyance. Having knobs which you can twiddle which don't do anything leads to all sorts of annoyance -- if I'm running low on space for cache, and spend much time twiddling the "max-acache-size" knob before discovering that someone has simply snipped the wires to it, I'd be super-grumpy. I'm expecting some issues when knobs get deprecated (and I'm likely to run into a few lurking in old configs which have grown over time), but I'd rather have named not start just after I've upgraded it than be running in some partially undefined state. W > > In any case, if we're going to make a policy that covers the whole range of > possibilities, then it needs to address the case when an option must > removed, and how to ensure operators aren't blindsided by that. > > -- > Evan Hunt -- e...@isc.org > Internet Systems Consortium, Inc. > ___ > 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 -- I don't think the execution is relevant when it was obviously a bad idea in the first place. This is like putting rabid weasels in your pants, and later expressing regret at having chosen those particular rabid weasels and that pair of pants. ---maf ___ 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
Re: A policy for removing named.conf options.
> > Is it really much of a hassle to leave the obsolete options in the > > parser, but just ignore them? IMHO, it depends on the option. For something like "managed-keys" and "trusted-keys", there are clear security implications. Once those are no longer effective, it would be dangerous to have named ignore them - even with a logged warning. Operators who didn't notice the log message wouldn't realize they were running without the security they'd configured. For something like "cleaning-interval" or "max-acache-size", IMHO it would be safe to let it slide. With "dnssec-enable" or "queryport-pool-ports", maybe those fall somewhere in between, I could see arguments either way. In any case, if we're going to make a policy that covers the whole range of possibilities, then it needs to address the case when an option must removed, and how to ensure operators aren't blindsided by that. -- Evan Hunt -- e...@isc.org Internet Systems Consortium, Inc. ___ 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
Re: A policy for removing named.conf options.
> On 13 Jun 2019, at 18:10, John Thurston wrote: > > On 6/13/2019 4:37 AM, Lightner, Jeffrey wrote: >> I'd suggest also giving warnings for deprecated options when running >> named-checkconf (and named-checkzone if applicable). You mention the logs >> but not the commands. >> Jeffrey C. Lightner >> Sr. UNIX/Linux Administrator > > I hope this is implemented in named-checkconf/zone. > > It would also be nice to include some sort of option on named-checkconf to > 'whitelist' or ignore the deprecation warnings, as I use named-checkconf two > different ways. "--no-deprecated”-like option is a nice idea, I like it. Thanks! -- Ondřej Surý ond...@isc.org ___ 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
Re: A policy for removing named.conf options.
> On 13 Jun 2019, at 17:55, Barry Margolin wrote: > > In article , > Matthijs Mekking wrote: > >> ## 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. >> Configuration options that are deprecated will be identified in the >> Release Note for the release they are deprecated in. > > As others have said, I'm not sure how effective this will be. I suspect > most people don't check the logs routinely, only when something goes > wrong. The policy isn’t intended to take care of people who don’t really care. The policy is here to have a transparent and careful way how to remove options. > Is it really much of a hassle to leave the obsolete options in the > parser, but just ignore them? Unfortunately, yes, it adds to overall entropy of the source code, and we aim to fix the cruft that has accumulated in last 20 years. This is more of high level design decision, but it is something that has to be done because it is connected with maintenance burden. And it’s a burden we don’t have to really carry on our shoulders. Ondrej -- Ondřej Surý ond...@isc.org ___ 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
Re: A policy for removing named.conf options.
On 6/13/2019 4:37 AM, Lightner, Jeffrey wrote: I'd suggest also giving warnings for deprecated options when running named-checkconf (and named-checkzone if applicable). You mention the logs but not the commands. Jeffrey C. Lightner Sr. UNIX/Linux Administrator I hope this is implemented in named-checkconf/zone. It would also be nice to include some sort of option on named-checkconf to 'whitelist' or ignore the deprecation warnings, as I use named-checkconf two different ways. When I'm setting up a server, or making a configuration change, I use it interactively. In this case, I would love to know if an option I'm trying to use is going away. I have automated deployment processes which call named-checkconf. In most of these cases, I only need to know that my .conf is valid even if it isn't optimal. I'll uncover the warnings with my next interactive work, but I don't want my automated processes to stop working because something will be going away at some point in the near future. -- Do things because you should, not just because you can. John Thurston907-465-8591 john.thurs...@alaska.gov Department of Administration State of Alaska ___ 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
Re: A policy for removing named.conf options.
In article , Matthijs Mekking wrote: > ## 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. > Configuration options that are deprecated will be identified in the > Release Note for the release they are deprecated in. As others have said, I'm not sure how effective this will be. I suspect most people don't check the logs routinely, only when something goes wrong. Is it really much of a hassle to leave the obsolete options in the parser, but just ignore them? -- Barry Margolin Arlington, MA ___ 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
Re: A policy for removing named.conf options.
Hi there, On Thu, 13 Jun 2019, Leroy Tennison wrote: On Thu, 13 Jun 2019, Ond?ej Sur? wrote: On 13 Jun 2019, at 15:55, G.W. Haywood via bind-users ... wrote: ... could you not set up an ISC zone which BIND on startup will ping ... we?ve been discussing the ?call home? feature on several occasions and usually something more pressing crawls at top of the TODO list... Unconditional "call home" is always problematic ... Sure. ... administrative hassle ... management approval ... Hence the "ask for permission at build time, etc.". Just Say No. We would be happy to collect more feedback and don?t get me started on how I just love to receive patches, preferably as merge requests (ping me if you need up the projects limit in our GitLab) ;). Unfortunately I also have one of those TODO lists, and I'm afraid it has no room for patching BIND although I'd relish the opportunity. I did have a quick look and it doesn't look too daunting. -- 73, Ged. ___ 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
Re: A policy for removing named.conf options.
Unconditional "call home" is always problematic but discretionary "call home" (per the URL) is much better. However, be aware that some environments (such as Payment Card Industry standards) require that all outbound traffic have a business justification. This could be justified, it's just going to be an administrative hassle to document the need and go through a management approval process. From: bind-users on behalf of Ondřej Surý Sent: Thursday, June 13, 2019 9:22:53 AM To: G.W. Haywood Cc: bind-users@lists.isc.org Subject: [EXTERNAL] Re: A policy for removing named.conf options. Hey, we’ve been discussing the “call home” feature on several occasions and usually something more pressing crawls at top of the TODO list, but here’s the issue we have as a starter: https://linkprotect.cudasvc.com/url?a=https%3a%2f%2fgitlab.isc.org%2fisc-projects%2fbind9%2fissues%2f421=E,1,5RfyTpYfPh7xliqVD4MiTRmekNfpBmTXzQmVptTqjqm1ew4vcDjQwzkKiVAlJhtyT_HqrdNmh4vqy-Umg9NGAUvDh_3a7EB7SlLtOH6OKbxmhCUZxrp9n8zD=1 We would be happy to collect more feedback and don’t get me started on how I just love to receive patches, preferably as merge requests (ping me if you need up the projects limit in our GitLab) ;). Ondrej -- Ondřej Surý ond...@isc.org Harriscomputer Leroy Tennison Network Information/Cyber Security Specialist E: le...@datavoiceint.com [cid:Data-Voice-International-LOGO_aa3d1c6e-5cfb-451f-ba2c-af8059e69609.PNG] 2220 Bush Dr McKinney, Texas 75070 www.datavoiceint.com<http://www..com> This message has been sent on behalf of a company that is part of the Harris Operating Group of Constellation Software Inc. These companies are listed here<http://subscribe.harriscomputer.com/>. If you prefer not to be contacted by Harris Operating Group please notify us<http://subscribe.harriscomputer.com/>. This message is intended exclusively for the individual or entity to which it is addressed. This communication may contain information that is proprietary, privileged or confidential or otherwise legally exempt from disclosure. If you are not the named addressee, you are not authorized to read, print, retain, copy or disseminate this message or any part of it. If you have received this message in error, please notify the sender immediately by e-mail and delete all copies of the message. t; On 13 Jun 2019, at 15:55, G.W. Haywood via bind-users wrote: > > Hello again, > > On Thu, 13 Jun 2019, Matthijs Mekking wrote: >> On 6/13/19 2:40 PM, G.W. Haywood via bind-users wrote: >> > On Thu, 13 Jun 2019, Matthijs Mekking? wrote: >> > >> > > | managed-keys?? | 9.15/9.16 | replaced with dnssec-keys | >> > >> > According to my changelogs for 'named.conf I removed 'managed-keys' and >> > 'trusted-keys' three years ago, but still use 'managed-keys-directory'. >> ... it is likely that you are using managed trust anchors that >> are configured with 'managed-keys' in a bind.keys file. ... > > Correct. It says in that file that I'm not expected to do anything to > it - so I expect you'll take care of that when the time comes, yes? > > To tell you about the use of configuration options, could you not set > up an ISC zone which BIND on startup will ping with a few packets? > You'd get a lot more (and more accurate) feedback than sending out a > plea on a mailing list. You could make it a compile time option, ask > for permission at build time, etc.. > > -- > > 73, > Ged. > ___ > Please visit > https://linkprotect.cudasvc.com/url?a=https%3a%2f%2flists.isc.org%2fmailman%2flistinfo%2fbind-users=E,1,CqxGXQ1aiGLDV9LxLwljfYJRolmwJV3RlfcYaNABVsMlBnR5RJRsa2BaKR3xs-G5eFTxIA841AhYXTegjj-ggT2H9TJqOoJb18sEG8eenJz3jV80sk-eIJ1K=1 > to unsubscribe from this list > > bind-users mailing list > bind-users@lists.isc.org > https://linkprotect.cudasvc.com/url?a=https%3a%2f%2flists.isc.org%2fmailman%2flistinfo%2fbind-users=E,1,lrTADuMZK7-3YQwQVI98M2QtIe3X6vetMWM-r7d7aOkIyI4r9ebviUn3Zt3DP7266hKmVaHsi7YHuqRMl2Qa34whLALYOPPIkAmRLthBNJxi5A,,=1 ___ Please visit https://linkprotect.cudasvc.com/url?a=https%3a%2f%2flists.isc.org%2fmailman%2flistinfo%2fbind-users=E,1,__bZRbafpXn77YybXrIT8vrp5HPPCi47lEsNtl-XZNPm4xWpJaPv9WPRyYhW3ZVQvnsQgeCu5aVZu0wCqwBWSSWRNUEyvXYAcg-qkT-ZxuxC4DuEJSd0BmCGog,,=1 to unsubscribe from this list bind-users mailing list bind-users@lists.isc.org https://linkprotect.cudasvc.com/url?a=https%3a%2f%2flists.isc.org%2fmailman%2flistinfo%2fbind-users=E,1,ISqAFF76QaPqnU4mChTvAsOO3ML7KgbBDfwn3SbpXS-IEHJzUjsTCizHF7IZrVYRstLhmfu0DKXlGExNXKlgM_d16WvubXeUUOJqNO6T6Q,,=1 ___ 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
RE: A policy for removing named.conf options.
Systemd writes logs for things it starts to the Journal which can be viewed
with journalctl command.
On some distros (e.g. RHEL7) it also continues to write many things to system
logs like /var/log/messages. Not all of what goes to the Journal is in
/var/log/messages but all of what is in /var/log/messages goes to the Journal.
From: bind-users On Behalf Of Leroy Tennison
Sent: Thursday, June 13, 2019 9:57 AM
To: bind-users@lists.isc.org
Subject: Re: A policy for removing named.conf options.
First of all, I appreciate the fact that you are seeking feedback before
acting, thank you.
I agree with Warren's point about logs and, unfortunately, also with his
analysis concerning distributions. A couple of additional comments.
The major Linux distributions are moving to systemd (whether we like it or
not), whatever is done has to take that into account.
The only thing you have (the most) control over is the software you produce,
another approach would be to add a generic message facility to all your
utilities that, for example, displays the contents of a file at startup (if it
exists). Daemon startup could check the configuration files and generate the
content of the displayed file ("You're using 'blah' option which is
depreciated, see http://...;). This way, if an administrator uses any of your
utilities, they see the message. For "extra credit", add a "don't display this
message again" option. If an administrator manages to support your software
without using any of your utilities then they are capable of remediating their
own problems.
Harriscomputer
Leroy Tennison
Network Information/Cyber Security Specialist
E: le...@datavoiceint.com<mailto:le...@datavoiceint.com>
[cid:image001.png@01D521D3.3503B870]
2220 Bush Dr
McKinney, Texas
75070
www.datavoiceint.com<http://www..com>
This message has been sent on behalf of a company that is part of the Harris
Operating Group of Constellation Software Inc. These companies are listed
here<http://subscribe.harriscomputer.com/>.
If you prefer not to be contacted by Harris Operating Group please notify
us<http://subscribe.harriscomputer.com/>.
This message is intended exclusively for the individual or entity to which it
is addressed. This communication may contain information that is proprietary,
privileged or confidential or otherwise legally exempt from disclosure. If you
are not the named addressee, you are not authorized to read, print, retain,
copy or disseminate this message or any part of it. If you have received this
message in error, please notify the sender immediately by e-mail and delete all
copies of the message.
From: bind-users
mailto:bind-users-boun...@lists.isc.org>> on
behalf of Ondřej Surý mailto:ond...@isc.org>>
Sent: Thursday, June 13, 2019 8:37 AM
To: Warren Kumari
Cc: bind-users@lists.isc.org<mailto:bind-users@lists.isc.org>
Subject: [EXTERNAL] Re: A policy for removing named.conf options.
Hi Warren and everybody,
first, let me thank for the fruitful discussion!
> On 13 Jun 2019, at 15:18, Warren Kumari
> mailto:war...@kumari.net>> wrote:
>
> Many many people don't look at their logs -- could named also print
> stuff to (stdout, stderr) when starting?
>
> Note that this will require some testing -- various distributions use
> various init scripts - in many cases things printed at startup don't
> actually make it to the console, and I'm suspecting some init systems
> will barf, but...
It's undermentioned in the policy proposal, but the named-checkconf
will be loud about the deprecated options. We can then bug distros to
integrate the named-checkconf run into the pre/postinst maintainer scripts.
(Hey myself, fix the Debian package. Ok, myself...)
> Another phased approach would be to require users to acknowledge that
> the feature is being deprecated -- initially it could warn, and then
> named could require command line flags to enable the (being)
> deprecated features, and then in the next release they would stop (e.g
> named --enable_deprecated_cleaning-interval). I think that this is way
> overkill, but just a thought.
That would take 4 full years to deprecate single option, as we need to take
people that upgrade from ESV to ESV into account, and we were aiming
at slightly "faster" approach :-).
Thanks,
--
Ondřej Surý
ond...@isc.org<mailto:ond...@isc.org>
___
Please visit
https://linkprotect.cudasvc.com/url?a=https%3a%2f%2flists.isc.org%2fmailman%2flistinfo%2fbind-users=E,1,yw6EFdI2bCuC2na2ur7-F1G92uow3vtsWpruIMf4wVLkS96WojpFuQ9yFBatKWXzbsJWnOpPiH9CsJum226CS7Pr4Oi5GsbAuvBcrpl8GbMNpGxrMrpl3M9XNfw,=1
to unsubscribe from this list
bind-users mailing list
bind-users@lists.isc.org
Re: A policy for removing named.conf options.
Hey, we’ve been discussing the “call home” feature on several occasions and usually something more pressing crawls at top of the TODO list, but here’s the issue we have as a starter: https://gitlab.isc.org/isc-projects/bind9/issues/421 We would be happy to collect more feedback and don’t get me started on how I just love to receive patches, preferably as merge requests (ping me if you need up the projects limit in our GitLab) ;). Ondrej -- Ondřej Surý ond...@isc.org > On 13 Jun 2019, at 15:55, G.W. Haywood via bind-users > wrote: > > Hello again, > > On Thu, 13 Jun 2019, Matthijs Mekking wrote: >> On 6/13/19 2:40 PM, G.W. Haywood via bind-users wrote: >> > On Thu, 13 Jun 2019, Matthijs Mekking? wrote: >> > >> > > | managed-keys?? | 9.15/9.16 | replaced with dnssec-keys | >> > >> > According to my changelogs for 'named.conf I removed 'managed-keys' and >> > 'trusted-keys' three years ago, but still use 'managed-keys-directory'. >> ... it is likely that you are using managed trust anchors that >> are configured with 'managed-keys' in a bind.keys file. ... > > Correct. It says in that file that I'm not expected to do anything to > it - so I expect you'll take care of that when the time comes, yes? > > To tell you about the use of configuration options, could you not set > up an ISC zone which BIND on startup will ping with a few packets? > You'd get a lot more (and more accurate) feedback than sending out a > plea on a mailing list. You could make it a compile time option, ask > for permission at build time, etc.. > > -- > > 73, > Ged. > ___ > 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 ___ 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
Re: A policy for removing named.conf options.
First of all, I appreciate the fact that you are seeking feedback before
acting, thank you.
I agree with Warren's point about logs and, unfortunately, also with his
analysis concerning distributions. A couple of additional comments.
The major Linux distributions are moving to systemd (whether we like it or
not), whatever is done has to take that into account.
The only thing you have (the most) control over is the software you produce,
another approach would be to add a generic message facility to all your
utilities that, for example, displays the contents of a file at startup (if it
exists). Daemon startup could check the configuration files and generate the
content of the displayed file ("You're using 'blah' option which is
depreciated, see http://...;). This way, if an administrator uses any of your
utilities, they see the message. For "extra credit", add a "don't display this
message again" option. If an administrator manages to support your software
without using any of your utilities then they are capable of remediating their
own problems.
Harriscomputer
Leroy Tennison
Network Information/Cyber Security Specialist
E: le...@datavoiceint.com
[cid:Data-Voice-International-LOGO_aa3d1c6e-5cfb-451f-ba2c-af8059e69609.PNG]
2220 Bush Dr
McKinney, Texas
75070
www.datavoiceint.com<http://www..com>
This message has been sent on behalf of a company that is part of the Harris
Operating Group of Constellation Software Inc. These companies are listed
here<http://subscribe.harriscomputer.com/>.
If you prefer not to be contacted by Harris Operating Group please notify
us<http://subscribe.harriscomputer.com/>.
This message is intended exclusively for the individual or entity to which it
is addressed. This communication may contain information that is proprietary,
privileged or confidential or otherwise legally exempt from disclosure. If you
are not the named addressee, you are not authorized to read, print, retain,
copy or disseminate this message or any part of it. If you have received this
message in error, please notify the sender immediately by e-mail and delete all
copies of the message.
From: bind-users on behalf of Ondřej Surý
Sent: Thursday, June 13, 2019 8:37 AM
To: Warren Kumari
Cc: bind-users@lists.isc.org
Subject: [EXTERNAL] Re: A policy for removing named.conf options.
Hi Warren and everybody,
first, let me thank for the fruitful discussion!
> On 13 Jun 2019, at 15:18, Warren Kumari wrote:
>
> Many many people don't look at their logs -- could named also print
> stuff to (stdout, stderr) when starting?
>
> Note that this will require some testing -- various distributions use
> various init scripts - in many cases things printed at startup don't
> actually make it to the console, and I'm suspecting some init systems
> will barf, but...
It's undermentioned in the policy proposal, but the named-checkconf
will be loud about the deprecated options. We can then bug distros to
integrate the named-checkconf run into the pre/postinst maintainer scripts.
(Hey myself, fix the Debian package. Ok, myself...)
> Another phased approach would be to require users to acknowledge that
> the feature is being deprecated -- initially it could warn, and then
> named could require command line flags to enable the (being)
> deprecated features, and then in the next release they would stop (e.g
> named --enable_deprecated_cleaning-interval). I think that this is way
> overkill, but just a thought.
That would take 4 full years to deprecate single option, as we need to take
people that upgrade from ESV to ESV into account, and we were aiming
at slightly "faster" approach :-).
Thanks,
--
Ondřej Surý
ond...@isc.org
___
Please visit
https://linkprotect.cudasvc.com/url?a=https%3a%2f%2flists.isc.org%2fmailman%2flistinfo%2fbind-users=E,1,yw6EFdI2bCuC2na2ur7-F1G92uow3vtsWpruIMf4wVLkS96WojpFuQ9yFBatKWXzbsJWnOpPiH9CsJum226CS7Pr4Oi5GsbAuvBcrpl8GbMNpGxrMrpl3M9XNfw,=1
to unsubscribe from this list
bind-users mailing list
bind-users@lists.isc.org
https://linkprotect.cudasvc.com/url?a=https%3a%2f%2flists.isc.org%2fmailman%2flistinfo%2fbind-users=E,1,YVga50vu8jtaQRjJyL3EYLTif7UroYK4D1uIX3KMLr4tHA0WEL7m4ytBOAe3Ry1gkCjeaIlSnMv7JrNAOoVnw5JLA1CytXg871RJx0Ey=1
___
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
Re: A policy for removing named.conf options.
Hello again, On Thu, 13 Jun 2019, Matthijs Mekking wrote: On 6/13/19 2:40 PM, G.W. Haywood via bind-users wrote: > On Thu, 13 Jun 2019, Matthijs Mekking? wrote: > > > | managed-keys?? | 9.15/9.16 | replaced with dnssec-keys | > > According to my changelogs for 'named.conf I removed 'managed-keys' and > 'trusted-keys' three years ago, but still use 'managed-keys-directory'. ... it is likely that you are using managed trust anchors that are configured with 'managed-keys' in a bind.keys file. ... Correct. It says in that file that I'm not expected to do anything to it - so I expect you'll take care of that when the time comes, yes? To tell you about the use of configuration options, could you not set up an ISC zone which BIND on startup will ping with a few packets? You'd get a lot more (and more accurate) feedback than sending out a plea on a mailing list. You could make it a compile time option, ask for permission at build time, etc.. -- 73, Ged. ___ 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
Re: A policy for removing named.conf options.
> On 13 Jun 2019, at 14:18, Warren Kumari wrote: > >> 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. > > Many many people don't look at their logs -- could named also print > stuff to (stdout, stderr) when starting? That probably won’t work Warren. The people that don’t/won't read their logs are unlikely to read named’s stdout or stderr. Assuming they knew were these went. Besides, those file descriptors are usually closed or get redirected to /dev/null whenever a daemon gets started from init or its equivalents: % lsof -p 11450 COMMAND PID USER FD TYPE DEVICE SIZE/OFF NODE NAME ... named-9.1 11450 nobody0uVCHR 0,25 0t025 /dev/null named-9.1 11450 nobody1uVCHR 0,25 0t025 /dev/null named-9.1 11450 nobody2uVCHR 0,25 0t025 /dev/null How about having named-checkconf alert people to config file elements that are dead or about to die? This could then be documented in the README or INSTALL files and the ARM. I know, I know - nobody reads them either. :-( Failing to start the name server because of a deprecated element in named.conf would certainly get someone's attention. Effective, but perhaps a bit extreme. :-) ___ 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
Re: A policy for removing named.conf options.
Hi Warren and everybody, first, let me thank for the fruitful discussion! > On 13 Jun 2019, at 15:18, Warren Kumari wrote: > > Many many people don't look at their logs -- could named also print > stuff to (stdout, stderr) when starting? > > Note that this will require some testing -- various distributions use > various init scripts - in many cases things printed at startup don't > actually make it to the console, and I'm suspecting some init systems > will barf, but… It’s undermentioned in the policy proposal, but the named-checkconf will be loud about the deprecated options. We can then bug distros to integrate the named-checkconf run into the pre/postinst maintainer scripts. (Hey myself, fix the Debian package. Ok, myself…) > Another phased approach would be to require users to acknowledge that > the feature is being deprecated -- initially it could warn, and then > named could require command line flags to enable the (being) > deprecated features, and then in the next release they would stop (e.g > named --enable_deprecated_cleaning-interval). I think that this is way > overkill, but just a thought. That would take 4 full years to deprecate single option, as we need to take people that upgrade from ESV to ESV into account, and we were aiming at slightly “faster” approach :-). Thanks, -- Ondřej Surý ond...@isc.org ___ 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
Re: A policy for removing named.conf options.
On Thu, Jun 13, 2019 at 6:46 AM Matthijs Mekking wrote: > > Dear BIND 9 users, > > 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. > > 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 deprecated options. > > The policy below describes our proposal for the procedure for removing > named.conf options. We would like to hear your feedback. > > Thanks, best regards, > > Matthijs > > > # Policy for removing named.conf options > > A named.conf option will first become deprecated before it is removed > from the code and becomes an unknown option. > > ## 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. Many many people don't look at their logs -- could named also print stuff to (stdout, stderr) when starting? Note that this will require some testing -- various distributions use various init scripts - in many cases things printed at startup don't actually make it to the console, and I'm suspecting some init systems will barf, but... Another phased approach would be to require users to acknowledge that the feature is being deprecated -- initially it could warn, and then named could require command line flags to enable the (being) deprecated features, and then in the next release they would stop (e.g named --enable_deprecated_cleaning-interval). I think that this is way overkill, but just a thought. W > Configuration options that are deprecated will be identified in the > Release Note for the release they are deprecated in. > > Deprecating an option can be done at any time, but preferably before the > next ESV release. For example, an option that that needs to be > deprecated before the ESV 9.16 will need to flagged so in the 9.15 > development or the 9.14 stable release. > > ## Removing > > A user that has a removed option configured will be unable to start > `named` because the configuration option is no longer known. 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. Configuration options that are removed > from BIND 9 will be noted in the Release Note for the first version they > are removed from. > > For example, an option that has been marked as deprecated before 9.16 > could 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 > also stay in 9.19/9.20. > > ## Removing related code > > The code that relates to a configuration option that is to be removed > will in general be deleted at the same time as the configuration option > is removed. The BIND 9 team may decide to remove the related code at an > earlier stage if it is considered harmful to keep. In that case the > option will become obsolete rather than deprecated. > > ## Candidate options to be deprecated/removed > > 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. > > Below is a table of candidate options we may deprecate and remove. This > list is by no means set in stone. Feel free to add suggestions, or add > comments. > > | option | will be deprecated in | comments | > | -- | - | - | > | cleaning-interval | 9.15/9.16 | obsolete | > | dnssec-update-mode | | use auto-dnssec instead | > | dialup | | | > | managed-keys | 9.15/9.16 | replaced with dnssec-keys | > | trusted-keys | 9.15/9.16 | replaced with dnssec-keys | > > In addition, there are already quite some options that are ancient, > obsoleted, or never implemented before 9.15. They are listed in this issue: > > https://gitlab.isc.org/isc-projects/bind9/issues/1086 > > and may be removed in the next stable release after 9.16. > > ___ > Please visit
Re: A policy for removing named.conf options.
Hi, On 6/13/19 2:40 PM, G.W. Haywood via bind-users wrote: > Hi there, > > On Thu, 13 Jun 2019, Matthijs Mekking wrote: > >> We would like to hear your feedback. > > Thank you for the timely heads up. > >> | managed-keys | 9.15/9.16 | replaced with dnssec-keys | > > According to my changelogs for 'named.conf I removed 'managed-keys' and > 'trusted-keys' three years ago, but still use 'managed-keys-directory'. First of all, it is likely that you are using managed trust anchors that are configured with 'managed-keys' in a bind.keys file. If not, I believe that having `managed-keys-directory` is useless. > Will the option 'managed-keys-directory' also be deprecated? The option `managed-keys-directory` will stay because it will serve as the directory to store the files that track managed DNSSEC keys (i.e., those configured using "initial-key" keyword in the new "dnssec-keys" statement. Best regards, Matthijs signature.asc Description: OpenPGP digital 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
Re: A policy for removing named.conf options.
Hi there, On Thu, 13 Jun 2019, Matthijs Mekking wrote: We would like to hear your feedback. Thank you for the timely heads up. | managed-keys | 9.15/9.16 | replaced with dnssec-keys | According to my changelogs for 'named.conf I removed 'managed-keys' and 'trusted-keys' three years ago, but still use 'managed-keys-directory'. Will the option 'managed-keys-directory' also be deprecated? -- 73, Ged. ___ 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
RE: A policy for removing named.conf options.
I'd suggest also giving warnings for deprecated options when running named-checkconf (and named-checkzone if applicable). You mention the logs but not the commands. Jeffrey C. Lightner Sr. UNIX/Linux Administrator DS Services of America, Inc. 2300 Windy Ridge Pkwy Suite 600 N Atlanta, GA 30339-8461 P: 678-486-3516 C: 678-772-0018 F: 678-460-3603 E: jlight...@dsservices.com -Original Message- From: bind-users On Behalf Of Matthijs Mekking Sent: Thursday, June 13, 2019 6:47 AM To: bind-users@lists.isc.org Subject: A policy for removing named.conf options. Dear BIND 9 users, 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. 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 deprecated options. The policy below describes our proposal for the procedure for removing named.conf options. We would like to hear your feedback. Thanks, best regards, Matthijs # Policy for removing named.conf options A named.conf option will first become deprecated before it is removed from the code and becomes an unknown option. ## 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. Configuration options that are deprecated will be identified in the Release Note for the release they are deprecated in. Deprecating an option can be done at any time, but preferably before the next ESV release. For example, an option that that needs to be deprecated before the ESV 9.16 will need to flagged so in the 9.15 development or the 9.14 stable release. ## Removing A user that has a removed option configured will be unable to start `named` because the configuration option is no longer known. 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. Configuration options that are removed from BIND 9 will be noted in the Release Note for the first version they are removed from. For example, an option that has been marked as deprecated before 9.16 could 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 also stay in 9.19/9.20. ## Removing related code The code that relates to a configuration option that is to be removed will in general be deleted at the same time as the configuration option is removed. The BIND 9 team may decide to remove the related code at an earlier stage if it is considered harmful to keep. In that case the option will become obsolete rather than deprecated. ## Candidate options to be deprecated/removed 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. Below is a table of candidate options we may deprecate and remove. This list is by no means set in stone. Feel free to add suggestions, or add comments. | option | will be deprecated in | comments | | -- | - | - | | cleaning-interval | 9.15/9.16 | obsolete | | dnssec-update-mode | | use auto-dnssec instead | | dialup | | | | managed-keys | 9.15/9.16 | replaced with dnssec-keys | | trusted-keys | 9.15/9.16 | replaced with dnssec-keys | In addition, there are already quite some options that are ancient, obsoleted, or never implemented before 9.15. They are listed in this issue: https://gitlab.isc.org/isc-projects/bind9/issues/1086 and may be removed in the next stable release after 9.16. ___ 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
