Hi Petr On Thu, Oct 01, 2026 at 12:43:11PM +0200, Petr Špaček wrote: > Hello. > > Is CSYNC/NSEC with an empty type bitmap: > a) syntactically valid record > b) should it trigger FORMERR (= whole message ignored)
From the RFCs:
For NSEC, RFC 4034 section 4.1.2:
> Type Bit Maps Field = ( Window Block # | Bitmap Length | Bitmap )+
Where the + denotes at least one in the grammar. The later text also
states it: "Blocks with no types present MUST NOT be included."
For CSYNC, RFC 7477 section 2.1.1.2.1:
> The Type Bit Map field is encoded in the same way as the Type Bit Map
> field of the NSEC record, described in [RFC4034], Section 4.1.2.
For NSEC3, RFC 5155 intitially had the same grammar as NSEC above, but
RFC 6840 allowed it in section 6.4:
> An NSEC3 record that matches an Empty Non-Terminal effectively has no
> type associated with it. This NSEC3 record has an empty type bit
> map. Section 3.2.1 of [RFC5155] contains the statement:
>
> Blocks with no types present MUST NOT be included.
>
> However, the same section contains a regular expression:
>
> Type Bit Maps Field = ( Window Block # | Bitmap Length | Bitmap )+
>
> The plus sign in the regular expression indicates that there is one
> or more of the preceding element. This means that there must be at
> least one window block. If this window block has no types, it
> contradicts with the first statement. Therefore, the correct text in
> Section 3.2.1 of [RFC5155] should be:
>
> Type Bit Maps Field = ( Window Block # | Bitmap Length | Bitmap )*
That's specific to NSEC3.
Mukund
signature.asc
Description: PGP signature
_______________________________________________ DNSOP mailing list -- [email protected] To unsubscribe send an email to [email protected]
