# Introduction DNSSEC

Normally, "control" over the ZSK and possibly also over the KSK in a DNSSEC-enabled infrastructure will rest with the zone administrator. Often, the zone administrator is identical with the operator of the name server infrastructure, hereinafter referred to as "operator".

To change this operator, you must roll over the key(s) concerned and transfer DNS delegation to an infrastructure (set of name servers) that is independent of the "old" operator.

In this document, we explicate the steps which are necessary in the relevant scenarios to enable a key rollover and operator change without inconsistencies.

If you strictly follow the work schedules, no validation errors will occur because during the rollover procedure the validating resolver can retrieve its keys from both the old and the new operator.

Caution! |  | If you carry out an operator change in one single step, i.e. execute a change of delegation by only one single request, this will lead to validation errors!

A change of RegAcc not including an operator change, however, will remain feasible through one single CHPROV request without causing problems, even with DNSSEC domains.

## Requirements

To use you must know the procedure of moving an unsigned .de domain from one operator to another and you must have basic knowledge about DNSSEC (meaning of KSK and ZSK and steps of domain signing procedure).

## Roles

In this document, two roles will be distinguished:

- Operator

- RegAcc

The RegAcc will be the DENIC member who administers the domain and who will make the changes in the database (Registry .de), whilst the operator will provide the name server infrastructure.

## Form of Presentation

We have chosen the following form of presentation:

Figure 1: Example illustration

Explanation: All case studies in this document are based on the domain "de-example.de". We want to carry out an operator change for this domain. The two servers shown for the old and the new operator are just examples; they are not requirements. "NS old" and "NS new" represent the NS resource records of the de-example.de domain.

It is assumed that you are working with separate KSK and ZSK for the zone (de-example.de). The additions to the Delegation Signer (DS) "old" and "new" refer to the authoritative data origin. This origin may either be the old or the new operator.

The index card in the picture displays an extract from the .de zone for the de-example.de domain with the respective relevant data. Also, for the old and the new operator we display only the data needed in the respective operator's zone for the operator change. Please note that the displayed keys are the public keys and that, for reasons of clarity, the relevant DNSSEC signatures are not shown. When necessary, we explain in the text which data is signed with which key. It goes without saying that the private section of the key is used in such cases.

DS(KEY) stands for a DS-RR generated by the registry based on the key stored in the domain object.

If request types are mentioned in the text, they are written in a different font (Courier New).

## Initial situation

The name server information and the valid KSK of the old operator of the domain, e.g. de-example.de, are stored in the registry .de. The ZSK of the old operator is signed with this operator's KSK and published in the DNS. The zone de-example.de is delegated to the name servers of the operator.

The operators involved must be capable to sign with DNSSEC.

Figure 2: Situation before operator change