Currently, if some of the RRSIGs in a given RRset fail to validate (i.e. no matching key exists in DNSKEY), Zonemaster reports the following ERROR:
Trying to verify XXX RRset with signature XXX gave error 'No keys with the keytag and algorithm from the RRSIG found'.
This seems overly alarming. As far as I can tell, the presence of an RRSIG with no matching DNSKEY does not prevent the zone from being RFC-compliant. In fact, such a situation is perfectly normal and expected when doing a so-called "conservative algorithm rollover" as described in RFC 6781 4.1.4.
In fairness, it is not entirely clear how validators are supposed to behave when faced with an invalid RRSIG. RFC 4035 5.3.3 states that this is up to "local resolver security policy". RFC 6840 5.4 further restricts this to "a resolver SHOULD accept any valid RRSIG as sufficient, and only determine that an RRset is Bogus if all RRSIGs fail validation".
IMHO this finding should be demoted from ERROR to WARNING. However an ERROR should still be thrown if all RRSIGs for a given RRset fail validation.
Currently, if some of the RRSIGs in a given RRset fail to validate (i.e. no matching key exists in DNSKEY), Zonemaster reports the following ERROR:
This seems overly alarming. As far as I can tell, the presence of an RRSIG with no matching DNSKEY does not prevent the zone from being RFC-compliant. In fact, such a situation is perfectly normal and expected when doing a so-called "conservative algorithm rollover" as described in RFC 6781 4.1.4.
In fairness, it is not entirely clear how validators are supposed to behave when faced with an invalid RRSIG. RFC 4035 5.3.3 states that this is up to "local resolver security policy". RFC 6840 5.4 further restricts this to "a resolver SHOULD accept any valid RRSIG as sufficient, and only determine that an RRset is Bogus if all RRSIGs fail validation".
IMHO this finding should be demoted from ERROR to WARNING. However an ERROR should still be thrown if all RRSIGs for a given RRset fail validation.