pub struct NSEC3 {
// some fields omitted
}RFC 5155, NSEC3, March 2008
3. The NSEC3 Resource Record
The NSEC3 Resource Record (RR) provides authenticated denial of
existence for DNS Resource Record Sets.
The NSEC3 RR lists RR types present at the original owner name of the
NSEC3 RR. It includes the next hashed owner name in the hash order
of the zone. The complete set of NSEC3 RRs in a zone indicates which
RRSets exist for the original owner name of the RR and form a chain
of hashed owner names in the zone. This information is used to
provide authenticated denial of existence for DNS data. To provide
protection against zone enumeration, the owner names used in the
NSEC3 RR are cryptographic hashes of the original owner name
prepended as a single label to the name of the zone. The NSEC3 RR
indicates which hash function is used to construct the hash, which
salt is used, and how many iterations of the hash function are
performed over the original owner name. The hashing technique is
described fully in Section 5.
Hashed owner names of unsigned delegations may be excluded from the
chain. An NSEC3 RR whose span covers the hash of an owner name or
"next closer" name of an unsigned delegation is referred to as an
Opt-Out NSEC3 RR and is indicated by the presence of a flag.
The owner name for the NSEC3 RR is the base32 encoding of the hashed
owner name prepended as a single label to the name of the zone.
The type value for the NSEC3 RR is 50.
The NSEC3 RR RDATA format is class independent and is described
below.
The class MUST be the same as the class of the original owner name.
The NSEC3 RR SHOULD have the same TTL value as the SOA minimum TTL
field. This is in the spirit of negative caching [RFC2308].
3.2. NSEC3 RDATA Wire Format
The RDATA of the NSEC3 RR is as shown below:
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 /
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Hash Algorithm is a single octet.
Flags field is a single octet, the Opt-Out flag is the least
significant bit, as shown below:
0 1 2 3 4 5 6 7
+-+-+-+-+-+-+-+-+
| |O|
+-+-+-+-+-+-+-+-+
Iterations is represented as a 16-bit unsigned integer, with the most
significant bit first.
Salt Length is represented as an unsigned octet. Salt Length
represents the length of the Salt field in octets. If the value is
zero, the following Salt field is omitted.
Salt, if present, is encoded as a sequence of binary octets. The
length of this field is determined by the preceding Salt Length
field.
Hash Length is represented as an unsigned octet. Hash Length
represents the length of the Next Hashed Owner Name field in octets.
The next hashed owner name is not base32 encoded, unlike the owner
name of the NSEC3 RR. It is the unmodified binary hash value. It
does not include the name of the containing zone. The length of this
field is determined by the preceding Hash Length field.
Methods
RFC 5155, NSEC3, March 2008
3.1.1. Hash Algorithm
The Hash Algorithm field identifies the cryptographic hash algorithm
used to construct the hash-value.
The values for this field are defined in the NSEC3 hash algorithm
registry defined in Section 11.
RFC 5155, NSEC3, March 2008
3.1.2. Flags
The Flags field contains 8 one-bit flags that can be used to indicate
different processing. All undefined flags must be zero. The only
flag defined by this specification is the Opt-Out flag.
3.1.2.1. Opt-Out Flag
If the Opt-Out flag is set, the NSEC3 record covers zero or more
unsigned delegations.
If the Opt-Out flag is clear, the NSEC3 record covers zero unsigned
delegations.
The Opt-Out Flag indicates whether this NSEC3 RR may cover unsigned
delegations. It is the least significant bit in the Flags field.
See Section 6 for details about the use of this flag.
RFC 5155, NSEC3, March 2008
3.1.3. Iterations
The Iterations field defines the number of additional times the hash
function has been performed. More iterations result in greater
resiliency of the hash value against dictionary attacks, but at a
higher computational cost for both the server and resolver. See
Section 5 for details of the use of this field, and Section 10.3 for
limitations on the value.
RFC 5155, NSEC3, March 2008
3.1.5. Salt
The Salt field is appended to the original owner name before hashing
in order to defend against pre-calculated dictionary attacks. See
Section 5 for details on how the salt is used.
RFC 5155, NSEC3, March 2008
3.1.7. Next Hashed Owner Name
The Next Hashed Owner Name field contains the next hashed owner name
in hash order. This value is in binary format. Given the ordered
set of all hashed owner names, the Next Hashed Owner Name field
contains the hash of an owner name that immediately follows the owner
name of the given NSEC3 RR. The value of the Next Hashed Owner Name
field in the last NSEC3 RR in the zone is the same as the hashed
owner name of the first NSEC3 RR in the zone in hash order. Note
that, unlike the owner name of the NSEC3 RR, the value of this field
does not contain the appended zone name.
RFC 5155, NSEC3, March 2008
3.1.8. Type Bit Maps
The Type Bit Maps field identifies the RRSet types that exist at the
original owner name of the NSEC3 RR.
Trait Implementations
Derived Implementations