A policy for removing named.conf options.

Lightner, Jeffrey JLightner at dsservices.com
Thu Jun 13 19:27:43 UTC 2019


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-bounces at lists.isc.org> On Behalf Of Warren Kumari
Sent: Thursday, June 13, 2019 2:53 PM
To: Evan Hunt <each at isc.org>
Cc: Ondřej Surý <ondrej at isc.org>; comp-protocols-dns-bind at isc.org
Subject: Re: A policy for removing named.conf options.

On Thu, Jun 13, 2019 at 2:43 PM Evan Hunt <each at 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 -- each at 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 at 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 at lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users


More information about the bind-users mailing list