Skip to main content

10. Special Considerations

10. Special Considerations​

10.1. Domain Name Length Restrictions​

Zones signed using this specification have additional domain name length restrictions imposed upon them. In particular, zones with names that, when converted into hashed owner names exceed the 255 octet length limit imposed by [RFC1035], cannot use this specification.

The actual maximum length of a domain name in a particular zone depends on both the length of the zone name (versus the whole domain name) and the particular hash function used.

As an example, SHA-1 produces a hash of 160 bits. The base-32 encoding of 160 bits results in 32 characters. The 32 characters are prepended to the name of the zone as a single label, which includes a length field of a single octet. The maximum length of the zone name, when using SHA-1, is 222 octets (255 - 33).

10.2. DNAME at the Zone Apex​

The DNAME specification in Section 3 of [RFC2672] has a 'no- descendants' limitation. If a DNAME RR is present at node N, there MUST be no data at any descendant of N.

If N is the apex of the zone, there will be NSEC3 and RRSIG types present at descendants of N. This specification updates the DNAME specification to allow NSEC3 and RRSIG types at descendants of the apex regardless of the existence of DNAME at the apex.

10.3. Iterations​

Setting the number of iterations used allows the zone owner to choose the cost of computing a hash, and therefore the cost of generating a dictionary. Note that this is distinct from the effect of salt, which prevents the use of a single precomputed dictionary for all time.

Obviously the number of iterations also affects the zone owner's cost of signing and serving the zone as well as the validator's cost of verifying responses from the zone. We therefore impose an upper limit on the number of iterations. We base this on the number of iterations that approximates the cost of verifying an RRSet.

The limits, therefore, are based on the size of the smallest zone signing key, rounded up to the nearest table value (or rounded down if the key is larger than the largest table value).

A zone owner MUST NOT use a value higher than shown in the table below for iterations for the given key size. A resolver MAY treat a response with a higher value as insecure, after the validator has verified that the signature over the NSEC3 RR is correct.

                         +----------+------------+
                         | Key Size | Iterations |
                         +----------+------------+
                         | 1024     | 150        |
                         | 2048     | 500        |
                         | 4096     | 2,500      |
                         +----------+------------+

This table is based on an approximation of the ratio between the cost of an SHA-1 calculation and the cost of an RSA verification for keys of size 1024 bits (150 to 1), 2048 bits (500 to 1), and 4096 bits (2500 to 1).

The ratio between SHA-1 calculation and DSA verification is higher (1500 to 1 for keys of size 1024). A higher iteration count degrades performance, while DSA verification is already more expensive than RSA for the same key size. Therefore the values in the table MUST be used independent of the key algorithm.

10.4. Transitioning a Signed Zone from NSEC to NSEC3​

When transitioning an already signed and trusted zone to this specification, care must be taken to prevent client validation failures during the process.

The basic procedure is as follows:

  1. Transition all DNSKEYs to DNSKEYs using the algorithm aliases described in Section 2. The actual method for safely and securely changing the DNSKEY RRSet of the zone is outside the scope of this specification. However, the end result MUST be that all DS RRs in the parent use the specified algorithm aliases.

After this transition is complete, all NSEC3-unaware clients will treat the zone as insecure. At this point, the authoritative server still returns negative and wildcard responses that contain NSEC RRs.

  1. Add signed NSEC3 RRs to the zone, either incrementally or all at once. If adding incrementally, then the last RRSet added MUST be the NSEC3PARAM RRSet.

  2. Upon the addition of the NSEC3PARAM RRSet, the server switches to serving negative and wildcard responses with NSEC3 RRs according to this specification.

  3. Remove the NSEC RRs either incrementally or all at once.

10.5. Transitioning a Signed Zone from NSEC3 to NSEC​

To safely transition back to a DNSSEC [RFC4035] signed zone, simply reverse the procedure above:

  1. Add NSEC RRs incrementally or all at once.

  2. Remove the NSEC3PARAM RRSet. This will signal the server to use the NSEC RRs for negative and wildcard responses.

  3. Remove the NSEC3 RRs either incrementally or all at once.

  4. Transition all of the DNSKEYs to DNSSEC algorithm identifiers. After this transition is complete, all NSEC3-unaware clients will treat the zone as secure.

Last updated on