From dot@dotat.at Fri Jul 28 10:00:30 2017 CC: "Tony Finch" To: "Mark Andrews via RT" Date: Fri, 28 Jul 2017 11:00:30 +0100 content-type: TEXT/PLAIN; charset="utf-8" X-RT-Incoming-Encryption: Not encrypted Return-Path: X-Original-To: bind9-public@bugs.isc.org Delivered-To: bind9-public@bugs.isc.org From: "Tony Finch" X-Cam-Antivirus: no malware found References: <20170728011421.874A5802ED01@rock.dv.isc.org> In-Reply-To: Message-ID: X-RT-Interface: Email X-RT-Original-Encoding: utf-8 User-Agent: Alpine 2.11 (DEB 23 2013-08-11) X-Cam-Scannerinfo: http://help.uis.cam.ac.uk/email-scanner-virus 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 0F62BD78ACE for ; Fri, 28 Jul 2017 10:00:30 +0000 (UTC) Received: from ppsw-30.csi.cam.ac.uk (ppsw-30.csi.cam.ac.uk [131.111.8.130]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx.pao1.isc.org (Postfix) with ESMTPS id C80633499FD for ; Fri, 28 Jul 2017 10:00:33 +0000 (UTC) Received: from grey.csi.cam.ac.uk ([131.111.57.57]:55823) by ppsw-30.csi.cam.ac.uk (ppsw.cam.ac.uk [131.111.8.136]:25) with esmtps (TLSv1:ECDHE-RSA-AES256-SHA:256) id 1db24M-000jeY-fu (Exim 4.89) (return-path ); Fri, 28 Jul 2017 11:00:31 +0100 X-Spam-Status: No, score=-4.2 required=5.0 tests=BAYES_00,RCVD_IN_DNSWL_MED, RCVD_IN_MSPIKE_H3,RCVD_IN_MSPIKE_WL autolearn=ham autolearn_force=no version=3.4.0 X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on mx.pao1.isc.org MIME-Version: 1.0 Subject: Re: [ISC-Bugs #45629] when update add CDS is REFUSED RT-Message-ID: Content-Length: 1442 Mark Andrews via RT wrote: > > With inline signing DNSSEC records (other than DS) are modified by > other paths than using UPDATE. I would be using these mechanisms > instead of UPDATE even with normal signed zones. Yes, I'm aware of those mechanisms. But for quick fiddling, and for testing broken CDS RRsets, I hoped I could use UPDATE. I think something the patch below would have helped avoid confusion. (Is this the right test for the security status of a zone?) --- bin/named/update.c | 9 +++++++-- 1 file changed, 7 insertions(+), 2 deletions(-) diff --git a/bin/named/update.c b/bin/named/update.c index cd62c5d..5023dff 100644 --- a/bin/named/update.c +++ b/bin/named/update.c @@ -3100,9 +3100,14 @@ update_action(isc_task_t *task, isc_event_t *event) { if (! ISC_LIST_EMPTY(diff.tuples)) { result = dns_zone_cdscheck(zone, db, ver); if (result == DNS_R_BADCDS || result == DNS_R_BADCDNSKEY) { + isc_boolean_t secure = + dns_zone_getkeyopts(zone) & + (DNS_ZONEKEY_ALLOW|DNS_ZONEKEY_MAINTAIN); update_log(client, zone, LOGLEVEL_PROTOCOL, - "update rejected: bad %s RRset", - result == DNS_R_BADCDS ? "CDS" : "CDNSKEY"); + "update rejected: bad %s RRset%s", + result == DNS_R_BADCDS ? "CDS" : "CDNSKEY", + !secure ? " (zone is unsigned" + " or inline-signing)" : ""); result = DNS_R_REFUSED; goto failure; } -- 2.10.1.445.g3cdd5d1