RUSTSEC-2026-0509 NSEC3 records from another zone were accepted in proofs of nonexistence

When DNSSEC validation used NSEC3 records to prove that a name or record type does not exist, it compared only the hashed first label of each NSEC3 owner name with the hash of the name being checked. The rest of the owner name, which says which zone the record belongs to, was not checked. Someone...

Parent-side NSEC at a zone cut accepted as proof of nonexistence below the cut

At a delegation, the parent zone signs an NSEC record for the child's name whose type bitmap has NS but not SOA or has DNAME. RFC 6840 section 4.1 says such a record only proves that no DS record exists at that name. It says nothing about names below the cut or about other types at the cut, becau...

Child-side NSEC or NSEC3 record accepted as proof that a delegation has no DS record

To show that a delegation is insecure, a validator needs proof that the parent zone has no DS record for it. That proof must come from the parent side of the zone cut: RFC 4035 section 5.2, RFC 5155 section 8.9 and RFC 6840 section 4.4 require the matching NSEC or NSEC3 record not to have the SOA...

hickory-proto: NSEC3 closest-encloser proof validation enters unbounded loop on cross-zone responses

The NSEC3 closest-encloser proof validation in hickory-proto's 0.25.0-alpha.3 ... 0.25.2 and hickory-net's 0.26.0-alpha.1 .. 0.26.0 DnssecDnsHandle walks from the QNAME up to the SOA owner name, building a list of candidate encloser names. The iterator used assumes the QNAME is a descendant of th...