DNSSEC is a protocol extension of DNS based on cryptographic tools (keys and signatures). DNSSEC protect the DNS data and transactions. DNSSEC takes full advantage of the hierarchical structure of the DNS: the zones are secured locally, but they can also become a part of a more global scheme, where chains of trust are built to allow a zone to authenticate the keys of its children zones, aswell as to allow a zone to be authenticated by its parent zone.

Delay of this activity

Originally, we anticipated the implementation of DNSSEC in the 6NET DNS infrastructure by the end of year 1. At the time when this schedule was made, the DNSSEC specification was considered to be nearly finished and expected to move through the IETF standardisation process quickly. Later, the DNSEXT working group of the IETF started a major revision of the specification to address a number of scalability and management issues. As a consequence, it was decided to postpone the DNSSEC related activity of WP3 to the end of March 2004.

Deployment Plan

This focuses on the planned action for testing DNSSEC when the updated software versions become
available, during 2004.

DNSSEC will be deployed in 6NET. As a minimum, DNSSEC will be applied to the inverse address mapping of the 6NET address space 2001:0798::/40 in the manner describer bellow. If time permits, this will be extended to the 6net.org zone, which is more interesting as it contains more non-trivial delegations (i.e., delegations to different organizations).

• All authoritative name servers for the zones 8.9.7.0.1.0.0.2.ip6.arpa. and 8.9.7.0.1.0.0.2.ip6.int. and their sub-zones run a DNSSEC-capable name server.

• The administrators of the top-level zones of these DNS subtrees generate at least one key per zone (“zone-signing keys”) and sign the zone contents with it. When they are transmitted to all participants in a secure manner, the public parts of these keys establish a “secure entry point” to those particular sub-trees. This step is necessary as long as DNSSEC is not deployed all the way down from the root of the DNS.

• The organizations that want to be able to verify the signatures on the resource records of these zones must install DNSSEC-capable caching servers and establish secure communications between the caches and the stub-resolvers. They must obtain and install authenticated copies of the public keys described above to establish the secure entry points.

• Each sub-zone must maintain its own set of zone-signing keys and communicate them to their
parent zone through an authenticated channel to establish a secure delegation.

The procedures for key management in the DNSSEC framework have not yet been fully established.
This area of work is considered to be out of scope for 6NET. Therefore, only a minimal set of key
management procedures will be established in 6NET, consisting of :

• proper generation of keying material (e.g. use of a decent random number generator)

• transmission of public keys over authenticated channels only (e.g. by using the PGP web-oftrust that has already been established among 6NET participants)

• manual key roll-overs

More sophisticated key management functions may be implemented if the DNSSEC-specific guidelines become available in time.

Note : there are two types of DNSSEC Key : zone-signing-key (ZSK) that signed all RR of the zone and key-signing key (KSK) that signed only the KEY RR. Only the KSK is transmitted to the parent zone. This permit to do an easier key rollover: you can change the ZSK without change the KSK. In special case when there is only one Key: it’s a ZSK and this Key is transmitted to the parent zone.