wiki:Rfc5155DetailedRequirements

RFC 5155

The use of the NSEC3 resource record to provide authenticated denial of existence is described in this RFC. The alternative NSEC RR denies the existence of a name by providing information on two owner names and asserting that the zone contains no name between them. The NSEC3 RR essentially does the same, but to avoid providing the capability to enumerate the zone, uses hashes of names. It also include an "opt-out" feature to reduce the number of signatures in zones that have a lot of unsigned delegations.

This document is a breakdown of the RFC and itemises the requirements detailed in that RFC. Each requiement has the following information:

  • The number of the requirement. (This is the location within the document of the requirement in the form section/paragraph/sequence. The optional /paragraph is the number of the paragraph in the section and the /sequence (also optional) distinguishes multiple requirements in the same paragraph.
  • The requirement itself.
  • Whether BIND 10 implements the requirement.
  • Any qualifications or notes.

General Requirements of the Authoritative Server

The following set of requirements cover the general capabilities of the authoritative server:

Number Requirement Implemented Notes
General
2/3/a Must support algorithm DSA through algorithm identifier DSA-NSEC3-SHA1
2/3/b Must support algorithm RSASHA1 through algorithm identifier DSA-NSEC3-RSASHA1
7.4 Zones signed with an unrecognised NSEC3 hash algorithm should be rejected on loading.
10.3/4 The server should not load a zone with an "iterations" value more than that specified for the key size as given in the table in RFC 5155 section 10.3.
NSEC3 RRs
3/7 The class of NSEC3 RR must be same as class of owner name
3/8 The TTL of an NSEC3 RR should have same TTL as SOA minimum TTL field Also mentioned in 7.1/4
2.3 Must understand the NSEC3 record wire data format
3.2 Must support special cases in NSEC3 record:
* In the type bitmaps field, bit 0 of window block 0 must be set to 0.
* Bits representing meta-types or qtypes (as in RFC 2929 section 3.1) must be set to 0.
* Blocks with no types present must not be included in the type bitmap field.
* Trailing zero octets in the type bitmap must be excluded.
* The type field should not include an entry for the NSEC3 RR.
Also mentioned in 7.1/5.
3.3 Where relevant, the server must recognise the presentation format of NSEC3
NSEC3PARAM RRs
4 Must recognise the NSEC3PARAM RR
4/2/a The NSEC3PARAM RR should only exist at the apex of the zone Note - it not prohibited to have an NSEC3PARAM RR at another location, but it is ignored if it is.
4/2/b If the flags field in the NSEC3PARAM RR is 0, there must be an NSEC3 RR (with the same algorithm, iteration and salt) present at every hashed owner name in the zone.
4/6 The class of an NSEC3PARAM record must be the same as the NSEC3 RRs to which it refers.
4.1.2/a The flags field of an NSEC3PARAM RR must be zero.
4.1.2/b When interpreting an NSEC3PARAM RR, the flags field must be assumed to be zero, with non-zero values being ignored.
4.2 Must understand the NSEC3PARAM record wire data format
4.3 Where relevant, the server must recognise the presentation format of NSEC3PARAM RR
General Processing
5 Must be able to calculate the hash of an RR as described in section 5 of RFC 5155
Opt-Out
6/4 If opt-out is enabled, must be able to support the presence of NSEC3 RRs where not strictly needed.
6/5 Must be able to support mixture of opt-out and non opt-out NSRC3 RRs in a zone
Serving Zones
7.2/3/a All NSEC3 RRs returned in a response must have the same algorithm, iteration and salt value.
7.2/3/b All NSEC3 RRs returned in a response must have a flags field set to 0 or 1.

Inclusion of NSEC3 Records in Responses from Authoritative Server

The following requirements cover the possible responses that the server can return that include NSEC3 records. The number of NSEC3 records returned depends on QNAME and type of response. Up to two of these RRs are determined by the "closest encloser" proof described in section 7.2.1 of RFC 5155. This is stated as a requirement and as a component of other responses where needed.

Number Requirement Implemented Notes
7.2.1 The server should be capable of creating NSEC3 RRs that prove the existent of the "closest encloser" (or "closest provable encloser").
7.2.2 If the QNAME does not exist, the server should return a "closest encloser proof" for the name and an NSEC3 RR for the (non-existent) wildcard RR at the closest encloser.
7.2.3 If the QNAME exists but the QTYPE does not (and the QTYPE is not DS), the server should return a single NSEC3 record that matches the QNAME. The returned NSEC3 RR must not have bits for either the QTYPE or CNAME set in the type bit map field. (The QTYPE bit is set implies that the requested data was present. The CNAME bit set implies that the query should have followed the CNAME.)
7.2.4/1 If the QNAME exists but the QTYPE does not (and the QTYPE is DS) and there is an NSEC3 that matches the QNAME the server must return it. * The returned NSEC3 RR must not have bits for either the QTYPE or CNAME set in the type bit map field. (The QTYPE bit is set implies that the requested data was present. The CNAME bit set implies that the query should have followed the CNAME.)
* If the server is authoritative for both sides of a zone cut at QNAME, the server must return the proof from the parent side.
7.2.4/2 If the QNAME exists but the QTYPE does not (and the QTYPE is DS) and there is no NSEC3 that matches the QNAME the server must return the "closest provable encloser" proof for the QNAME * The returned NSEC3 RR must not have bits for either the QTYPE or CNAME set in the type bit map field. (The QTYPE bit is set implies that the requested data was present. The CNAME bit set implies that the query should have followed the CNAME.) In addition, the NSEC3 RR that covers the "next closer" name must have the Opt-out bit set.
* If the server is authoritative for both sides of a zone cut at QNAME, the server must return the proof from the parent side.
7.2.5 If there is a wildcard match for QNAME, but QTYPE is not present at that name, the response must include a closest encloser proof for QNAME and must include the NSEC3 RR that matches the wildcard. * Proves that neither QNAME nor a wildcard that matches QNAME exists.
* The closest ancestor to QNAME must be the immediate ancestor of the wildcard RR.
7.2.6 If there is a wilcard match for the QNAME/QTYPE combination, the NSEC3 RR that covers the "next closer" name of the immediate ancestor of the wildcard must be returned. This proves that QNAME does not exist and that the closest encloser of QNAME and the immediate ancestor of the wildcard are the same. It is not necessary to return an NSEC3 RR that matches the "closest encloser" as this is proven by the presence of the expanded wildcard in the response.
7.2.7/1 If a query is for an unsigned subzone and there is an NSEC3 RR that matches the delegation name, the RR must be included in response. The DS bit in the Type Bit Maps field must not be set, as it would imply that the subzone were a signed zone.
7.2.7/2 If a query is for an unsigned subzone and there is no NSEC3 RR that matches the delegation name and the zone is opt-out, a closest provable encloser proof must be included in the response. The included NSEC3 RR that covers the "next closer" name for the delegation must have the Opt-Out flag set to one. The opt-out flag set to 1 will be the case unless something has gone wrong. So the server should not set this flag, but report as an error any occurrence where this is not the case.
7.2.8 If a query is received for an NSEC3 RR (i.e. QNAME is the same as the name of an NSEC3 RR) and there are no other RRs at that QNAME or descendents of the QNAME, the server must return an NXDOMAIN response. This is because the owner names of the NSEC3 RRs are not included in the NSEC3 chain, so each is covered by another NSEC3 record effectively disproving its existence.
7.2.9 If the hash of a non-existing QNAME is the same as the owner name of an existing RR, the server return a server failure error.
7.3 If there are multiple NSEC3PARAM RRs present at the apex of the zone, there are multiple NSEC3 chains present. The server must use one chain for its responses, but may use any criteria as to which chain to use.

Requirements on the Resolver

The following requirements cover the interpretation of NSEC3 records by the resolver.

Just as the authoritative server needs to be able to understand and extract the records to form a "closest encloser" proof, so the resolver must be able to verify a "closest encloser" proof. An algorithm for verifying the proof given in RFC 5155 section 8.3.

Number Requirement Implemented Notes
General
8.3 The resolver must be able to validate "closest encloser" proofs
NSEC3 RRs
3.2 Must understand NSEC3 record
8.2 Must ignore NSEC3 RRs with unknown hash types Only DSA-NSEC3-SHA1 and DSA-NSEC3-RSASHA1 are recognised.
8.3 Must ignore NSEC3 RRs with a flags field value other than 0 or 1
Validation Process
8.4 If an "Name Error" response is received, the resolver must validate the associated "closest encloser" proof and that there is an NSEC3 RR for the wildcard at the closest encloser.
8.5/1 If a "No Data" response is received and the QTYPE is not DS, the resolver must validate that the NSEC3 RR matches the QNAME and that neither the QTYPE nor CNAME bits are set in the Type Bit Maps field.
8.6/1 If a "No Data" response is received and the QTYPE is DS and there is an NSEC3RR that matches the QNAME, the resolver must validate that the NSEC3 RR matches the QNAME and that neither the DS nor CNAME bits are set in the Type Bit Maps field.
8.6/2/a If a "No Data" response is received and the QTYPE is DS and there is not an NSEC3 RR that matches the QNAME, the resolver must validate that:
* there is a "closest provable encloser" proof in the response.
* the NSEC3 RR that covers the "next closer" name has the Opt-Out bit set.
8.7 If a "No Data" response is received and the QNAME is a wildcard, the resolver must validate:
* verify the closest encloser proof.
* validate that the response contains an NSEC3 RR matching the wildcard name generated by prepending the asterisk label to the closest encloser.
* the bits corresponding to the QTYPE and to CNAME are not set in the wildcard matching NSEC3 RR.
8.8/2 If a wildcard answer is received, the resolver must verify that there is an NSEC3 RR that covers the "next closer" name to QNAME present in the response.
8.9/2 If a referral is received and there is an NSEC3 RR that matches the delegation name (owner name of the NS RRset in the authority section of the response), the validator must check:
* NS bit is set and the DS bit is not set in the Type Bit Maps field.
* The NSEC3 RR is from the parent zone (i.e. that the SOA bit is not set in the type bits maps field)
8.9/4 If a referral is received and there is no NSEC3 RR that matches the delegation name (owner name of the NS RRset in the authority section of the response), the validator must:
* verify the "closest provable encloser" proof for the name.
* Verify that the "Opt-Out" bit is set in the NSEC3 RR that covers the "next closer" name to the delegation name.
9.2 The AD bit must not be set when returning a response containing a closest (provable) encloser proof in which the NSEC3 RR that covers the "next closer" name has the Opt-Out bit set.
10.3/4 The resolver may consider NSEC3 RRs with an "iterations" value more than that specified for the key size as given in the table in RFC 5155 section 10.3 as insecure.
Last modified 6 years ago Last modified on Nov 16, 2011, 4:47:03 PM