X-RT-Interface: Email References: <3E18C1A0C550C44DA156DA5DA8ECCC6AA2D6EA43@NICS-EXCH2.sbg.nic.at> <30884B13-9973-4DBF-871F-E4AD21F4EA8C@isc.org> <20180103221602.GA73325@isc.org> To: "bind9-public@isc.org" From: "Klaus Darilion" Thread-Index: AdN4nu+KcdPwOOxmSIyu9X68aqyO5AMQZBojABWWvKA= X-Spam-Status: No, score=-5.0 required=5.0 tests=RCVD_IN_DNSWL_HI, RP_MATCHES_RCVD autolearn=unavailable autolearn_force=no version=3.4.1 In-Reply-To: X-Spam-Checker-Version: SpamAssassin 3.4.1 (2015-04-28) on mx.pao1.isc.org X-Originating-Ip: [10.10.0.45] X-RT-Incoming-Encryption: Not encrypted Date: Thu, 4 Jan 2018 08:52:34 +0000 Delivered-To: bind9-public@bugs.isc.org Content-Language: de-DE X-MS-Has-Attach: X-Original-To: bind9-public@bugs.isc.org Content-Transfer-Encoding: base64 Message-ID: <3E18C1A0C550C44DA156DA5DA8ECCC6AA2DA59F1@NICS-EXCH2.sbg.nic.at> MIME-Version: 1.0 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 194CDD78B0B for ; Thu, 4 Jan 2018 08:52:42 +0000 (UTC) Received: from mail.sbg.nic.at (mail.sbg.nic.at [83.136.33.227]) (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 60BBB3B8CA5 for ; Thu, 4 Jan 2018 08:52:38 +0000 (UTC) Received: from nics-exch2.sbg.nic.at ([10.17.175.6]) by mail.sbg.nic.at with XWall v3.53 ; Thu, 4 Jan 2018 09:52:36 +0100 Received: from NICS-EXCH2.sbg.nic.at ([fe80::a5b2:6e42:e54d:9d57]) by NICS-EXCH2.sbg.nic.at ([fe80::a5b2:6e42:e54d:9d57%12]) with mapi id 14.03.0361.001; Thu, 4 Jan 2018 09:52:36 +0100 Thread-Topic: [ISC-Bugs #46875] rndc zonestatus type is wrong for bump-in-the-wire signed zone X-Xwall-BCKS: auto From klaus.darilion@nic.at Thu Jan 4 08:52:42 2018 X-RT-Original-Encoding: utf-8 X-MS-Tnef-Correlator: content-type: text/plain; charset="utf-8" Return-Path: Accept-Language: de-AT, de-DE, en-US Subject: AW: [ISC-Bugs #46875] rndc zonestatus type is wrong for bump-in-the-wire signed zone RT-Message-ID: Content-Length: 1891 > -----Ursprüngliche Nachricht----- > Von: Evan Hunt via RT [mailto:bind9-public@isc.org] > Gesendet: Mittwoch, 3. Jänner 2018 23:16 > An: Klaus Darilion > Betreff: Re: [ISC-Bugs #46875] rndc zonestatus type is wrong for bump- > in-the-wire signed zone > > On Wed, Jan 03, 2018 at 10:08:32PM +0000, Mark Andrews via RT wrote: > > > What's there is okay, and can be committed, but it occurs to me it's > > > incomplete. We have expiry and refresh timers being reported only > for > > > the signed zone, but if the raw zone is type slave then we should > have it > > > reported for both, the way we currently do with serial numbers. > > > > They don’t make sense for the signed zone. s/zone/mayberaw/ > > That was my first thought, but I think those values are actually > potentially meaningful (even if only in an error condition) for > the signed zone too. > > We could switch to reporting from mayberaw in the existing code, > but change to a more detailed output format in 9.13. Some comment from a user: I actually found this issue as I was interested to find out the freshness-status of a slave zone - regardless if the zone is unsigned or "bump-in-the-wire" signed, and regardless if the zone is further slaved or not. Unfortunately the freshness status is missing total. With freshness I mean: - was the last SOA-check against the master successfull (at least 1 master if there are multiple masters) - is the slave's serial identical to the master's serial? - was the last XFR try successful? I want to know if there is a problem between master and slave bevore noticing that the zone expired. And this is currently not exposed to "zonestatus". Watching the logfile is cumbersome and may reports false positive if there are transitional communication problems. Shall I open a "feature request"? Thanks Klaus