A policy for removing named.conf options.

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
26 messages Options
12
Reply | Threaded
Open this post in threaded view
|

A policy for removing named.conf options.

Matthijs Mekking
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
[hidden email]
https://lists.isc.org/mailman/listinfo/bind-users

signature.asc (499 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

RE: A policy for removing named.conf options.

Lightner, Jeffrey
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: [hidden email]

-----Original Message-----
From: bind-users <[hidden email]> On Behalf Of Matthijs Mekking
Sent: Thursday, June 13, 2019 6:47 AM
To: [hidden email]
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
[hidden email]
https://lists.isc.org/mailman/listinfo/bind-users
Reply | Threaded
Open this post in threaded view
|

Re: A policy for removing named.conf options.

Bind-Users forum mailing list
In reply to this post by Matthijs Mekking
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
[hidden email]
https://lists.isc.org/mailman/listinfo/bind-users
Reply | Threaded
Open this post in threaded view
|

Re: A policy for removing named.conf options.

Matthijs Mekking
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



_______________________________________________
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list

bind-users mailing list
[hidden email]
https://lists.isc.org/mailman/listinfo/bind-users

signature.asc (499 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: A policy for removing named.conf options.

Warren Kumari
In reply to this post by Matthijs Mekking
On Thu, Jun 13, 2019 at 6:46 AM Matthijs Mekking <[hidden email]> 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 https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list
>
> bind-users mailing list
> [hidden email]
> 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
[hidden email]
https://lists.isc.org/mailman/listinfo/bind-users
Reply | Threaded
Open this post in threaded view
|

Re: A policy for removing named.conf options.

Ondřej Surý
Hi Warren and everybody,

first, let me thank for the fruitful discussion!

> On 13 Jun 2019, at 15:18, Warren Kumari <[hidden email]> 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ý
[hidden email]

_______________________________________________
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list

bind-users mailing list
[hidden email]
https://lists.isc.org/mailman/listinfo/bind-users
Reply | Threaded
Open this post in threaded view
|

Re: A policy for removing named.conf options.

Jim Reid
In reply to this post by Warren Kumari


> On 13 Jun 2019, at 14:18, Warren Kumari <[hidden email]> 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 nobody    0u    VCHR               0,25      0t0        25 /dev/null
named-9.1 11450 nobody    1u    VCHR               0,25      0t0        25 /dev/null
named-9.1 11450 nobody    2u    VCHR               0,25      0t0        25 /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
[hidden email]
https://lists.isc.org/mailman/listinfo/bind-users
Reply | Threaded
Open this post in threaded view
|

Re: A policy for removing named.conf options.

Bind-Users forum mailing list
In reply to this post by Matthijs Mekking
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
[hidden email]
https://lists.isc.org/mailman/listinfo/bind-users
Reply | Threaded
Open this post in threaded view
|

Re: A policy for removing named.conf options.

Leroy Tennison
In reply to this post by Ondřej Surý

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: [hidden email]


2220 Bush Dr
McKinney, Texas
75070
www.datavoiceint.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.

If you prefer not to be contacted by Harris Operating Group please notify us.

 

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 <[hidden email]> on behalf of Ondřej Surý <[hidden email]>
Sent: Thursday, June 13, 2019 8:37 AM
To: Warren Kumari
Cc: [hidden email]
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 <[hidden email]> 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ý
[hidden email]

_______________________________________________
Please visit https://linkprotect.cudasvc.com/url?a=https%3a%2f%2flists.isc.org%2fmailman%2flistinfo%2fbind-users&c=E,1,yw6EFdI2bCuC2na2ur7-F1G92uow3vtsWpruIMf4wVLkS96WojpFuQ9yFBatKWXzbsJWnOpPiH9CsJum226CS7Pr4Oi5GsbAuvBcrpl8GbMNpGxrMrpl3M9XNfw,&typo=1 to unsubscribe from this list

bind-users mailing list
[hidden email]
https://linkprotect.cudasvc.com/url?a=https%3a%2f%2flists.isc.org%2fmailman%2flistinfo%2fbind-users&c=E,1,YVga50vu8jtaQRjJyL3EYLTif7UroYK4D1uIX3KMLr4tHA0WEL7m4ytBOAe3Ry1gkCjeaIlSnMv7JrNAOoVnw5JLA1CytXg871RJx0Ey&typo=1


_______________________________________________
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list

bind-users mailing list
[hidden email]
https://lists.isc.org/mailman/listinfo/bind-users
Reply | Threaded
Open this post in threaded view
|

Re: A policy for removing named.conf options.

Ondřej Surý
In reply to this post by Bind-Users forum mailing list
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ý
[hidden email]

> On 13 Jun 2019, at 15:55, G.W. Haywood via bind-users <[hidden email]> 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
> [hidden email]
> 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
[hidden email]
https://lists.isc.org/mailman/listinfo/bind-users
Reply | Threaded
Open this post in threaded view
|

RE: A policy for removing named.conf options.

Lightner, Jeffrey
In reply to this post by Leroy Tennison

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 <[hidden email]> On Behalf Of Leroy Tennison
Sent: Thursday, June 13, 2019 9:57 AM
To: [hidden email]
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 <a href="http://">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: [hidden email]


2220 Bush Dr
McKinney, Texas
75070
www.datavoiceint.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.

If you prefer not to be contacted by Harris Operating Group please notify us.

 

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 <[hidden email]> on behalf of Ondřej Surý <[hidden email]>
Sent: Thursday, June 13, 2019 8:37 AM
To: Warren Kumari
Cc: [hidden email]
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 <[hidden email]> 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ý
[hidden email]

_______________________________________________
Please visit https://linkprotect.cudasvc.com/url?a=https%3a%2f%2flists.isc.org%2fmailman%2flistinfo%2fbind-users&c=E,1,yw6EFdI2bCuC2na2ur7-F1G92uow3vtsWpruIMf4wVLkS96WojpFuQ9yFBatKWXzbsJWnOpPiH9CsJum226CS7Pr4Oi5GsbAuvBcrpl8GbMNpGxrMrpl3M9XNfw,&typo=1 to unsubscribe from this list

bind-users mailing list
[hidden email]
https://linkprotect.cudasvc.com/url?a=https%3a%2f%2flists.isc.org%2fmailman%2flistinfo%2fbind-users&c=E,1,YVga50vu8jtaQRjJyL3EYLTif7UroYK4D1uIX3KMLr4tHA0WEL7m4ytBOAe3Ry1gkCjeaIlSnMv7JrNAOoVnw5JLA1CytXg871RJx0Ey&typo=1


_______________________________________________
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list

bind-users mailing list
[hidden email]
https://lists.isc.org/mailman/listinfo/bind-users
Reply | Threaded
Open this post in threaded view
|

Re: A policy for removing named.conf options.

Leroy Tennison
In reply to this post by Ondřej Surý

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 <[hidden email]> on behalf of Ondřej Surý <[hidden email]>
Sent: Thursday, June 13, 2019 9:22:53 AM
To: G.W. Haywood
Cc: [hidden email]
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&c=E,1,5RfyTpYfPh7xliqVD4MiTRmekNfpBmTXzQmVptTqjqm1ew4vcDjQwzkKiVAlJhtyT_HqrdNmh4vqy-Umg9NGAUvDh_3a7EB7SlLtOH6OKbxmhCUZxrp9n8zD&typo=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ý
[hidden email]

&g

Harriscomputer

Leroy Tennison
Network Information/Cyber Security Specialist
E: [hidden email]


2220 Bush Dr
McKinney, Texas
75070
www.datavoiceint.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.

If you prefer not to be contacted by Harris Operating Group please notify us.

 

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 <[hidden email]> 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&c=E,1,CqxGXQ1aiGLDV9LxLwljfYJRolmwJV3RlfcYaNABVsMlBnR5RJRsa2BaKR3xs-G5eFTxIA841AhYXTegjj-ggT2H9TJqOoJb18sEG8eenJz3jV80sk-eIJ1K&typo=1 to unsubscribe from this list
>
> bind-users mailing list
> [hidden email]
> https://linkprotect.cudasvc.com/url?a=https%3a%2f%2flists.isc.org%2fmailman%2flistinfo%2fbind-users&c=E,1,lrTADuMZK7-3YQwQVI98M2QtIe3X6vetMWM-r7d7aOkIyI4r9ebviUn3Zt3DP7266hKmVaHsi7YHuqRMl2Qa34whLALYOPPIkAmRLthBNJxi5A,,&typo=1

_______________________________________________
Please visit https://linkprotect.cudasvc.com/url?a=https%3a%2f%2flists.isc.org%2fmailman%2flistinfo%2fbind-users&c=E,1,__bZRbafpXn77YybXrIT8vrp5HPPCi47lEsNtl-XZNPm4xWpJaPv9WPRyYhW3ZVQvnsQgeCu5aVZu0wCqwBWSSWRNUEyvXYAcg-qkT-ZxuxC4DuEJSd0BmCGog,,&typo=1 to unsubscribe from this list

bind-users mailing list
[hidden email]
https://linkprotect.cudasvc.com/url?a=https%3a%2f%2flists.isc.org%2fmailman%2flistinfo%2fbind-users&c=E,1,ISqAFF76QaPqnU4mChTvAsOO3ML7KgbBDfwn3SbpXS-IEHJzUjsTCizHF7IZrVYRstLhmfu0DKXlGExNXKlgM_d16WvubXeUUOJqNO6T6Q,,&typo=1

_______________________________________________
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list

bind-users mailing list
[hidden email]
https://lists.isc.org/mailman/listinfo/bind-users
Reply | Threaded
Open this post in threaded view
|

Re: A policy for removing named.conf options.

Bind-Users forum mailing list
In reply to this post by Matthijs Mekking
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
[hidden email]
https://lists.isc.org/mailman/listinfo/bind-users
Reply | Threaded
Open this post in threaded view
|

Re: A policy for removing named.conf options.

Barry Margolin
In reply to this post by Matthijs Mekking
In article <[hidden email]>,
 Matthijs Mekking <[hidden email]> 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
[hidden email]
https://lists.isc.org/mailman/listinfo/bind-users
Reply | Threaded
Open this post in threaded view
|

Re: A policy for removing named.conf options.

John Thurston
In reply to this post by Lightner, Jeffrey
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 Thurston    907-465-8591
[hidden email]
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
[hidden email]
https://lists.isc.org/mailman/listinfo/bind-users
Reply | Threaded
Open this post in threaded view
|

Re: A policy for removing named.conf options.

Ondřej Surý
In reply to this post by Barry Margolin

> On 13 Jun 2019, at 17:55, Barry Margolin <[hidden email]> wrote:
>
> In article <[hidden email]>,
> Matthijs Mekking <[hidden email]> 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ý
[hidden email]
_______________________________________________
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list

bind-users mailing list
[hidden email]
https://lists.isc.org/mailman/listinfo/bind-users
Reply | Threaded
Open this post in threaded view
|

Re: A policy for removing named.conf options.

Ondřej Surý
In reply to this post by John Thurston

> On 13 Jun 2019, at 18:10, John Thurston <[hidden email]> 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ý
[hidden email]

_______________________________________________
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list

bind-users mailing list
[hidden email]
https://lists.isc.org/mailman/listinfo/bind-users
Reply | Threaded
Open this post in threaded view
|

Re: A policy for removing named.conf options.

Evan Hunt
In reply to this post by Ondřej Surý
> > 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 -- [hidden email]
Internet Systems Consortium, Inc.
_______________________________________________
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list

bind-users mailing list
[hidden email]
https://lists.isc.org/mailman/listinfo/bind-users
Reply | Threaded
Open this post in threaded view
|

Re: A policy for removing named.conf options.

Warren Kumari
On Thu, Jun 13, 2019 at 2:43 PM Evan Hunt <[hidden email]> 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 -- [hidden email]
> Internet Systems Consortium, Inc.
> _______________________________________________
> Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list
>
> bind-users mailing list
> [hidden email]
> 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
[hidden email]
https://lists.isc.org/mailman/listinfo/bind-users
Reply | Threaded
Open this post in threaded view
|

RE: A policy for removing named.conf options.

Lightner, Jeffrey
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 <[hidden email]> On Behalf Of Warren Kumari
Sent: Thursday, June 13, 2019 2:53 PM
To: Evan Hunt <[hidden email]>
Cc: Ondřej Surý <[hidden email]>; [hidden email]
Subject: Re: A policy for removing named.conf options.

On Thu, Jun 13, 2019 at 2:43 PM Evan Hunt <[hidden email]> 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 -- [hidden email]
> Internet Systems Consortium, Inc.
> _______________________________________________
> Please visit https://lists.isc.org/mailman/listinfo/bind-users to
> unsubscribe from this list
>
> bind-users mailing list
> [hidden email]
> 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
[hidden email]
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
[hidden email]
https://lists.isc.org/mailman/listinfo/bind-users
12