Skip to main content

8. Validator Considerations

8. Validator Considerations​

8.1. Responses with Unknown Hash Types​

A validator MUST ignore NSEC3 RRs with unknown hash types. The practical result of this is that responses containing only such NSEC3 RRs will generally be considered bogus.

8.2. Verifying NSEC3 RRs​

A validator MUST ignore NSEC3 RRs with a Flag fields value other than zero or one.

A validator MAY treat a response as bogus if the response contains NSEC3 RRs that contain different values for hash algorithm, iterations, or salt from each other for that zone.

8.3. Closest Encloser Proof​

In order to verify a closest encloser proof, the validator MUST find the longest name, X, such that

  • X is an ancestor of QNAME that is matched by an NSEC3 RR present

in the response. This is a candidate for the closest encloser, and

  • The name one label longer than X (but still an ancestor of -- or

equal to -- QNAME) is covered by an NSEC3 RR present in the response.

One possible algorithm for verifying this proof is as follows:

  1. Set SNAME=QNAME. Clear the flag.

  2. Check whether SNAME exists:

  • If there is no NSEC3 RR in the response that matches SNAME (i.e., an NSEC3 RR whose owner name is the same as the hash of SNAME, prepended as a single label to the zone name), clear the flag.

  • If there is an NSEC3 RR in the response that covers SNAME, set the flag.

  • If there is a matching NSEC3 RR in the response and the flag was set, then the proof is complete, and SNAME is the closest encloser.

  • If there is a matching NSEC3 RR in the response, but the flag is not set, then the response is bogus.

  1. Truncate SNAME by one label from the left, go to step 2.

Once the closest encloser has been discovered, the validator MUST check that the NSEC3 RR that has the closest encloser as the original owner name is from the proper zone. The DNAME type bit must not be set and the NS type bit may only be set if the SOA type bit is set. If this is not the case, it would be an indication that an attacker is using them to falsely deny the existence of RRs for which the server is not authoritative.

In the following descriptions, the phrase "a closest (provable) encloser proof for X" means that the algorithm above (or an equivalent algorithm) proves that X does not exist by proving that an ancestor of X is its closest encloser.

8.4. Validating Name Error Responses​

A validator MUST verify that there is a closest encloser proof for QNAME present in the response and that there is an NSEC3 RR that covers the wildcard at the closest encloser (i.e., the name formed by prepending the asterisk label to the closest encloser).

8.5. Validating No Data Responses, QTYPE is not DS​

The validator MUST verify that an NSEC3 RR that matches QNAME is present and that both the QTYPE and the CNAME type are not set in its Type Bit Maps field.

Note that this test also covers the case where the NSEC3 RR exists because it corresponds to an empty non-terminal, in which case the NSEC3 RR will have an empty Type Bit Maps field.

8.6. Validating No Data Responses, QTYPE is DS​

If there is an NSEC3 RR that matches QNAME present in the response, then that NSEC3 RR MUST NOT have the bits corresponding to DS and CNAME set in its Type Bit Maps field.

If there is no such NSEC3 RR, then the validator MUST verify that a closest provable encloser proof for QNAME is present in the response, and that the NSEC3 RR that covers the "next closer" name has the Opt- Out bit set.

8.7. Validating Wildcard No Data Responses​

The validator MUST verify a closest encloser proof for QNAME and MUST find an NSEC3 RR present in the response that matches the wildcard name generated by prepending the asterisk label to the closest encloser. Furthermore, the bits corresponding to both QTYPE and CNAME MUST NOT be set in the wildcard matching NSEC3 RR.

8.8. Validating Wildcard Answer Responses​

The verified wildcard answer RRSet in the response provides the validator with a (candidate) closest encloser for QNAME. This closest encloser is the immediate ancestor to the generating wildcard.

Validators MUST verify that there is an NSEC3 RR that covers the "next closer" name to QNAME present in the response. This proves that QNAME itself did not exist and that the correct wildcard was used to generate the response.

8.9. Validating Referrals to Unsigned Subzones​

The delegation name in a referral is the owner name of the NS RRSet present in the authority section of the referral response.

If there is an NSEC3 RR present in the response that matches the delegation name, then the validator MUST ensure that the NS bit is set and that the DS bit is not set in the Type Bit Maps field of the NSEC3 RR. The validator MUST also ensure that the NSEC3 RR is from the correct (i.e., parent) zone. This is done by ensuring that the SOA bit is not set in the Type Bit Maps field of this NSEC3 RR.

Note that the presence of an NS bit implies the absence of a DNAME bit, so there is no need to check for the DNAME bit in the Type Bit Maps field of the NSEC3 RR.

If there is no NSEC3 RR present that matches the delegation name, then the validator MUST verify a closest provable encloser proof for the delegation name. The validator MUST verify that the Opt-Out bit is set in the NSEC3 RR that covers the "next closer" name to the delegation name.

Last updated on