[dns-operations] anchors.atlas.ripe.net/ripe.net - DNSSEC bogus due expiration

[Steven Miller]

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 <marka at isc.org> wrote:
> 
> 
> 
>> On 3 Nov 2023, at 02:18, Viktor Dukhovni <ietf-dane at 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 at 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: marka at isc.org
> 
> 
> _______________________________________________
> dns-operations mailing list
> dns-operations at lists.dns-oarc.net
> https://lists.dns-oarc.net/mailman/listinfo/dns-operations