I liked Viktor’s idea. It would be cool if time-to-re-sign and time-to-signature-expiration were available on the json/xml stats port. (Or are they and I missed it? The last time I used the json/xml stuff, I wasn’t getting metrics for signed zones, just the usual counters and the time-to-expire for secondaries…)
-Steve > On Nov 3, 2023, at 1:43 AM, Mark Andrews <ma...@isc.org> wrote: > > > >> On 3 Nov 2023, at 02:18, Viktor Dukhovni <ietf-d...@dukhovni.org> wrote: >> >> On Thu, Nov 02, 2023 at 09:34:17AM +0100, Stephane Bortzmeyer wrote: >> >>>> Specifically, in the case of signed zones, monitoring MUST also include >>>> regular checks of the remaining expiration time of at least the core >>>> zone apex records (DNSKEY, SOA and NS), and ideally the whole zone, both >>>> on the primary server and the secondaries. >>> >>> Indeed. If you use Nagios or compatible (such as Icinga), I recommend >>> this plugin for signatures monitoring: >>> >>> http://dns.measurement-factory.com/tools/nagios-plugins/check_zone_rrsig_expiration.html >> >> I wonder whether the widely authoritative resolvers could do more to >> to help? >> >> For example, BIND loads zone data into memory. It should be able to >> know the time of the soonest signature expiration for a zone, or at >> least (if not loaing the whole zone into memory) the soonest expiration >> time is of recently queried records. > > When you let named perform the signing it does just that. The RRSIGs are > in a heap. We look at the earliest expiration and figure out when it is > due to be re-signed (could be in the past if the server was offline for a > while). We set a timer. When that timer expires we re-sign that RRset plus > several more along with an updated SOA record re-adding them to the heap. > We set a timer for the next batch. If the primary has been down too long > and they have all expired the entire zone will be signed this way when the > primary starts up. > >> There could be a new "rdnc" protocol verb that asks the nameserver for a >> list of all the zones where the soonest expiration time is below some >> threshold, or askes about a particular zone. >> >> Of course in that case the monitoring agent would be a in a "privileged" >> position to query the nameserver's internal control plane, rather than >> having to send queries through "the front door". >> >> Both kinds of monitoring are likely important, but more visibility via >> the control plane may be able to offer a precise/timely view. >> >> - Check each nameserver's control plane. >> - Check as much of the zone as possible. >> - Check each nameserver VIP over each supported protocol >> (UDP, TCP, DoT, DoQ, ...) >> - From multiple vantage points if possible/applicable when >> service is on anycast IPs. >> >> Perhaps through OARC support development of monitoring plugins that >> many operators can use? >> >> If after all the past incidents minor and not so minor operators >> still aren't doing adequate monitoring, perhaps we (the software >> and standards) developers and haven't given them adequate tools? >> >> -- >> Viktor. >> _______________________________________________ >> dns-operations mailing list >> dns-operations@lists.dns-oarc.net >> https://lists.dns-oarc.net/mailman/listinfo/dns-operations > > -- > Mark Andrews, ISC > 1 Seymour St., Dundas Valley, NSW 2117, Australia > PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org > > > _______________________________________________ > dns-operations mailing list > dns-operations@lists.dns-oarc.net > https://lists.dns-oarc.net/mailman/listinfo/dns-operations _______________________________________________ dns-operations mailing list dns-operations@lists.dns-oarc.net https://lists.dns-oarc.net/mailman/listinfo/dns-operations