The NSEC resource record (RFC 4034 section 4) — the building block of authenticated denial of existence: a Domain naming the next existing owner in the zone's canonical order, plus an NsecTypes bitmap of RR types present at the proving name.

The next-owner-name field is not subject to wire-form name compression (RFC 3597 section 4) and is not lower-cased when computing canonical wire form (RFC 6840 section 5.1).

See T_nsec3 for the hashed-name variant.

The NSEC3 resource record (RFC 5155 section 3.2) — the hashed denial-of-existence variant. The next-owner-name field carries the hashed equivalent rather than the plain name, and the record itself includes the hashing parameters (algorithm, flags, iteration count, salt) needed to reproduce the hash. The trailing NsecTypes bitmap names the RR types present at the proving (un-hashed) name.

                     1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 2 3 3
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|   Hash Alg.   |     Flags     |          Iterations           |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|  Salt Length  |                     Salt                      /
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|  Hash Length  |             Next Hashed Owner Name            /
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
/                         Type Bit Maps                         /
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

The Ord instance compares the fields in wire-encoding order, using dnsTextCmp on the length-prefixed salt and hashed-name bytes, so it agrees with the canonical RR-content ordering of RFC 4034 section 6.2.

See T_nsec for the un-hashed variant and T_nsec3param for the zone-apex parameter record.

The NSEC3PARAM resource record (RFC 5155 section 4.2) — a zone-apex record describing the NSEC3 hashing parameters (algorithm, iteration count, salt) in use across the zone's NSEC3 chain. Validating resolvers do not consult this record (each T_nsec3 carries its own parameters in the RDATA); it exists for authoritative-server tooling.

                     1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 2 3 3
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|   Hash Alg.   |     Flags     |          Iterations           |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|  Salt Length  |                     Salt                      /
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

(Editorial: the salt and iteration count were largely a bad idea in retrospect; best practice for zone signers is to set the salt empty and the iteration count to zero.)

See T_nsec3 for the records produced under these parameters.

Abstract representation of a set of RRTYPE codepoints, stored as the window-based wire-format bitmap from RFC 4034 section 4.1.2. Used by T_nsec, T_nsec3, and T_csync to carry the set of types present at the owner name.

An NsecTypes may legitimately be empty -- this is the expected encoding for an NSEC3 empty-non-terminal. With NSEC, the type bitmap is expected to include at least the NSEC type itself; that invariant is not enforced by the type.

Construction and enumeration go through IsList:

• fromList tys :: NsecTypes builds the bitmap from a list of RRTYPE values; duplicates are merged and the wire-form ordering is canonical regardless of input order. Under OverloadedLists the same input shape is just [A, AAAA, MX].
• toList bm :: [RRTYPE] enumerates the contained types in ascending wire-form order.
• (<>) unions two bitmaps; mempty is the empty bitmap.

For membership without enumerating the whole set, use hasRRtype, which goes directly to the relevant window, block and bit offset.

Construct the per-window bitmaps from a list of types.

Convert NsecTypes bitmap to an RRTYPE list

Efficient NSEC/NSEC3 type bitmap membership predicate.

The NXT resource record (RFC 2535 section 5.2) — the obsolete predecessor of T_nsec, defined here for compatibility with archival DNSSEC zone data. Same conceptual shape as NSEC (next owner name + type bitmap) but with a different type-bitmap encoding.

                     1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 2 3 3
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                  next domain name                             /
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                    type bit map                               /
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

The domain name is wire-form name-compressed on decode only (RFC 3597 section 4) and canonicalises to lower case (RFC 4034 section 6.2). The Eq and Ord instances compare the domain field in canonical wire form (via equalWireHost / compareWireHost) and the type bitmap byte-wise.

See T_nsec for the modern replacement.

An RRtype representable in an NXT RR bitmap.

An error if any of input RRtypes are above 127.

Construct the bitmap from a non-empty list of types.

Reconstruct RRTYPE list from bitmap.

Efficient NXT type bitmap membership predicate.