On 3 Dec 2025, at 11:03, Viktor Dukhovni <[email protected]> wrote: > > On Wed, Dec 03, 2025 at 11:01:38AM +0100, Ondřej Surý wrote: >> Ok, look at the NSEC3 proof that the servers give: >> >> vesdsjhfre0tap5h15gth2f925g1nj4c.realtor. 3600 IN NSEC3 1 1 0 - ( >> VESDSJHFRE0TAP5H15GTH2F925G1NJ4C >> NS ) >> >> The NSEC3 record points back to itself instead of to the next name and it is >> being properly rejected as invalid. > > Are you sure that's invalid? A record that isn't last isn't supposed to > point backwawrds, but must otherwise the next value be a strict > successor (>) or merely not a strict predecessor (>=)? > > The NSEC3 in question is a "covering" record, since the qname hash falls > between the two values. I don't see clear language in RFC5155 that > precludes this (adminttedly fragile) corner case. > > One might credibly argue that BIND is too strict, while at the same time > also credibly argue that the signer is unwise to push its luck.
The fundamental issue is the following: These two records are mutually exclusive: unc76dksrlaqrktml8lett67lo33h3b2.realtor. 3600 in nsec3 1 1 0 - 6NMM0ATQNU3MC2CH7HSP6DQOIFC8HKUA A RRSIG vesdsjhfre0tap5h15gth2f925g1nj4c.realtor. 3600 in nsec3 1 1 0 - VESDSJHFRE0TAP5H15GTH2F925G1NJ4C NS The first "covers" the second. The authoritative server returns the second, assuming it is covering the hash of "hlaor.realtor" (5eb4b...) 5eb4b sorts before "6NMM....", which is the first nsec3 record in the list, so it will return the last, which is "vesds.....". BIND9 doesn't receive a covering NSEC3 record to prove that the DS for hlaor.realtor doesn't exist, and returns an err.r Warmly, Roy _______________________________________________ dns-operations mailing list [email protected] https://lists.dns-oarc.net/mailman/listinfo/dns-operations
