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 wrote:
>
>
>
>> On 3 Nov 2023, at 02:18, Viktor Dukhovni 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
