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

[Mark Andrews]

> 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