X-RT-Incoming-Encryption: Not encrypted Received: from mx.pao1.isc.org (mx.pao1.isc.org [149.20.64.53]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "mx.pao1.isc.org", Issuer "COMODO RSA Organization Validation Secure Server CA" (not verified)) by bugs.isc.org (Postfix) with ESMTPS id 775DDD78B0F for ; Fri, 9 Feb 2018 04:36:16 +0000 (UTC) Received: from mail.banu.com (mail.banu.com [46.4.129.225]) by mx.pao1.isc.org (Postfix) with ESMTP id 2632F3AB003 for ; Fri, 9 Feb 2018 04:36:13 +0000 (UTC) Received: from jurassic (unknown [49.203.218.231]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mail.banu.com (Postfix) with ESMTPSA id 96EF932C009F; Fri, 9 Feb 2018 04:36:11 +0000 (UTC) content-type: text/plain; charset="utf-8" X-Spam-Checker-Version: SpamAssassin 3.4.1 (2015-04-28) on mx.pao1.isc.org Content-Disposition: inline Subject: Re: [ISC-Bugs #43670] Warn on seeing trusted-keys option in config Delivered-To: bind9-confidential@bugs.isc.org To: "Mark Andrews via RT" X-RT-Original-Encoding: utf-8 Return-Path: From muks@isc.org Fri Feb 9 04:36:16 2018 X-Original-To: bind9-confidential@bugs.isc.org From: "Mukund Sivaraman" Date: Fri, 9 Feb 2018 10:06:07 +0530 References: <20161117035644.E572B5A5BED1@rock.dv.isc.org> <20180208190956.GA31608@jurassic> MIME-Version: 1.0 In-Reply-To: X-Spam-Status: No, score=0.0 required=5.0 tests=none autolearn=disabled version=3.4.1 X-RT-Interface: Email User-Agent: Mutt/1.9.2 (2017-12-15) Message-ID: <20180209043607.GA5231@jurassic> RT-Message-ID: Content-Length: 995 On Thu, Feb 08, 2018 at 10:08:32PM +0000, Mark Andrews via RT wrote: > On Thu Feb 08 09:10:07 2018, muks wrote: > > On Thu, Nov 17, 2016 at 03:56:57AM +0000, Mark Andrews via RT wrote: > > > Warning for "." and "dlv.isc.org" when they match the built-in > > > managed keys would be appropriate. > > > > Somehow this ticket seems to have dropped off the radar. > > > > Please review rt43670. > > > > Mukund > > > > No!!! Named is used in private networks where trusted-keys for the root > is perfectly appropriate. > > dlv.isc.org already has plenty of warnings. > > A warning for a trusted-key for "." which matches the to be removed > key without the added key already being present would be the point > where I would issue a warning. Anything else is going to generate > noise or is us enforcing our policy ideas on the operator. > > Also all this code should be bin lib/bind9/check.c OK. I checked the code that was merged and it looks like a better way to handle it. Mukund