dnssec-verify reports errors in NSEC3 chain

Summary

Please see the attached zone file. The output of dnssec-verify is:

$ faketime '2023-12-10' dnssec-verify -o 6DA7ffbF. 6DA7ffbF.rndzone
Loading zone '6DA7ffbF.' from file '6DA7ffbF.rndzone'

Verifying the zone using the following algorithms:
- ECDSAP256SHA256
Bad NSEC3 record for fadb1aa3f.6DA7ffbF, bit map mismatch
Expected and found NSEC3 chains not equal
Break in NSEC3 chain at: VKGD3TE5QRGB6S0KJH6UV3FKS9FUMRIV
Expected: 01EAMK8ES71TN6TKHOK512LQMCORC5O9
Found: 0R6S95GSLHH7HT7MFN2N1NJGNFS7Q2CQ
DNSSEC completeness test failed (failure).

I'd say that the NSEC3 chain is however correct.

Some notes:

• opt-out is not used
• fadb1aa3f.6da7ffbf. -> 01eamk8es71tn6tkhok512lqmcorc5o9.6da7ffbf. (first NSEC3 lexicographically, but this probably doesnt care)
• 427e09.owa.6da7ffbf. -> vkgd3te5qrgb6s0kjh6uv3fks9fumriv.6da7ffbf. (last NSEC3 lexicographically)
• node fadb1aa3f.6da7ffbf. is "weird" in the way that it's a delegation with non-authoritative data: MX and even DNSKEY(!), but this shouldn't influence the chaining of NSEC3, moreover, it relates to the bitmap at 01EAMK... and not VKGD3T...

BIND version affected

$ dnssec-verify -V
dnssec-verify 9.18.18-0ubuntu0.22.04.1-Ubuntu

Steps to reproduce

Use faketime as the RRSIGs are expired already. It doesn't matter since the errors are related to NSEC3s and not signatures.

The zone file in question is attached.

Just call $ faketime '2023-12-10' dnssec-verify -o 6DA7ffbF. 6DA7ffbF.rndzone

What is the current bug behavior?

Verify reports errors in the attached zone's NSEC3 chain.

What is the expected correct behavior?

No errors reported.