When positive wildcard expansion happens, NSEC(3) records are needed
to prove that the expansion was allowed. If the NSEC3 had too many
iterations, we downgrade the answer to insecure status, but
unintentionally we also dropped the NSEC3 record from the answer.
That was breaking DNSSEC validation of that answer, e.g. when
forwarding to Knot Resolver. The validator needs the NSEC3 -
either to validate the expansion or to determine that it's too expensive.
------------
- stats: add separate metrics for IPv6 and IPv4 (!1544)
+Bugfixes
+--------
+- fix NSEC3 records missing in answer for positive wildcard expansion
+ with the NSEC3 having over-limit iteration count (#910, !1550)
+
+
Knot Resolver 5.7.2 (2024-03-27)
================================
}
} else if (!query->parent) {
/* Answer for initial query */
- const bool to_wire = ((pkt_class & (PKT_NXDOMAIN|PKT_NODATA)) != 0);
+ const bool to_wire = ((pkt_class & (PKT_NXDOMAIN|PKT_NODATA)) != 0)
+ /* We need to cover the case of positive wildcard answer
+ * with over-limit NSEC3 iterations. */
+ || query->flags.DNSSEC_WEXPAND;
state = pick_authority(pkt, req, to_wire);
if (state != kr_ok()) {
return KR_STATE_FAIL;