Re: dnssec-validation auto vs yes

2019-06-13 Thread Tony Finch
Shawn Zhou via bind-users wrote: > Thanks Even. Sounds like "dnssec-validation auto" is a more > future-proof option for what want it. I will use that instead. My recommendation is to avoid configuring or installing root trust anchors, and let named handle all that itself. In BIND 9.14 and

A policy for removing named.conf options.

2019-06-13 Thread 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

Re: A policy for removing named.conf options.

2019-06-13 Thread 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

Re: A policy for removing named.conf options.

2019-06-13 Thread Warren Kumari
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

Re: A policy for removing named.conf options.

2019-06-13 Thread Ondřej Surý
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

Re: A policy for removing named.conf options.

2019-06-13 Thread Jim Reid
> 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

Re: A policy for removing named.conf options.

2019-06-13 Thread Ondřej Surý
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

RE: A policy for removing named.conf options.

2019-06-13 Thread Lightner, Jeffrey
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

Re: A policy for removing named.conf options.

2019-06-13 Thread Barry Margolin
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

RE: A policy for removing named.conf options.

2019-06-13 Thread 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 

Re: A policy for removing named.conf options.

2019-06-13 Thread G.W. Haywood via bind-users
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

Re: A policy for removing named.conf options.

2019-06-13 Thread Ondřej Surý
> 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.

Re: A policy for removing named.conf options.

2019-06-13 Thread Leroy Tennison
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

Re: A policy for removing named.conf options.

2019-06-13 Thread G.W. Haywood via bind-users
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

Re: A policy for removing named.conf options.

2019-06-13 Thread Leroy Tennison
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

Upcoming changes to the BIND 9 build system - Introduction of automake

2019-06-13 Thread Ondřej Surý
Hey all, I’ve been working on rewriting the build system from plain autoconf (+optional libtool) to the modern toolchain that uses all the kids on the block - autoconf, automake, libtool and pkg-config. The work in progress can be found in

Re: A policy for removing named.conf options.

2019-06-13 Thread Ondřej Surý
> 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

Re: A policy for removing named.conf options.

2019-06-13 Thread John Thurston
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

Re: A policy for removing named.conf options.

2019-06-13 Thread G.W. Haywood via bind-users
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

Re: A policy for removing named.conf options.

2019-06-13 Thread Evan Hunt
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

per zone dnssec setting

2019-06-13 Thread Shawn Zhou via bind-users
Hi, Does BIND9 allow per zone dnssec setting? I wanted to forward requests for certain zone to remote resolvers which doesn't support DNSSEC and also disable dnssec validation for that particular zone because forward-only resolver will return SERVFAIL to the client when the remote resolves

Re: A policy for removing named.conf options.

2019-06-13 Thread Warren Kumari
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

RE: A policy for removing named.conf options.

2019-06-13 Thread 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 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

Re: dnssec-validation auto vs yes

2019-06-13 Thread Warren Kumari
On Wed, Jun 12, 2019 at 8:25 PM Evan Hunt wrote: > > On Wed, Jun 12, 2019 at 11:40:27PM +, Shawn Zhou via bind-users wrote: > > The default BIND9 installation for CentOS7 has dnssec-validation set to > > "yes" and it also includes managed-keys as well. Do those managed-keys > > get updated

Re: A policy for removing named.conf options.

2019-06-13 Thread Warren Kumari
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

Re: A policy for removing named.conf options.

2019-06-13 Thread Evan Hunt
> > 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

Re: A policy for removing named.conf options.

2019-06-13 Thread @lbutlr
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

RE: A policy for removing named.conf options.

2019-06-13 Thread Browne, Stuart via bind-users
> -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,