Skip to main content

7. Authoritative Server Considerations

7. Authoritative Server Considerations​

7.1. Zone Signing​

Zones using NSEC3 must satisfy the following properties:

  • Each owner name within the zone that owns authoritative RRSets

MUST have a corresponding NSEC3 RR. Owner names that correspond to unsigned delegations MAY have a corresponding NSEC3 RR. However, if there is not a corresponding NSEC3 RR, there MUST be an Opt-Out NSEC3 RR that covers the "next closer" name to the delegation. Other non-authoritative RRs are not represented by NSEC3 RRs.

  • Each empty non-terminal MUST have a corresponding NSEC3 RR, unless

the empty non-terminal is only derived from an insecure delegation covered by an Opt-Out NSEC3 RR.

  • The TTL value for any NSEC3 RR SHOULD be the same as the minimum

TTL value field in the zone SOA RR.

  • The Type Bit Maps field of every NSEC3 RR in a signed zone MUST

indicate the presence of all types present at the original owner name, except for the types solely contributed by an NSEC3 RR itself. Note that this means that the NSEC3 type itself will never be present in the Type Bit Maps.

The following steps describe a method of proper construction of NSEC3 RRs. This is not the only such possible method.

  1. Select the hash algorithm and the values for salt and iterations.

  2. For each unique original owner name in the zone add an NSEC3 RR.

  • If Opt-Out is being used, owner names of unsigned delegations MAY be excluded.

  • The owner name of the NSEC3 RR is the hash of the original owner name, prepended as a single label to the zone name.

  • The Next Hashed Owner Name field is left blank for the moment.

  • If Opt-Out is being used, set the Opt-Out bit to one.

  • For collision detection purposes, optionally keep track of the original owner name with the NSEC3 RR.

  • Additionally, for collision detection purposes, optionally create an additional NSEC3 RR corresponding to the original owner name with the asterisk label prepended (i.e., as if a wildcard existed as a child of this owner name) and keep track of this original owner name. Mark this NSEC3 RR as temporary.

  1. For each RRSet at the original owner name, set the corresponding bit in the Type Bit Maps field.

  2. If the difference in number of labels between the apex and the original owner name is greater than 1, additional NSEC3 RRs need to be added for every empty non-terminal between the apex and the original owner name. This process may generate NSEC3 RRs with duplicate hashed owner names. Optionally, for collision detection, track the original owner names of these NSEC3 RRs and create temporary NSEC3 RRs for wildcard collisions in a similar fashion to step 1.

  3. Sort the set of NSEC3 RRs into hash order.

  4. Combine NSEC3 RRs with identical hashed owner names by replacing them with a single NSEC3 RR with the Type Bit Maps field consisting of the union of the types represented by the set of NSEC3 RRs. If the original owner name was tracked, then collisions may be detected when combining, as all of the matching NSEC3 RRs should have the same original owner name. Discard any possible temporary NSEC3 RRs.

  5. In each NSEC3 RR, insert the next hashed owner name by using the value of the next NSEC3 RR in hash order. The next hashed owner name of the last NSEC3 RR in the zone contains the value of the hashed owner name of the first NSEC3 RR in the hash order.

  6. Finally, add an NSEC3PARAM RR with the same Hash Algorithm, Iterations, and Salt fields to the zone apex.

If a hash collision is detected, then a new salt has to be chosen, and the signing process restarted.

7.2. Zone Serving​

This specification modifies DNSSEC-enabled DNS responses generated by authoritative servers. In particular, it replaces the use of NSEC RRs in such responses with NSEC3 RRs.

In the following response cases, the NSEC RRs dictated by DNSSEC [RFC4035] are replaced with NSEC3 RRs that prove the same facts. Responses that would not contain NSEC RRs are unchanged by this specification.

When returning responses containing multiple NSEC3 RRs, all of the NSEC3 RRs MUST use the same hash algorithm, iteration, and salt values. The Flags field value MUST be either zero or one.

7.2.1. Closest Encloser Proof​

For many NSEC3 responses a proof of the closest encloser is required. This is a proof that some ancestor of the QNAME is the closest encloser of QNAME.

This proof consists of (up to) two different NSEC3 RRs:

  • An NSEC3 RR that matches the closest (provable) encloser.

  • An NSEC3 RR that covers the "next closer" name to the closest

encloser.

The first NSEC3 RR essentially proposes a possible closest encloser, and proves that the particular encloser does, in fact, exist. The second NSEC3 RR proves that the possible closest encloser is the closest, and proves that the QNAME (and any ancestors between QNAME and the closest encloser) does not exist.

These NSEC3 RRs are collectively referred to as the "closest encloser proof" in the subsequent descriptions.

For example, the closest encloser proof for the nonexistent "alpha.beta.gamma.example." owner name might prove that "gamma.example." is the closest encloser. This response would contain the NSEC3 RR that matches "gamma.example.", and would also contain the NSEC3 RR that covers "beta.gamma.example." (which is the "next closer" name).

It is possible, when using Opt-Out (Section 6), to not be able to prove the actual closest encloser because it is, or is part of an insecure delegation covered by an Opt-Out span. In this case, instead of proving the actual closest encloser, the closest provable encloser is used. That is, the closest enclosing authoritative name is used instead. In this case, the set of NSEC3 RRs used for this proof is referred to as the "closest provable encloser proof".

7.2.2. Name Error Responses​

To prove the nonexistence of QNAME, a closest encloser proof and an NSEC3 RR covering the (nonexistent) wildcard RR at the closest encloser MUST be included in the response. This collection of (up to) three NSEC3 RRs proves both that QNAME does not exist and that a wildcard that could have matched QNAME also does not exist.

For example, if "gamma.example." is the closest provable encloser to QNAME, then an NSEC3 RR covering "*.gamma.example." is included in the authority section of the response.

7.2.3. No Data Responses, QTYPE is not DS​

The server MUST include the NSEC3 RR that matches QNAME. This NSEC3 RR MUST NOT have the bits corresponding to either the QTYPE or CNAME set in its Type Bit Maps field.

7.2.4. No Data Responses, QTYPE is DS​

If there is an NSEC3 RR that matches QNAME, the server MUST return it in the response. The bits corresponding with DS and CNAME MUST NOT be set in the Type Bit Maps field of this NSEC3 RR.

If no NSEC3 RR matches QNAME, the server MUST return a closest provable encloser proof for QNAME. The NSEC3 RR that covers the "next closer" name MUST have the Opt-Out bit set (note that this is true by definition -- if the Opt-Out bit is not set, something has gone wrong).

If a server is authoritative for both sides of a zone cut at QNAME, the server MUST return the proof from the parent side of the zone cut.

7.2.5. Wildcard No Data Responses​

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. This combination proves both that QNAME itself does not exist and that a wildcard that matches QNAME does exist. Note that the closest encloser to QNAME MUST be the immediate ancestor of the wildcard RR (if this is not the case, then something has gone wrong).

7.2.6. Wildcard Answer Responses​

If there is a wildcard match for QNAME and QTYPE, then, in addition to the expanded wildcard RRSet returned in the answer section of the response, proof that the wildcard match was valid must be returned.

This proof is accomplished by proving that both QNAME does not exist and that the closest encloser of the QNAME and the immediate ancestor of the wildcard are the same (i.e., the correct wildcard matched).

To this end, the NSEC3 RR that covers the "next closer" name of the immediate ancestor of the wildcard MUST be returned. It is not necessary to return an NSEC3 RR that matches the closest encloser, as the existence of this closest encloser is proven by the presence of the expanded wildcard in the response.

7.2.7. Referrals to Unsigned Subzones​

If there is an NSEC3 RR that matches the delegation name, then that NSEC3 RR MUST be included in the response. The DS bit in the type bit maps of the NSEC3 RR MUST NOT be set.

If the zone is Opt-Out, then there may not be an NSEC3 RR corresponding to the delegation. In this case, the 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. (Note that this will be the case unless something has gone wrong).

7.2.8. Responding to Queries for NSEC3 Owner Names​

The owner names of NSEC3 RRs are not represented in the NSEC3 RR chain like other owner names. As a result, each NSEC3 owner name is covered by another NSEC3 RR, effectively negating the existence of the NSEC3 RR. This is a paradox, since the existence of an NSEC3 RR can be proven by its RRSIG RRSet.

If the following conditions are all true:

  • the QNAME equals the owner name of an existing NSEC3 RR, and

  • no RR types exist at the QNAME, nor at any descendant of QNAME,

then the response MUST be constructed as a Name Error response (Section 7.2.2). Or, in other words, the authoritative name server will act as if the owner name of the NSEC3 RR did not exist.

Note that NSEC3 RRs are returned as a result of an AXFR or IXFR query.

7.2.9. Server Response to a Run-Time Collision​

If the hash of a non-existing QNAME collides with the owner name of an existing NSEC3 RR, then the server will be unable to return a response that proves that QNAME does not exist. In this case, the server MUST return a response with an RCODE of 2 (server failure).

Note that with the hash algorithm specified in this document, SHA-1, such collisions are highly unlikely.

7.3. Secondary Servers​

Secondary servers (and perhaps other entities) need to reliably determine which NSEC3 parameters (i.e., hash, salt, and iterations) are present at every hashed owner name, in order to be able to choose an appropriate set of NSEC3 RRs for negative responses. This is indicated by an NSEC3PARAM RR present at the zone apex.

If there are multiple NSEC3PARAM RRs present, there are multiple valid NSEC3 chains present. The server must choose one of them, but may use any criteria to do so.

7.4. Zones Using Unknown Hash Algorithms​

Zones that are signed according to this specification, but are using an unrecognized NSEC3 hash algorithm value, cannot be effectively served. Such zones SHOULD be rejected when loading. Servers SHOULD respond with RCODE=2 (server failure) responses when handling queries that would fall under such zones.

7.5. Dynamic Update​

A zone signed using NSEC3 may accept dynamic updates [RFC2136]. However, NSEC3 introduces some special considerations for dynamic updates.

Adding and removing names in a zone MUST account for the creation or removal of empty non-terminals.

  • When removing a name with a corresponding NSEC3 RR, any NSEC3 RRs

corresponding to empty non-terminals created by that name MUST be removed. Note that more than one name may be asserting the existence of a particular empty non-terminal.

  • When adding a name that requires adding an NSEC3 RR, NSEC3 RRs

MUST also be added for any empty non-terminals that are created. That is, if there is not an existing NSEC3 RR matching an empty non-terminal, it must be created and added.

The presence of Opt-Out in a zone means that some additions or delegations of names will not require changes to the NSEC3 RRs in a zone.

  • When removing a delegation RRSet, if that delegation does not have

a matching NSEC3 RR, then it was opted out. In this case, nothing further needs to be done.

  • When adding a delegation RRSet, if the "next closer" name of the

delegation is covered by an existing Opt-Out NSEC3 RR, then the delegation MAY be added without modifying the NSEC3 RRs in the zone.

The presence of Opt-Out in a zone means that when adding or removing NSEC3 RRs, the value of the Opt-Out flag that should be set in new or modified NSEC3 RRs is ambiguous. Servers SHOULD follow this set of basic rules to resolve the ambiguity.

The central concept to these rules is that the state of the Opt-Out flag of the covering NSEC3 RR is preserved.

  • When removing an NSEC3 RR, the value of the Opt-Out flag for the

previous NSEC3 RR (the one whose next hashed owner name is modified) should not be changed.

  • When adding an NSEC3 RR, the value of the Opt-Out flag is set to

the value of the Opt-Out flag of the NSEC3 RR that previously covered the owner name of the NSEC3 RR. That is, the now previous NSEC3 RR.

If the zone in question is consistent with its use of the Opt-Out flag (that is, all NSEC3 RRs in the zone have the same value for the flag) then these rules will retain that consistency. If the zone is not consistent in the use of the flag (i.e., a partially Opt-Out zone), then these rules will not retain the same pattern of use of the Opt-Out flag.

For zones that partially use the Opt-Out flag, if there is a logical pattern for that use, the pattern could be maintained by using a local policy on the server.

Last updated on