Can the NSEC3-OPTOUT record cover no RRTYPE’s?

At first glance, the answer seems obvious: No. The point of NSEC3 is to proof the (non)existence of data. With the OPT-OUT flag set, you skip all the non-secure data. So you would expect to have some data to cover for such an NSEC3 record. If you read RFC 5155 Section 3.2.1 it is not entirely clear, though I’m tempted to think these should not happen in the wild. Except we just found one, generated by bind’s dnssec-signzone:  IN NS foo.  IN NS foo.  IN DS blob.  IN NS foo.

The change was that “” submitted a DS record which was added to the zone. Note also that  neither “” or “” are zone cuts, although there are many delegations underneath (but none with a DS record or orphan glue)

This caused bind to add two NSEC3 entries as part of the NSEC3 chain, an entry for HASH( and an entry for HASH( (forgive the wordpress wrapping of lines)   3600 IN      NSEC3   1 1 5 – qnkecttopnji0h479fhpjmv18gsl1sdk ;{ flags: optout}   3600    IN      NSEC3   1 1 5 – r85l4g712aibs65e47aj79e7odi202h9 ;{ flags: optout}

Note how these NSEC3 entries do not cover a single RRTYPE, because there is no zonecut and there are no RRTYPE’s for these entries.

When signing this zone with opendnssec, instead of bind, the entries are not added. Who is right? Before using my brains, I decided to use other people’s brains.

named-checkzone loaded both the bind and ods version with “OK”. So no help there. It’s a bug because it should declare at least one of the copies as containing errors in the NSEC3 hash chain

ldns-verify complained about ALL the non-zone-cuts in the zones but otherwise showed no difference. So that’s also a failure, on top of the failure of assuming dots are zone cuts.

validns found the bind zone OK, but complained about the ods zone with:

ca.signed.ods-signer-01.ldns:2898958: no corresponding NSEC3 found for
ca.signed.ods-signer-01.ldns:2907968: no corresponding NSEC3 found for

So validns seems to agree with bind. Which software is right? The only thing I”m sure of now, is that I need more coffee and time to re-read RFC 5155, and specifically look at how things are supposed to work in this case.

I’m continuously surprised at how many TLD’s have rolled out DNSSEC, yet we’re still seeing differences between signer engines and validators all the time……


One thought on “Can the NSEC3-OPTOUT record cover no RRTYPE’s?

  1. The short answer is yes.

    The long answer is yes, a NSEC3-OPTOUT record can cover no RRTYPEs. Before adding the DS record for, there were only insecure delegations below According to RFC5155, Section 7.1, bullet 2, those domains do not require a NSEC3 when using Opt-Out. But if you add the DS record, suddenly the empty non-terminals and are derived for a secure delegation. The NSEC3 records need to be created and they have a empty bitmap (since they belong to an empty non-terminal).

    Why are those needed? They tell the resolver the closest encloser for Those are needed to deny that there was wildcard expansion possible.

    Suppose the above zone also has a *.ca. configured (regardless whether that might be a good idea or not). If we didn’t add NSEC3s for the empty non-terminals, the resolver thinks ca. is the closest encloser and a query for could be expanded by the wildcard *.ca. That seems like something we don’t want.

    More background information is provided here:

    By the way, bind and validns are right here. So is OpenDNSSEC 1.3 LTS, it is doing it correct. The bug is in the 1.4 beta. And I’ll get to it tomorrow first thing in the morning.

Leave a Reply

Your email address will not be published. Required fields are marked *