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 <jlight...@dsservices.com> 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 <bind-users-boun...@lists.isc.org> On Behalf Of Warren Kumari > Sent: Thursday, June 13, 2019 2:53 PM > To: Evan Hunt <e...@isc.org> > Cc: Ondřej Surý <ond...@isc.org>; 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 <e...@isc.org> 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
