The CZ.NIC association, the administrator of the .CZ domain and of 0.2.4.e164.arpa, is planning to deploy the DNSSEC technology to improve security.

When the technology was introduced in the autumn of 2008, it was decided that it would be deployed in a version called NSEC. NSEC is a part of the DNSSEC specification that solves the problem of authorized reply about the non-existence of the domain. When the zone file containing all records for the given domain is signed, a NSEC record is entered between all subdomains. The record refers to the next subdomain in the alphabet. This NSEC record is then signed as usual. If the client sends a request referring to a non-existent domain, they are sent an answer containing a NSEC record that refers to the previous existing domain and the next existing domain. This way, the client can easily verify that the requested domain does not exist. NSEC records have an undesirable property, though. Due to the concatenation of consecutive domains, it is easy to obtain the content of the whole zone by an appropriate combination of queries about the NSEC records. This browsing of the zone came to be called zonewalking. From the viewpoint of security, this is not a serious problem. DNS is a public database, and no sensitive data can be accessed this way. Therefore, all domain administrators who deployed DNSSEC opted for this version.

However, IETF working groups worked on versions that would remove the problem of zonewalking. The result was a version called NSEC3, which was published in RFC 5255. NSEC3 retained the way of proving the non-existence of domains by sending the client a signed record referring to the previous and next domain, which means that the requested domain is not available. The way domains are identified has changed, though. The hash of the domain name is used instead of the domain name itself. Domains are ordered in the zone file by the hash of their names. Clients inquiring about a non-existent domain can compute the hash of its name, and by making a comparison with the reply containing the previous and the next hash in the zone file, they can verify the non-existence of the domain, just like in the NSEC version.

The deployment of NSEC3 in both domains demands that CZ.NIC, in the capacity of their administrator, change KSK keys and re-sign the zone file using a new algorithm with these keys. This internal change from the NSEC version to the NSEC3 version does not have any direct impact on the domain holders and Internet users. It will only affect the operators of recursive DNS servers who have already activated validation using the DNSSEC technology, i.e. mainly Internet service providers (ISP). For them, the change is equivalent to a regular rotation of keys for the given domain with one difference. New types of keys (RSASHA512) and the NSEC3 version must be supported by the software of the recursive DNS server. If this requirement is satisfied, everything is alright. Otherwise an upgrade must be carried out. Ideally, no change is needed for the ENUM domain. The key for signing this domain will be automatically inserted into the parent domain e164.arpa. The ISP validating this domain should have the key of this parent domain in its configuration and does not need to change anything. For the .CZ domain, a new key will have to be added in the DNS server configuration, just like during standard key rotation. Since a new root domain will probably have been signed when the keys are changed, it is possible that ISP will already be using directly the keys of the root domain. In this case, the situation is like for the ENUM domain, and no change in configuration is needed.

Schedule of NSEC3 deployment

• 4 June 2010 – Launching the test environment for operators of recursive DNS servers - DONE
• 15 June 2010 – Switch to NSEC3 in the 0.2.4.e164.arpa domain - DONE
• 3 August 2010 - 24 August 2010 - Switch to NSEC3 in the .CZ domain - DONE

Should you have any questions regarding the switch to NSEC3, please contact us at podpora@nic.cz.