The Domain Name System Security (DNSSEC) Extensions introduced the NSEC resource record for authenticated denial of existence, and the NSEC3 resource record for hashed authenticated denial of existence. This document introduces an alternative resource record, NSEC4, which similarly provides authenticated denial of existence. It permits gradual expansion of delegation-centric zones, just like NSEC3 does. With NSEC4 it is possible, but not required, to provide measures against zone enumeration.
NSEC4 reduces the size of the denial of existence response and adds Opt-Out to unhashed names. NSEC4 unifies NSEC and NSEC3.
Hashed authenticated denial of existence proofs hinge on the closest encloser proof (Section 7.2.1 and 8.3 of ). When validating a hashed denial of existence response, a validator must deny or assert the presence of a next closer name and a wildcard name. A validator can derive these names from the closest encloser.
This is why most of the denial of existence responses with NSEC3 contain three records:
- A record which matches the closest encloser, this tells the validator what the (unhashed) name of the closest encloser is;
- A record which covers or matches the next closer, to deny or assert the existence of the next closer name. The validator needs to know the closest encloser to construct the next closer name;
- A record which covers or matches the wildcard, to deny or assert wildcard synthesis. The validator needs to know the closest encloser to construct the source of synthesis.
This document presents a new record, NSEC4, that is similar to NSEC3, but differs in the following ways:
- It provides a new way to deny the existence of the wildcard, by introducing the Wildcard flag (described in ). This bit makes the third record, from the list above, redundant;
- It allows for unhashed records, by introducing an Identity function (described in ).
With NSEC4 you will need a maximum of two records for any denial of existence response, saving one record and accompanying signature(s) compared to NSEC3.
By defining an Identity function, we also fold back NSEC into NSEC4 and add Opt-out to unhashed names. With this change we collapse NSEC and NSEC3 into one new record to leave only one form of authenticated denial of existence in the DNS.
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in .
The reader is assumed to be familiar with the basic DNS and DNSSEC concepts described in , , , , , and subsequent RFCs that update them: , , and .
Furthermore, the same terminology is used throughout this document as is described in Section 1.3 from , with the following changes:
Original owner name:
: the owner name corresponding to a hashed owner name if hashing is used. Or the owner name as-is if no hashing is used.
Opt-Out NSEC4 RR:
: an NSEC4 RR that has the Opt-Out flag set to 1.
Wildcard NSEC4 RR:
: an NSEC4 RR that has the Wildcard flag set to 1.
Opt-Out zone:
: a zone with at least one Opt-Out NSEC4 RR.
Base32:
: the "Base 32 Encoding with Extended Hex Alphabet" as specified in . Note that trailing padding characters ("=") are not used in the NSEC4 specification.
To cover:
: an NSEC4 RR is said to "cover" a name if the (hashed) name or (hashed) next closer name falls between the owner name of the NSEC4 RR and the next (hashed) owner name of the NSEC4. In other words, if it proves the nonexistence of the name, either directly or by proving the nonexistence of an ancestor of the name.
To match:
: When a hash algorithm is defined, an NSEC4 RR is said to "match" a name if the owner name of the NSEC4 RR is the same as the hashed owner name of that name. When no hash algorithm (Identity function) is defined, an NSEC4 RR is said to "match" a name if the name and the owner name of the NSEC4 RR are equal.
Identity function:
: Perform no hashing. Leave the name as-is.
This document describes an EXPERIMENTAL extension to DNSSEC. It interoperates with non-experimental DNSSEC using the technique described in . This experiment is identified with the following private algorithm (using algorithm PRIVATEDNS):
- Algorithm "5.nsec4.nlnetlabs.nl.", is an alias for algorithm 5, RSASHA1.
Servers wishing to sign and serve zones that utilize NSEC4 MUST sign the zone with this private algorithm and MUST NOT use any other algorithms.
Resolvers MUST NOT apply NSEC4 validation described in this document unless a response contains RRSIGs created with this private algorithm.
The NSEC4 RR provides authenticated denial of existence for DNS RRsets.
The NSEC4 RR lists RR types present at the original owner name of the NSEC4 RR. It includes the next (hashed) owner name in the canonical order of the zone. The complete set of NSEC4 RRs in a zone indicates which RRSets exist for the original owner name of the RR and form a chain. 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 NSEC4 RR can be cryptographic hashes of the original owner name prepended as a single label to the name of the zone. The NSEC4 RR indicates which hash function (if any) 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 the same as with NSEC3 and is described in Section 5 of . NSEC3 creates hashes for empty non-terminals, NSEC4 does the same, even when the Identity function is in use.
(Hashed) owner names of unsigned delegations may be excluded from the chain. An NSEC4 RR whose span covers an owner name or next closer name of an unsigned delegation is referred to as an Opt-Out NSEC4 RR and is indicated by the presence of a flag.
If hashing is in use, the owner name for the NSEC4 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 NSEC4 RR is [TBD].
The NSEC4 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 NSEC4 RR SHOULD have the same TTL value as the SOA minimum TTL field. This is in the spirit of negative caching .
The NSEC4 RDATA has many similarities with the NSEC3 RDATA, but there are differences:
- There is an extra flag bit reserved to indicate whether wildcard synthesis is possible (e.g. does a wildcard domain name exist that is immediately descending from the original owner name?);
- The hash length does not need to be stored, as all domain names are stored as domain names, not raw hashes. [MG: this limits the hash to 63 octects..]
[MM: Hash length is one byte. In general, NSEC3 is used in TLD zones. Those domain names are relatively short (on average 3 characters (5 bytes wireformat), so in that case NSEC3 RRs become 4 bytes longer.]
defines the NSEC3 hash algorithm registry. Hash algorithm 0 is reserved. For NSEC4 we define hash algorithm 0 to be the Identity function, meaning that no hashing is used.
The Flags field is identical to the Flags field as defined in . This specification adds a new flag, the Wildcard Flag.
Like the Opt-Out Flag defined in Section 3.1.2.1 of .
The Wildcard Flag indicates whether there is wildcard synthesis possible (e.g. does a wildcard domain name exist that is immediately descending from the original owner name of the NSEC4?).
If the Wildcard flag is set, wildcard synthesis is possible.
If the Wildcard flag is clear, wildcard synthesis is not possible.
Like the Iterations field defined in Section 3.1.3 of .
Like the Salt Length field defined in Section 3.1.4 of .
Like the Salt field defined in Section 3.1.5 of .
The Next Owner Name field contains the next owner name that exists in the definition of Section 2.2.3 of .
The field contains the next owner name in the canonical ordering of the zone, as explained in Section 6.1 of .
A sender MUST NOT use DNS name compression on the Next Owner Name field when transmitting an NSEC4 RR.
Owner names of RRsets for which the given zone is not authoritative (such as glue records) MUST NOT be listed in the Next Owner Name, unless at least one authoritative RRset exists at the same owner name.
Like the Type Bit Maps field defined in Section 3.1.8 of .
The RDATA of the NSEC4 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 /
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
/ Next (Hashed) Owner Name /
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
/ Type Bit Maps /
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
^[fig:nsec4-wire::The NSEC4 on-the-wire format.]
Hash Algorithm is a single octet. If Hash Algorithm is zero (Identity function), the Iterations field, the Salt Length field and the Salt field MUST be ignored.
Flags field is a single octet. The following one-bit flags are defined:
0 1 2 3 4 5 6 7
+-+-+-+-+-+-+-+-+
| |W|O|
+-+-+-+-+-+-+-+-+
- O - Opt-Out flag
- W - Wildcard flag
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.
If Hash Algorithm is not zero, the Next (Hashed) Owner Name is a base32 encoded domain name of the hashed next owner name prepended as a single label to the name of the zone. If Hash Algorithm is zero it is a plain domain name.
The Type Bit Maps encode the existing types at the original owner name that matches the NSEC4 RR.
The encoding of the Type Bit Maps field is the same as that used by the NSEC and NSEC3 RR, described in , as well as in .
The presentation format of the RDATA portion is as follows:
-
The Hash Algorithm field is represented as an unsigned decimal integer. The value has a maximum of 255.
-
The Flags field is represented as an unsigned decimal integer. The value has a maximum of 255.
-
The Iterations field is represented as an unsigned decimal integer. The value is between 0 and 65535, inclusive.
-
The Salt Length field is not represented.
-
The Salt field is represented as a sequence of case-insensitive hexadecimal digits. Whitespace is not allowed within the sequence. The Salt field is represented as "-" (without the quotes) when the Salt Length field has a value of 0.
-
The Next (Hashed) Owner Name field is represented as a domain name.
-
The Type Bit Maps field is represented as a sequence of RR type mnemonics. When the mnemonic is not known, the TYPE representation as described in Section 5 of MUST be used.
NSEC record:
example. NSEC a.example NS SOA RRSIG DNSKEY NSEC
The same data shown as an NSEC3 record:
3msev9usmd4br9s97v51r2tdvmr9iqo1.example. NSEC3 1 0 0 - (
6cd522290vma0nr8lqu1ivtcofj94rga
NS SOA RRSIG DNSKEY NSEC3PARAM )
As an NSEC4 record with Identity function:
example. NSEC4 0 0 0 - a.example. NS SOA RRSIG DNSKEY NSEC4 NSEC4PARAM
And as an NSEC4 record with SHA1 hashing:
3msev9usmd4br9s97v51r2tdvmr9iqo1.example. NSEC4 1 0 0 - (
6cd522290vma0nr8lqu1ivtcofj94rga.example.
NS SOA RRSIG DNSKEY NSEC4PARAM )
Exactly like NSEC3PARAM described in Section 5 of , except the type code used [TBD] is that of NSEC4PARAM.
This specification adds Opt-Out as described in Section 6 of . Because of the Identity function, this allows for Opt-Out being used with unhashed names. A similar method is described in , but with NSEC4 we can reuse the Opt-Out bit from the Flags field.
With NSEC3, every empty non-terminal will have a NSEC3 record. This is mentioned in , for instance in section 7.1, the second bullet point:
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.
This is a crucial difference with respect to NSEC, where no such provision exists.
With NSEC4 we unify NSEC and NSEC3 and consequently, each empty non-terminal will get an NSEC4 record (see , the 6th bullet). Furthermore, NSEC4 represents the next owner name as a domain name, like NSEC, while NSEC3 represents the next name as an unmodified binary hash value.
Due to these changes, we can revert back to canonical ordering for NSEC4. This greatly simplifies the comparison code, because there is only one ordering mechanism.
Zones using NSEC4 must satisfy the same properties as described in Section 7.1 of , with NSEC3 replaced by NSEC4.
In addition, for each original owner name that has a wildcard domain name immediately descending from the original owner name, the corresponding NSEC4 RR MUST have the Wildcard bit set in the Flags field.
The following steps describe one possible method of proper construction of NSEC4 RRs.
-
Select the hash algorithm and the values for salt and iterations;
-
For each unique original owner name in the zone add an NSEC4 RR;
- If Opt-Out is being used, owner names of unsigned delegations MAY be excluded;
- The owner name of the NSEC4 RR is either the hash of the original owner name, prepended as a single label to the zone name, or is equal to the original owner name if Identity function is used;
- The Next 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, if hashing is used, optionally keep track of the original owner name with the NSEC4 RR. Create an additional NSEC4 RR corresponding to the original owner name with the asterisk label prepended. Mark this NSEC4 RR as temporary;
-
If the original owner name is a wildcard domain name (Section 2.1.1. of ), mark the NSEC4 to be an NSEC4 RR that is matching a wildcard;
-
For each RRSet at the original owner name, set the corresponding bit in the Type Bit Maps field;
-
Additional NSEC4 RRs need to be added for every empty non-terminal between the apex and the original owner name. If hashing is used, optionally keep track of the original owner names of these NSEC4 RRs and create temporary NSEC4 RRs for wildcard collisions in a similar fashion to step 3;
-
Sort the set of NSEC4 RRs into canonical order.
-
Combine NSEC4 RRs with identical owner names by replacing them with a single NSEC4 RR with the Type Bit Maps field consisting of the union of the types represented by the set of NSEC4 RRs. If hashing is used and the original owner name was tracked, then collisions may be detected when combining, as all of the matching NSEC4 RRs should have the same original owner name. If a hash collision is detected, then a new salt has to be chosen, and the signing process is restarted. Discard any possible temporary NSEC4 RRs;
-
In each NSEC4 RR, insert the next (hashed) owner name by using the domain name of the next NSEC4 RR in canonical order. The next (hashed) owner name of the last NSEC4 RR in the zone contains the value of the (hashed) owner name of the first NSEC4 RR in canonical order.
If the NSEC4 is marked to be matching a wildcard, find the NSEC4 that matches the closest encloser. Set the Wildcard bit in the Flags field of that NSEC4;
-
Finally, add an NSEC4PARAM RR with the same Hash Algorithm, Iterations, and Salt fields to the zone apex.
This specification modifies DNSSEC-enabled DNS responses generated by authoritative servers. In particular, it replaces the use of NSEC or NSEC3 RRs in such responses with NSEC4 RRs.
Instead of wasting a whole denial of existence RR to deny a wildcard, we have introduced a bit in the Flags field of the NSEC4 RR that indicates whether wildcard synthesis was possible because there exists a wildcard domain name immediately descending from the original owner name.
The Denial of Wildcard Synthesis proof consists of one NSEC4 RR, that matches some domain name, and that has the Wildcard bit clear.
Note that without much knowledge of the original owner name, this proof is not really useful. In particular, we don't know if this is the wildcard synthesis that we are looking for. This changes if we combine this proof with the closest encloser proof.
For some NSEC4 responses, namely Name Error Response () and Referrals to Unsigned Subzones (), a proof of the closest encloser is required. This is a proof that some ancestor of the QNAME is the closest encloser of QNAME. The proof is described in Section 7.2.1 of , and is the same for NSEC4.
The denial of wildcard synthesis proof combined with the closest encloser proof results in a denial of source of synthesis proof. The source of synthesis is defined in as the wildcard domain name immediately descending from the closest encloser.
The Denial of Source of Synthesis proof consists of (up to) two NSEC4 RRs, the same that constructed the closest encloser proof:
- an NSEC4 RR that matches the closest encloser, and that has the Wildcard bit clear in the Flags field;
- an NSEC4 RR that covers the next closer name to the closest encloser.
The first NSEC4 RR essentially proves that the encloser exists, and that no wildcard synthesis at the encloser is possible. The second NSEC4 RR proves that the encloser is the closest, thus the denial of the wildcard synthesis is the denial of the source of synthesis.
If the zone does not contain any RRsets matching QNAME either exactly or via wildcard name expansion, then the name server must include proof that:
- there is no exact match for QNAME;
- the zone contains no RRsets that would match QNAME via wildcard name expansion.
With NSEC, the server includes in the response an NSEC RR that covers QNAME, and an NSEC RR that covers the wildcard RR at the closest encloser.
With NSEC3, the server includes in the response an NSEC3 RR that covers the next closer, an NSEC3 RR that covers the wildcard RR at the closest encloser, and an NSEC3 RR that matches the closest encloser.
To prove the nonexistence of QNAME with NSEC4, the server MUST include a denial of source of synthesis proof. This collection of (up to) two NSEC4 RRs proves both that QNAME does not exist and that a wildcard that could have matched QNAME also does not exist.
When a NODATA response needs to be returned, it is safe to say that QNAME exists. Similar to NSEC and NSEC3, server MUST include the NSEC4 RR that matches QNAME. This NSEC4 RR MUST NOT have the bits corresponding to either the QTYPE or CNAME set in its Type Bit Maps field.
Because of Opt-Out, the response can be different when QTYPE is DS. If no NSEC4 RR matches QNAME, the server MUST return a closest provable encloser proof for QNAME. The NSEC4 RR that covers the next closer name MUST have the Opt-Out bit set.
Note that we do not need to ensure the denial of source of synthesis proof, because a DS RRset next to a wildcard is meaningless (Section 4.6, ).
If the zone does not contain any RRsets matching QNAME, but there is wildcard name expansion possible then the name server must include proof that the wildcard match was valid. This proof is accomplished by proving that QNAME does not exist and that the closest encloser of QNAME and the immediate ancestor of the wildcard are equal.
Both with NSEC and NSEC3, the server includes in the response an NSEC RR that covers the next closer. It is not necessary to return a 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.
To prove that the wildcard name expansion was valid with NSEC4, the server MUST include in the response an NSEC4 RR that covers the next closer. For the same reasons as with NSEC and NSEC3, it is not necessary to return a RR that matches the closest encloser.
With NSEC, the server includes in the response an NSEC RR that matches the wildcard, in addition to the NSEC RR that covers the next closer. The NSEC RR does not have the bits corresponding to QTYPE or CNAME set in its Type Bit Maps field.
Again, with NSEC3, the server includes in the response an NSEC3 RR that matches the wildcard, in addition to the NSEC3 RR that covers the next closer. The NSEC3 RR does not have the bits corresponding to QTYPE or CNAME set in its Type Bit Maps field. Besides that, an NSEC3 RR that matches the closest encloser is included, because there was no expanded wildcard in the response that can be used to determine the closest encloser.
already notes that the closest encloser to QNAME must be the immediate ancestor of the wildcard RR, which is also defined in . A closest encloser proof is not necessitated.
To prove the wildcard no data response with NSEC4, the server MUST include in the response an NSEC4 RR that matches the wildcard, and an NSEC4 RR that covers the next closer. The closest encloser can be derived from the NSEC4 RR that matches the wildcard. From that, the next closer can be derived.
If there is an NSEC4 RR that matches the delegation name, then that NSEC4 RR MUST be included in the response. The DS and CNAME bit in the type bit maps of the NSEC4 RR must not be set (by definition).
If the zone is Opt-Out, then there may not be an NSEC4 RR corresponding to the delegation. In this case, the closest provable encloser proof MUST be included in the response. The included NSEC4 RR that covers the next closer name for the delegation MUST have the Opt-Out flag set to one.
Note that with the Identity function, the NSEC4 RR that matches the closest provable encloser does not need to be included in the response, as it can be derived from the NSEC4 that covers the next closer name.
When NSEC4 hashing is in effect the paradox (NSEC4 records deny their own existence) described in Section 7.2.8 of is back. When the Identity function is used, there is no paradox. In light of this, queries for the NSEC4 resource type are handled in the same way as normal queries. Resolvers initiating these queries SHOULD disregard any information learned from the returned NSEC4 records.
The same considerations as described in Section 7.2.9 of for NSEC3 apply to NSEC4.
The same considerations as described in Section 7.3 of for NSEC3 and NSEC3PARAM apply to NSEC4 and NSEC4PARAM.
The same considerations as described in Section 7.4 of for NSEC3 apply to NSEC4.
A zone signed using NSEC4 may accept dynamic updates . However, NSEC4 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, similar to , Section 7.5.
The presence of Opt-Out in a zone means that some additions or removals of unsigned delegations of names will not require changes to the NSEC4 RRs in a zone. The same considerations as in , Section 7.5 for NSEC3 apply for NSEC4.
The presence of Opt-Out in a zone means that when adding or removing NSEC4 RRs, the value of the Opt-Out flag that should be set in new or modified NSEC4 RRs is ambiguous. Servers SHOULD follow the set of basic rules to resolve the ambiguity, as described in , Section 7.5.
Adding and removing wildcard names in a zone MUST account for the setting or clearing of the Wildcard bit in the Flags field:
-
When adding a wildcard name, the NSEC4 RR that matches the immediate parent of the wildcard MUST set the Wildcard bit in the Flags field;
-
When deleting a wildcard name, the NSEC4 RR that matches the immediate parent of the wildcard MUST clear the Wildcard bit in the Flags field.
A validator MUST ignore NSEC4 RRs with unknown hash types. The practical result of this is that responses containing only such NSEC4 RRs will generally be considered bogus.
A validator MUST ignore the undefined bits (0-5) in the Flags field of NSEC4 RRs.
A validator MAY treat a response as bogus if the response contains NSEC4 RRs that contain different values for hash algorithm, iterations, or salt from each other for that zone.
A validator MUST verify that there is a closest encloser for QNAME present in the response. A validator MUST verify that the Wildcard bit is clear in the Flags field of the NSEC4 RR that matches the closest encloser.
Note: In denial of existence responses, the Wildcard flag will never be set. Setting the bit indicated that wildcard synthesis is possible at the closest encloser. Obviously, that contradicts with the denial of existence of the query name. Nevertheless, a validator must verify that the Wildcard bit is clear. If a validator fails to check the bit, it is vulnerable to replay attacks. For example, if you do not check the Wildcard Flag in the example.com NSEC4 (but *.example.com does exist), an attacker can use the record to deny names that would otherwise match the wildcard name.
In order to find the closest encloser, the validator MUST find the longest name, X, such that X is an ancestor of QNAME that is matched by an NSEC4 RR present in the response.
One possible algorithm for finding the closest encloser is as follows:
- Set SNAME=QNAME;
- If there is an NSEC4 RR in the response that matches SNAME, then we have found the closest encloser;
- 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 NSEC4 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 MUST be clear if the SOA type bit is clear.
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 addition, the validator MUST verify that there is an NSEC4 RR that covers the next closer name.
If QTYPE is not DS, a validator MUST verify that an NSEC4 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 NSEC4 RR exists because it corresponds to an empty non-terminal, in which case the NSEC4 RR will have an empty Type Bit Maps field.
If QTYPE is DS, and there is an NSEC4 RR that matches QNAME present in the response, then that NSEC4 RR MUST NOT have the bits corresponding to DS and CNAME set in its Type Bit Maps field.
If there is no such NSEC4 RR, then the validator MUST verify that there is a closest provable encloser for QNAME present in the response. The closest provable encloser is found in a similar way as the closest encloser. In addition, the validator MUST verify that there is an NSEC4 RR that covers the next closer name and has the Opt-Out bit set.
The verified wildcard answer RRSet in the response provides the validator with a closest encloser for QNAME. The validator can do so by checking the label count in the RRSIG and the number of labels in the answer's owner name.
The validator MUST verify that there is an NSEC4 RR that covers the next closer name to QNAME is present in the response. This proves that QNAME itself did not exist and that the correct wildcard was used to generate the response.
The validator MUST verify that there is an NSEC4 RR present in the response that matches the source of synthesis.
In order to find the source of synthesis, the validator MUST find the longest name, X, such that X is an ancestor of QNAME and that *.X is matched by a NSEC4 RR present in the response.
One possible algorithm for finding the source of synthesis is as follows:
- Set SNAME=QNAME;
- Truncate SNAME by one label from the left. This is a candidate for the closest encloser;
- Set WNAME to be SNAME with the asterisk label prepended: WNAME=*.SNAME;
- If there is an NSEC4 RR in the response that matches WNAME, then we have found the source of synthesis, with SNAME being the closest encloser;
- Go to step 2.
The validator does not need to check that the closest encloser is from the proper zone. The authoritative server returned an NSEC4 that matches the source of synthesis. According to , this proves that the server did not encounter a referral (step 3b of the server algorithm ), nor did it encounter a DNAME (step 3c of the server algorithm ).
Now that the validator knows the source of synthesis and thus the closest encloser, it can derive the next closer name. The validator MUST verify that there is an NSEC4 RR that covers the next closer name to QNAME, is present in the response.
Note that, because the response included an NSEC4 that matches the source of synthesis, we know that there exists data in the zone below the closest encloser. Therefore, the closest encloser cannot be a delegation, nor can there exists a DNAME RRset at the closest encloser.
[MM: As an additional check, the validator can verify if the NSEC4 matching the closest encloser has the Wildcard Flag set.]
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 NSEC4 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 NSEC4 RR. The validator MUST also ensure that the NSEC4 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 NSEC4 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 NSEC4 RR.
If there is no NSEC4 RR present that matches the delegation name, then the validator MUST verify that there is a closest provable encloser for the delegation name. In addition, the validator MUST verify that there is an NSEC4 RR that covers the next closer name and has the Opt-Out bit set.
The same considerations as described in Section 9.1 of for NSEC3 apply to NSEC4.
The same considerations as described in Section 9.2 of for NSEC3 apply to NSEC4.
The same considerations as described in Section 10.1 of apply.
The DNAME specification in Section 3 of has a 'no-descendants' limitation. If a DNAME RR is present at node N, there MUST be no data at any descendant of N.
updates the DNAME specification to allow NSEC3 and RRSIG types at descendants of the apex regardless of the existence of DNAME at the apex.
This document updates the DNAME specification to also allow NSEC4 types at descendants of the apex regardless of the existence of DNAME at the apex.
Like Section 10.3 in , but we recommend to read as it shows that a lower iterations value is also acceptable. The research shows that that the half performance count for validators is roughly 150 to 600, depending on the key size. For authoritative servers the half performance count is around 100 iterations.
Appendix C of clarifies specific behavior and explains more special considerations for implementations, regarding salting and hash collisions. These considerations for NSEC3 also apply to NSEC4.
Although the NSEC4 and NSEC4PARAM RR formats include a hash algorithm parameter, this document does not define a particular mechanism for safely transitioning from one NSEC4 hash algorithm to another. When specifying a new hash algorithm for use with NSEC4, a transition mechanism MUST also be defined.
This document updates the IANA registry "DOMAIN NAME SYSTEM PARAMETERS" (http://www.iana.org/assignments/dns-parameters) in sub-registry "TYPES", by defining two new types. defines the NSEC4 RR type [TBD]. defines the NSEC4PARAM RR type [TBD].
This document possibly updates the IANA registry "DNS SECURITY ALGORITHM NUMBERS -- per " (http://www.iana.org/assignments/dns-sec-alg-numbers).
This document creates a new IANA registry for NSEC4 flags. This registry is named "DNSSEC NSEC4 Flags". The initial contents of this registry are:
0 1 2 3 4 5 6 7
+----+----+----+----+----+----+----+----+
| | | | | | |Wild|Opt-|
| | | | | | |card|Out |
+----+----+----+----+----+----+----+----+
bit 6 is the Wildcard flag.
bit 7 is the Opt-Out flag.
bits 0 - 5 are available for assignment.
Assignment of additional NSEC4 Flags in this registry requires IETF Standards Action .
This document creates a new IANA registry for NSEC4PARAM flags. This registry is named "DNSSEC NSEC4PARAM Flags". The initial contents of this registry are:
0 1 2 3 4 5 6 7
+---+---+---+---+---+---+---+---+
| | | | | | | | 0 |
+---+---+---+---+---+---+---+---+
bit 7 is reserved and must be 0.
bits 0 - 6 are available for assignment.
Assignment of additional NSEC4PARAM Flags in this registry requires IETF Standards Action .
Finally, this document creates a new IANA registry for NSEC4 hash algorithms. This registry is named "DNSSEC NSEC4 Hash Algorithms". The initial contents of this registry are:
0 is the Identity function.
1 is SHA-1.
2-255 Available for assignment.
Assignment of additional NSEC4 hash algorithms in this registry requires IETF Standards Action .
This document does not introduce any new security issues beyond those already discussed in , , and .
This document would not be possible without the help of Ed Lewis, Roy Arends, Wouter Wijngaards, Karst Koymans, Mohan Parthasarathy, Marco Davids, Esther Makaay and Antoin Verschuren.
With denialid published revisit this one.
- Clarification throughout the text (Mohan Parthasarathy);
- Add section about empty non-terminals in NSEC, NSEC3 and NSEC4;
- Rename Zero hashing to Identity function.
- No need for different ordering mechanisms: canonical ordering only.
- Remove section on validator algorithm (already explained in RFC4035).
- Initial document.