STEP-BY-STEP DNS SECURITY

OPERATOR GUIDANCE DOCUMENT

[Using the BIND-9.3.0 (or later) distribution]

Version 0.4

SPARTA, Inc.

7075 Samuel Morse Dr.

Columbia MD 21046

Ph: 410.872.1515

sparta-dnssec AT tislabs DOT com


Contents

Introduction

DNS Security raises the bar on spoofing attacks against the DNS by providing for origin authentication and integrity protection of DNS information.

This document is intended to function as a guidance document for DNS Security operations using the BIND-9.3.0 (or later) distribution [4].

This aim of this document is to assist operators in gaining operational experience with DNSSEC. Some basic understanding of DNSSEC terms and concepts is required. A good introduction to DNSSEC can be found in [5]. Some basic understanding of public key cryptography is also required [7].

This step-by-step document is meant to be a learning aid and is not intended to define policy in any form. Any implicit recommendations for key sizes, signature validity periods, and command line parameters are for illustration purposes ONLY and MUST NOT be used in production environments unless due-diligence has been taken to ensure that these values are acceptable within such environments.

Since one of the goals of this document is to self-contain DNS Security operations within sections and prevent constant cross-referencing between sections you may find certain text repetitive throughout the document.

Text marked in bold is used to represent commands or text entered by users within a given procedural step. Underlined text, which can also be in bold, is a placeholder for actual run-time values; these values are either automatically generated or are values that are known to the user from some other step.

The following procedures are described in the below-mentioned sections of this document:

  1. Zone Signing Key (ZSK) generation

This section describes the procedure for creating new Zone Signing Keys; i.e., the keys used for signing zone data.

  1. Key Signing Key (KSK) generation

This section describes the procedure for creating new Key Signing Keys; i.e., keys that are used to sign the ZSKs in the apex keyset.

  1. Signing a zone with no delegations

This section describes the procedure used to sign a zone that has no delegations (no non-authoritative NS records) present in the zone file.

  1. Signing a zone that has delegations

This section describes the procedure used to sign a zone that has delegations (non-authoritative NS records) present in the zone file. The difference between this and section 3 lies in the additional communication involved between the parent and the child and the creation of the DS record in the parent zone, when delegations are present.

  1. Configuring and serving a signed zone

This section describes the procedure for serving a signed zone file.

  1. Creating a signed delegation - child zone activity

This section describes the activities that the child zone needs to perform in order to facilitate the creation of a signed delegation at the parent.

  1. Creating a signed delegation - parent zone activity

This section describes the activities that the parent zone needs to perform in order to facilitate the creation of a signed delegation at the parent.

  1. “Current” ZSK roll-over (pre-publish scheme)

This section describes the procedure for rolling over an old ZSK. These steps should be used only if the older ZSK is known to have not been compromised.

  1. KSK roll-over (double signature scheme)

This section describes the procedure for rolling over an old KSK. These steps should be used only if the older KSK is known to have not been compromised.

  1. Emergency ZSK roll-over (Current ZSK compromise)

This section describes the procedure for performing an emergency roll-over of the Current (the key that is currently used to sign zone data) ZSK, when it is suspected or known to be compromised.

  1. Emergency ZSK roll-over (Published ZSK compromise)

This section describes the procedure for performing an emergency roll-over of the Published (the key that is pre-published in the zone file as the future zone signing key) ZSK, when it is suspected or known to be compromised.

  1. Emergency ZSK roll-over (Published and Current ZSK compromise)

This section describes the procedure for performing an emergency roll-over of the Published and Current ZSKs, when both are suspected or known to be compromised.

  1. Emergency KSK Roll-over (KSK compromise)

This section describes the procedure for performing an emergency roll-over of the KSK, when it is suspected or known to be compromised.

  1. Parent action during child KSK compromise

This section describes the actions that the parent zone must perform when it receives notification from the child about a KSK compromise, and before it publishes a DS value that points to the new KSK in the child.

These sections are followed by a number of appendices, which contain useful information such as checklists for important operations and pictorial illustrations for each of the operations described in the main body of this document.

The following table summarizes the list of steps relevant to different kinds of zones. The columns marked with a `X' for any row correspond to those operations that the zone operator for that type of zone needs to familiarize himself with.

Steps

Zone Profile

1

2

3

4

5

6

7

8

9

10

11

12

13

14

No signed delegations, parent is not signed

X

X

X

X

X

X

X

X

X

X

No signed delegations, parent is signed

X

X

X

X

X

X

X

X

X

X

X

Zone with signed delegations, parent is not signed

X

X

X

X

X

X

X

X

X

X

X

X

Zone with signed delegations, parent is signed

X

X

X

X

X

X

X

X

X

X

X

X

X

This document builds upon the procedures described [1] in for key roll-over techniques; the step-by-step instructions described in sections 8 and 9 are meant to closely follow the recommendations given by that document. Early versions of this guide were reviewed and critiqued by SAIC, Inc./Quotient, Inc. including Rip Loomis and Rob Payne, and their contributions are acknowledged.

Please send any comments and corrections to sparta-dnssec AT tislabs DOT com

    1. Check for randomness

$dd if=/dev/random bs=2 count=10 | od -x [ENTER]

The above command checks if /dev/random is able to provide random data when queried for.

dnssec-keygen and dnssec-signzone use random data from /dev/random by default; if the check for randomness fails, pseudorandom numbers can be used instead [6]. However, it is important to note that using pseudorandom numbers significantly affects the quality of the crypto material. A more appropriate measure would be to run the key generation and zone signing operations on a different system that has /dev/random and the ability to generate good, random data [2].

    1. Check for correct version of dnssec-keygen (9.3.0 or later)

$ dnssec-keygen -h [ENTER]

Usage:

dnssec-keygen -a alg -b bits -n type [options] name

Version: 9.3.0

……

$

If the version is incorrect, install the correct BIND version or adjust the PATH environment variable to use the correct installation.

    1. Generate the key

Generate a key of size 512 bytes.

$dnssec-keygen -a RSASHA1 -b 512 -n ZONE zone.name \ [ENTER]

Kzone.name.+005+zsktag

$

The process normally takes a few minutes to return its results. If the process appears to have stalled, run the command using a pseudo-random number generator as follows:

$dnssec-keygen -r /dev/urandom -a RSASHA1 -b 512 -n \ ZONE zone.name [ENTER]

Kzone.name.+005+zsktag

$

The output is two files:

zone.name - the name of the zone (example.com for instance)

zsktag - the id of this key.

You will need to note this is the number in the key-tag table as you walk through the document. This number is automatically generated and should not be changed. The key id will be the only field in the filename that changes as you rotate keys, so it should be tracked.

This document uses RSASHA1 as the cryptographic algorithm (005 in the algorithm field).

    1. Keep a record of the key-tags that currently refer to ZSKs.

Zone

ZSK

KSK

Exp

Tag

Size

Creat

S

Tag

Size

Creat

S

zone.name

zsktag

512

date

Leave the status field (S) empty for now.

    1. Keep the private keys for ZSKs and KSKs separate from each other

Storing the private keys for ZSKs and KSKs offline is considered a good security practice. ZSK and KSK separation lessens the operational burden during zone-key compromise, but only if the KSK is still considered to be safe for use. In cases where a signed zone is also updated via dynamic updates, the ZSK will need to be online and available to the name server process. To avoid a common vulnerability point (such as compromise of the system on which these keys reside), store the KSKs in a place that is considered safer.

    1. Check for randomness

$dd if=/dev/random bs=2 count=10 | od -x [ENTER]

The above command checks if /dev/random is able to provide random data when queried for.

dnssec-keygen and dnssec-signzone use random data from /dev/random by default; if the check for randomness fails, pseudorandom numbers can be used instead [6]. However, it is important to note that using pseudorandom numbers significantly affects the quality of the crypto material. A more appropriate measure would be to run the key generation and zone signing operations on a different system that has /dev/random, and the ability to generate good, random data [2].

    1. Check for correct version of dnssec-keygen (9.3.0 or later)

$ dnssec-keygen -h [ENTER]

Usage:

dnssec-keygen -a alg -b bits -n type [options] name

Version: 9.3.0

……

$

If the version is incorrect, install the correct BIND version or adjust the PATH environment variable to use the correct installation.

    1. Generate the key

Generate a key of size 1024 bytes. The KSKs are generally made stronger than ZSKs; key size is a rough measure of strength.

$dnssec-keygen -a RSASHA1 -b 1024 -n ZONE -f KSK \ zone.name [ENTER]

Kzone.name.+005+ksktag

$

The process normally takes a few minutes to return its results. If the process appears to have stalled, run the command using a pseudo-random number generator as follows:

$dnssec-keygen -r /dev/urandom -a RSASHA1 -b 1024 -n \ ZONE -f KSK zone.name [ENTER]

Kzone.name.+005+ksktag

$

The output is two files:

zone.name - the name of the zone (example.com for instance)

zsktag - the id of this key.

You will need to note this is the number in the key-tag table as you walk through the document. This number is automatically generated and should not be changed. The key id will be the only field in the filename that changes as you rotate keys, so it should be tracked.

This document uses RSASHA1 as the cryptographic algorithm (005 in the algorithm field).

    1. Keep a record of the key-tags that currently refer to KSKs.

Zone

ZSK

KSK

Exp

Tag

Size

Creat

S

Tag

Size

Creat

S

zone.name

ksktag

1024

date

Leave the status field (S) empty for now.

    1. Keep the private keys for ZSKs and KSKs separate from each other

Storing the private keys for ZSKs and KSKs offline is considered a good security practice. ZSK and KSK separation lessens the operational burden during zone-key compromise, but only if the KSK is still considered to be safe for use. In cases where a signed zone is also updated via dynamic updates, the ZSK will need to be online and available to the name server process. To avoid a common vulnerability point (such as compromise of the system on which these keys reside), store the KSKs in a place that is considered safer.

Zones need to be re-signed when any change is made to it. Follow Steps 3.3-3.8 when re-signing a zone file that has no delegations.

    1. Generate two ZSKs and one KSK

Follow steps in section 1 for generating the ZSKs and steps in section 2 for generating the KSK. Designate one of the two ZSKs as the Current (C) zone signing key and use it to sign the zone data; designate the other as the Published (P) key, which is for future use following a ZSK roll-over. Set the status of each of these keys in the column marked S. There is only one KSK and this is used to sign the zone apex keyset; mark its status as Current (C). The Published ZSK should be kept more safely than the Current ZSK, the idea being that the Published ZSK can be easily rolled in even if the Current ZSK is compromised (the Current ZSK may have to be kept online in some circumstances). The Published ZSK may be kept at the same location where the KSK is stored.

Zone

ZSK

KSK

Exp

Tag

Size

Creat

S

Tag

Size

Creat

S

zone.name

zsktag-cur

512

date

C

ksktag

1024

date

C

zsktag-pub

512

date

P

    1. Include the KSK and the ZSKs in the zone file; change the SOA serial number

$vi zonefile [ENTER]

zone.name IN SOA servername contact (

2004042201 ;increase current value by 1

; note that this value may

; be different in your zone

; file

)

;; ksk

$INCLUDE/path/to/Kzone.name.+005+ksktag.key

;; zsk1

$INCLUDE “/path/to/Kzone.name.+005+zsktag-cur.key

;; zsk2

$INCLUDE “/path/to/Kzone.name.+005+zsktag-pub.key

$

    1. Check the zone file for errors

$named-checkzone zone.name zonefile [ENTER]

zone zone.name/IN: loaded serial SerialNumber

OK

$

    1. Check permissions and ownership on ZSK and KSK files

The files should be readable by the dnssec-signzone tool as well as the process ID that the name server runs as.

    1. Check version of dnssec-signzone (9.3.0 or later)

$ dnssec-signzone -h [ENTER]

Usage:

dnssec-signzone [options] zonefile [keys]

Version: 9.3.0

$

If the version is incorrect, install the correct BIND version or adjust the PATH environment variable to use the correct installation.

    1. Sign the zone

$dnssec-signzone -k \ /path/to/Kzone.name.+005+ksktag.key -o zone.name -e \ +2592000 zonefile \

/path/to/Kzone.name.+005+zsktag-cur.key [ENTER]

zonefile.signed

$

Signature signing may take a few minutes to complete depending on the size of the zone file. If the above operation appears to be unresponsive for an unreasonable time frame, use pseudorandom numbers (using the -p option) instead.

$dnssec-signzone -k \ /path/to/Kzone.name.+005+ksktag.key -o zone.name -p \ -e +2592000 zonefile \

/path/to/Kzone.name.+005+zsktag-cur.key [ENTER]

zonefile.signed

$

The output is:

The signatures on the records as generated by the above command are valid for 2592000 seconds (30 days) from the current time (offset by -1 hour to account for clock skew between the name server and DNSSEC validators).

    1. Record the signature expiry time

Zone

ZSK

KSK

Exp

Tag

Size

Creat

S

Tag

Size

Creat

S

zone.name

zsktag-cur

512

date

C

ksktag

1024

date

C

date

zsktag-pub

512

date

P

    1. Check the zone file for errors

$named-checkzone zone.name zonefile.signed [ENTER]

zone zone.name/IN: loaded serial SerialNumber

OK

$

Zones need to be re-signed when any change is made to it. Follow steps 4.3-4.9 when re-signing a zone file that contains delegations.

    1. Generate two ZSKs and one KSK

Follow steps in section 1 for generating the ZSKs and steps in section 2 for generating the KSK. One of the two ZSKs is the Current (C) zone signing key and is used to sign the zone data; the other is Published (P) for future use following a ZSK roll-over. Set the status of each of these keys in the column marked S. There is only one KSK and this is used to sign the zone apex keyset; mark its status as Current (C). The Published ZSK should be kept more safely than the Current ZSK, the idea being that the Published ZSK can be easily rolled in even if the Current ZSK is compromised (the Current ZSK may have to be kept online in some circumstances). The Published ZSK may be kept at the same location where the KSK is stored.

Zone

ZSK

KSK

Exp

Tag

Size

Creat

S

Tag

Size

Creat

S

zone.name

zsktag-cur

512

date

C

ksktag

1024

date

C

zsktag-pub

512

date

P

    1. Include the ZSKs and the KSK in the zone file; change the SOA serial number

$vi zonefile [ENTER]

zone.name IN SOA servername contact (

2004042202 ;increase current value by 1

; note that this value may

; be different in your zone

; file

) …

;; ksk

$INCLUDE “/path/to/Kzone.name.+005+ksktag.key

;; cur-zsk

$INCLUDE “/path/to/Kzone.name.+005+zsktag-cur.key

;; pub-zsk

$INCLUDE “/path/to/Kzone.name.+005+zsktag-pub.key

$

    1. Check the zone file for errors

$named-checkzone zone.name zonefile [ENTER]

zone zone.name/IN: loaded serial SerialNumber

OK

$

    1. Check permissions and ownership on ZSK and KSK files

The files should be readable by the dnssec-signzone tool as well as the process ID that the name server runs as.

    1. Check version of dnssec-signzone (9.3.0 or later)

$ dnssec-signzone -h [ENTER]

Usage:

dnssec-signzone [options] zonefile [keys]

Version: 9.3.0

$

If the version is incorrect, install the correct BIND version or adjust the PATH environment variable to use the correct installation.

    1. Sign the zone

If the keysets from the child zones have been received (see section 7) run the following command:

$dnssec-signzone -g -k \ /path/to/Kzone.name.+005+ksktag.key -o zone.name -e \ +2592000 -d keyset-dir zonefile \ /path/to/Kzone.name.+005+zsktag-cur.key [ENTER]

zonefile.signed

$

Signature signing may take a while to complete depending on the size of the zone file. If the above operation seems unresponsive for a long time, re-run the previous command using pseudorandom numbers (using the -p option):

$dnssec-signzone -g -k \ /path/to/Kzone.name.+005+ksktag.key -o zone.name -p \ -e +2592000 -d keyset-dir zonefile \ /path/to/Kzone.name.+005+zsktag-cur.key [ENTER]

zonefile.signed

$

The -d option specifies the directory where the keyset files received from the child have been stored. If there are no keyset files available, run the above command(s) without the “-d keyset-dir option.

The output is:

The signatures on the records as generated by the above command are valid for 2592000 seconds (30 days) from the current time (offset by -1 hour to account for clock skew between the name server and DNSSEC validators).

    1. Record the signature expiry time

Zone

ZSK

KSK

Exp

Tag

Size

Creat

S

Tag

Size

Creat

S

zone.name

zsktag-cur

512

date

C

ksktag

1024

date

C

date

zsktag-pub

512

date

P

    1. Check the zone file for errors

$named-checkzone zone.name zonefile.signed [ENTER]

zone zone.name/IN: loaded serial SerialNumber

OK

$

    1. Confirm that the DS record was created in zone.name.signed

There should be a DS record in the signed zone file (zone.name.signed) for every domain name from where a keyset was received.

    1. Add the signed zone to the name server configuration file

$vi named.conf [ENTER]

zone “zone.name.” {

type master;

file “zonefile.signed”;

};

$

Note: the configuration file may have a different name than named.conf.

    1. Enable DNSSEC

Add the “dnssec-enable yes;” option in the named.conf file.

$vi named.conf [ENTER]

options {

dnssec-enable yes;

};

$

    1. Check the name server configuration file for errors

$named-checkconf named.conf [ENTER]

$

    1. Reload the zone

The name server process is assumed to be already running.

$rndc reload zone.name [ENTER]

The above command reloads the name server configuration files in addition to the zone contents.

    1. Check if the zone loaded properly

Confirm that the SOA serial number of the zone corresponds to the most recent value.

$dig @server-IP-address SOA zone.name [ENTER]

; <<>> DiG 9.3.0 <<>> …

;; flags: qr aa rd; QUERY: 1, ANSWER: 1, AUTHORITY: 1, ADDITIONAL: 0

;;ANSWER SECTION

zone.name 3600 IN SOA servername contact (

2004042204 ; this should be the most

; recent value

; note that this value may

; be different in your zone

; file

)

$

    1. Check the contents of the keyset file

Check if the keyset file generated in step 3.6 (or step 4.6) contains the correct KSK by making a visual comparison of the key material in the keyset file with the actual key contents. Also ensure that the key-tags in the keyset file correspond to the tags that were recorded for the KSK in 3.1 (or 4.1)

$cat keyset-zonefile [ENTER]

zone.name 3600 IN DNSKEY 257 3 5 (

); key id = key-tag

$

    1. Do a secure transfer of the keyset over to the parent

This step is necessary only if any of the KSKs for this zone have changed since the last time this file was sent to the parent (not required during a ZSK roll-over - sections 8, 10, 11, and 12).

Secure communication between the parent and child zone is done out-of-band.

    1. Wait for the parent to publish the DS record

$dig @parent-IP-address DS zone.name [ENTER]

; <<>> DiG 9.3.0 <<>> …

;; flags: qr aa rd; QUERY: 1, ANSWER: 1, AUTHORITY: 1, ADDITIONAL: 0

;;ANSWER SECTION

zone.name 3600 IN DS …

$

The aa flag must be set and the ANSWER section must be non-empty.

Check if the DS record returned above is the same as the value in the file generated in step 3.6 (or step 4.6).

    1. Ensure that the child keysets were received over a secure channel

Secure communication between the parent and child zone is done out-of-band.

    1. Ensure that each of the received keysets is for a zone that is being delegated

The owner name for the DNSKEY record in the received keyset must correspond to a valid delegation.

$cat keyset-childzonefile [ENTER]

child.zone.name 3600 IN DNSKEY 256 3 5 (

); key id = key-tag

$

child.zone.name must exist in the parent zonefile as a valid delegation.

$cat zonefile [ENTER]

child.zone.name NS server

A …

$

    1. Store all the child keysets in a separate directory.

This is simply to keep things clean.

    1. Sign the zone

Sign the zone using steps described in section 4.

    1. Reload the zone

The name server process is assumed to be already running.

$rndc reload zone.name [ENTER]

The above command reloads the name server configuration files in addition to the zone contents.

We use the pre-publish scheme for rolling over ZSKs. The alternative, the double signature method, is used for rolling over KSKs. Double signatures for records signed by the ZSK can increase the size of the zone many-fold; the pre-publish scheme, although requiring more steps for the roll-over, does not suffer from this problem. The size argument does not apply during KSK roll-over since the only record doubly signed by the KSK is the DNSKEY RRset.

    1. Make sure that sufficient time has elapsed since the last roll-over

The time between roll-overs has to be at least twice the maximum zone TTL period (the largest TTL in the zone file multiplied by two).

    1. Sign with the KSK and Published ZSK

Follow steps 3.3 - 3.8 or steps 4.3 - 4.9 depending on whether the zone contains or does not contain delegations. The ZSK used in the signing process in section 3.6 (or 4.6) must be the key that is marked as the Published key (P) in the key-tag table. The KSK used as input to dnssec-signzone does not change; hence the keyset does not change and does not have to be re-sent to the parent either.

Record the signature expiry date in the key-tag table.

Zone

ZSK

KSK

Exp

Tag

Size

Creat

S

Tag

Size

Creat

S

zone.name

zsktag-cur

512

Date

C

ksktag

1024

date

C

date

zsktag-pub

512

Date

P

    1. Reload the zone

The name server process is assumed to be already running.

$rndc reload zone.name [ENTER]

The above command reloads the name server configuration files in addition to the zone contents.

    1. Wait for old zone data in caches to expire and for the new data to propagate

Wait at least twice the maximum zone TTL period (the largest TTL in the zone file multiplied by two).

    1. Generate a New ZSK

Follow steps in section 1 for generating a new ZSK.

Update the key-tag table with the new ZSKs; set its status to New (N).

Zone

ZSK

KSK

Exp

Tag

Size

Creat

S

Tag

Size

Creat

S

zone.name

zsktag-cur

512

date

C

Ksktag

1024

date

C

date

zsktag-pub

512

date

P

zsktag-new

512

date

N

    1. Replace the Current ZSK with the New ZSK in the zone file; change the SOA serial number

$vi zonefile [ENTER]

zone.name IN SOA servername contact (

2004042205 ;increase current value by 1

; note that this value may

; be different in your zone

; file

)

;; ksk

$INCLUDE “/path/to/Kzone.name.+005+ksktag.key”

;; cur zsk

$INCLUDE “/path/to/Kzone.name.+005+zsktag-cur.key

;; pub zsk

$INCLUDE “/path/to/Kzone.name.+005+zsktag-pub.key”

;; new zsk

$INCLUDE “/path/to/Kzone.name.+005+zsktag-new.key

$

    1. Update the key-tag table to reflect the changed key status

Delete the old Current ZSK. Change the status of the Published ZSK to Current. Change the status of the New ZSK to Published.

Zone

ZSK

KSK

Exp

Tag

Size

Creat

S

Tag

Size

Creat

S

zone.name

zsktag-cur

512

date

C

ksktag

1024

date

C

date

zsktag-pub

512

date

PC

zsktag-new

512

date

NP

    1. Sign with the KSK and Current ZSK

Follow steps 3.3 - 3.8 or steps 4.3 - 4.9 depending on whether the zone contains or does not contain delegations. The ZSK used in the signing process in section 3.6 (or 4.6) must be the key that is marked as the Current key (C) in the key-tag table (this was the older Published key). The KSK used as input to the operation does not change; hence the keyset does not change and does not have to be re-sent to the parent either.

Record the expiry date in the key-tag table.

Zone

ZSK

KSK

Exp

Tag

Size

Creat

S

Tag

Size

Creat

S

zone.name

zsktag-pub

512

date

C

ksktag

1024

date

C

date

zsktag-new

512

date

P

    1. Reload the zone

The name server process is assumed to be already running.

$rndc reload zone.name [ENTER]

The above command reloads the name server configuration files in addition to the zone contents.

    1. Dispose of the old zone key

Delete the old ZSK's .private and .key files.

    1. Make sure that sufficient time has elapsed since the last roll-over

The time between roll-overs has to be at least twice the maximum zone TTL period (the largest TTL in the zone file multiplied by two).

    1. Generate a new KSK

Follow steps in section 2 for generating a new KSK.

Update the key-tag table with the new KSK; set its status to Published (P).

Zone

ZSK

KSK

Exp

Tag

Size

Creat

S

Tag

Size

Creat

S

zone.name

zsktag-cur

512

date

C

ksktag-cur

1024

date

C

date

zsktag-pub

512

date

P

ksktag-pub

1024

date

P

    1. Include the new key in the zone file; change the SOA serial number

$vi zonefile [ENTER]

zone.name IN SOA servername contact (

2004042207 ;increase current value by 1

; note that this value may

; be different in your zone

; file

)

;; cur ksk

$INCLUDE “/path/to/Kzone.name.+005+ksktag-cur.key”

;; new ksk

$INCLUDE “/path/to/Kzone.name.+005+ksktag-pub.key

;; zsk

$INCLUDE “/path/to/Kzone.name.+005+zsktag-cur.key”

;; zsk

$INCLUDE “/path/to/Kzone.name.+005+zsktag-pub.key”

$

    1. Re-sign the zone DNSKEY RRset with the older and newer KSK

ZSKs sign the zone data, whereas KSKs sign the RRset for all DNSKEYs recognized by the zone. There is no direct way to create the signed DNSKEY RRset for the zone; it is only formed as a by-product of the dnssec-signzone operation. Follow steps 3.3 - 3.8 or steps 4.3 - 4.9 depending on whether the zone contains or does not contain delegations. The ZSK used in the signing process in section 3.6 (or 4.6) must be the key that is marked as the Current key (C) in the key-tag table. Both the KSKs ( the Current and the New) must be simultaneously included in the dnssec-signzone operation (two -k options).

Note: Although the keyset has changed, this must not be sent to the parent as yet.

Update the key-tag table with the expiration date for the signatures.

Zone

ZSK

KSK

Exp

Tag

Size

Creat

S

Tag

Size

Creat

S

zone.name

zsktag-cur

512

date

C

ksktag-cur

1024

date

C

date

zsktag-pub

512

date

P

ksktag-pub

1024

date

P

    1. Reload the zone

The name server process is assumed to be already running.

$rndc reload zone.name [ENTER]

The above command reloads the name server configuration files in addition to the zone contents.

    1. Wait for the old DNSKEY RRset in caches to expire and for the new value to propagate

Wait for at least twice the maximum zone TTL period (the largest TTL in the zone file multiplied by two).

    1. Remove the Current KSK from the zone file; change the SOA serial number

$vi zonefile [ENTER]

zone.name IN SOA servername contact (

2004042208 ;increase current value by 1

)

;; cur ksk

$INCLUDE “/path/to/Kzone.name.+005+ksktag-cur.key”

;; new ksk

$INCLUDE “/path/to/Kzone.name.+005+ksktag-pub.key”

;; zsk

$INCLUDE “/path/to/Kzone.name.+005+zsktag-cur.key”

;; zsk

$INCLUDE “/path/to/Kzone.name.+005+zsktag-pub.key”

$

    1. Re-sign the zone DNSKEY RRset with the Published KSK and the Current ZSK

ZSKs sign the zone data whereas KSKs signs the RRset for all DNSKEYs recognized by the zone. There is no direct way to create the signed DNSKEY RRset for the zone; it is only formed as a by-product of the dnssec-signzone operation.

Follow steps 3.3 - 3.8 or steps 4.3 - 4.9 depending on whether the zone contains or does not contain delegations. Provide the new KSK in the -k option. The ZSK used in the signing process in section 3.6 (or 4.6) must be the key that is marked as the Current key (C) in the key-tag table.

    1. Update the key-tag table with only the latest KSKs

Delete the current KSK. Change the status of the new KSK from Published (P) to Current (C). Update the expiration date for the signatures.

Zone

ZSK

KSK

Exp

Tag

Size

Creat

S

Tag

Size

Creat

S

zone.name

zsktag-cur

512

date

C

ksktag-cur

1024

date

C

Date

zsktag-pub

512

date

P

ksktag-pub

1024

date

P C

    1. Go to section 6 if this zone is a secure delegation from some other zone

The keyset generated in step 9.8 contains only the new KSK and this must be sent to the parent for completing the secure delegation.

    1. Reload the zone

The name server process is assumed to be already running.

$rndc reload zone.name [ENTER]

The above command reloads the name server configuration files in addition to the zone contents.

    1. Dispose of the old KSK

Delete the old KSK's .private and .key files.

NOTE: If the KSK is also compromised, do the Emergency KSK roll-over first. As long as there is a valid KSK signature over the ZSK, the KSK can continue to be used to inject false zone data. If both keys are compromised, clients are exposed to attacks on that data (signatures over false data, replay attacks of the old KSK, replay attacks of the old DS) until the maximum of the expiration of the KSK's RRSIG (created by the ZSK) and the parent's signature over the DS of that KSK. Short TTLs allow recursive servers to more quickly recover from key-compromise situations, allowing them to get new keys more quickly. However, key compromise exposes the secure recursive server to replays of the old key until the signature expires.

The emergency procedures described for key roll-over use the rationale that injection of valid but false data (which can be generated using the compromised key) is more serious than discontinuity in our ability to validate true data. Thus, during emergency ZSK roll-over, there will be a period (up to twice the maximim zone TTL) where the cached zone data may not validate against the new ZSK. Also, the below steps are only useful if the Published and Current keys are kept separate from each other and if the Published ZSK has not also been compromised. If both ZSKs are compromised follow steps in section 12. If only the Published key is compromised follow steps in section 11.

    1. Generate a new ZSK

Follow steps in section 1 for generating a new ZSK. Update the key-tag table with the new ZSK; set its status to New (N).

Zone

ZSK

KSK

Exp

Tag

Size

Creat

S

Tag

Size

Creat

S

zone.name

zsktag-cur

512

date

C

ksktag

1024

date

C

date

zsktag-pub

512

date

P

zsktag-new

512

date

N

    1. Replace the Current ZSK with the New ZSK; change the SOA serial number in the zone file

$vi zonefile [ENTER]

zone.name IN SOA servername contact (

2004042209 ;increase current value by 1

; note that this value may

; be different in your zone

; file

)

;; ksk

$INCLUDE “/path/to/Kzone.name.+005+ksktag.key”

;; old zsk

$INCLUDE “/path/to/Kzone.name.+005+zsktag-cur.key

;; pub zsk

$INCLUDE “/path/to/Kzone.name.+005+zsktag-pub.key”

;; new zsk

$INCLUDE “/path/to/Kzone.name.+005+zsktag-new.key

$

    1. Sign zone with the Published ZSK only

Follow steps 3.3 - 3.8 or steps 4.3 - 4.9 depending on whether the zone contains or does not contain delegations. The ZSK used in the signing process in section 3.6 (or 4.6) must be the key that is marked as the Published key (P) in the key-tag table. The KSK used as input to dnssec-signzone does not change; hence the keyset does not change and does not have to be re-sent to the parent either.

    1. Reload the zone

The name server process is assumed to be already running.

$rndc reload zone.name [ENTER]

The above command reloads the name server configuration files in addition to the zone contents.

    1. Update the key-tag table

Change the status of the Published key to Current. Change the status of the New key to Published.

Zone

ZSK

KSK

Exp

Tag

Size

Creat

S

Tag

Size

Creat

S

zone.name

zsktag-cur

512

date

C

ksktag

1024

date

C

date

zsktag-pub

512

date

PC

zsktag-new

512

date

NP

    1. Dispose of the old ZSK

Delete the old ZSK's .private and .key files.

NOTE: If the KSK is also compromised, do the Emergency KSK roll-over first. As long as there is a valid KSK signature over the ZSK, the KSK can continue to be used to inject false zone data. If both keys are compromised, clients are exposed to attacks on that data (signatures over false data, replay attacks of the old KSK, replay attacks of the old DS) until the maximum of the expiration of the KSK's RRSIG (created by the ZSK) and the parent's signature over the DS of that KSK. Short TTLs allow recursive servers to more quickly recover from key-compromise situations, allowing them to get new keys more quickly. However, key compromise exposes the secure recursive server to replays of the old key until the signature expires.

The emergency procedures described for key roll-over uses that rationale that injection of valid but false data (which can be generated using the compromised key) is more serious than discontinuity in our ability to validate true data. Thus, during emergency ZSK roll-over, there will be a period (up to twice the maximum zone TTL) where the cached zone data may not validate against the new ZSK.

    1. Generate a new ZSK

Follow steps in section 1 for generating a new ZSK. Update the key-tag table with the new ZSK; set its status to New (N).

Zone

ZSK

KSK

Exp

Tag

Size

Creat

S

Tag

Size

Creat

S

zone.name

zsktag-cur

512

date

C

ksktag

1024

date

C

date

zsktag-pub

512

date

P

zsktag-new

512

date

N

    1. Replace the Published ZSK with the New ZSK in the zone file; change the SOA serial number

$vi zonefile [ENTER]

zone.name IN SOA servername contact (

2004042210 ;increase current value by 1

; note that this value may

; be different in your zone

; file

)

;; ksk

$INCLUDE “/path/to/Kzone.name.+005+ksktag.key”

;; cur zsk

$INCLUDE “/path/to/Kzone.name.+005+zsktag-cur.key”

;; pub zsk

$INCLUDE “/path/to/Kzone.name.+005+zsktag-pub.key

;; new zsk

$INCLUDE “/path/to/Kzone.name.+005+zsktag-new.key

$

    1. Sign zone with the Current ZSK only

Follow steps 3.3 - 3.8 or steps 4.3 - 4.9 depending on whether the zone contains or does not contain delegations. The ZSK used in the signing process in section 3.6 (or 4.6) must be the key that is marked as the Current key (C) in the key-tag table. The KSK used as input to dnssec-signzone does not change; hence the keyset does not change and does not have to be re-sent to the parent either.

    1. Reload the zone

The name server process is assumed to be already running.

$rndc reload zone.name [ENTER]

The above command reloads the name server configuration files in addition to the zone contents.

    1. Update the key-tag table

Remove the older Published key from the key-tag table. Change the status of the New key to Published.

Zone

ZSK

KSK

Exp

Tag

Size

Creat

S

Tag

Size

Creat

S

zone.name

zsktag-cur

512

date

C

ksktag

1024

date

C

date

zsktag-pub

512

date

P

zsktag-new

512

date

NP

    1. Dispose of the old ZSK

Delete the old ZSK's .private and .key files.

The emergency procedures described for key roll-over use the rationale that injection of valid but false data (which can be generated using the compromised key) is more serious than discontinuity in our ability to validate true data. Thus, during emergency ZSK roll-over, there will be a period (up to twice the maximim zone TTL) where the cached zone data may not validate against the new ZSK.

    1. Generate new Current and Published ZSKs

Follow steps in section 1 in order to generate two ZSKs. Update the key-tag table with the new ZSKs; replace the existing set of ZSKs with the new values.

Zone

ZSK

KSK

Exp

Tag

Size

Creat

S

Tag

Size

Creat

S

zone.name

zsktag-cur

512

date

C

ksktag

1024

date

C

date

zsktag-pub

512

date

P

zsktag-cur

512

date

C

zsktag-pub

512

date

P

    1. Replace all existing ZSKs in the zone file with the new values; change the SOA serial number

$vi zonefile [ENTER]

zone.name IN SOA servername contact (

2004042211 ;increase current value by 1

; note that this value may

; be different in your zone

; file

)

;; ksk

$INCLUDE “/path/to/Kzone.name.+005+ksktag.key”

;; cur zsk

$INCLUDE “/path/to/Kzone.name.+005+zsktag-cur.key”

;; pub zsk

$INCLUDE “/path/to/Kzone.name.+005+zsktag-pub.key

;; cur zsk

$INCLUDE “/path/to/Kzone.name.+005+zsktag-cur.key”

;; pub zsk

$INCLUDE “/path/to/Kzone.name.+005+zsktag-pub.key

$

    1. Sign zone with the Current ZSK

Follow steps 3.3 - 3.8 or steps 4.3 - 4.9 depending on whether the zone contains or does not contain delegations. The ZSK used in the signing process in section 3.6 (or 4.6) must be the key that is marked as the Current key (C) in the key-tag table. The KSK used as input to dnssec-signzone does not change; hence the keyset does not change and does not have to be re-sent to the parent either.

    1. Reload the zone

The name server process is assumed to be already running.

$rndc reload zone.name [ENTER]

The above command reloads the name server configuration files in addition to the zone contents.

    1. Dispose of the old ZSKs

Delete the older ZSK's .private and .key files.

The emergency procedures described for key roll-over use the rationale that injection of valid but false data (which can be generated using the compromised key) is more serious than discontinuity in our ability to validate true data. Thus, during emergency KSK roll-over, there will be a period (up to twice the maximum zone TTL) where it may not be possible to build an “authentication chain” from the zone data to the new KSK.

    1. Inform parent about the KSK compromise

This must be done securely using out-of-band mechanisms.

    1. Ensure that the DS record for this zone has been removed from the parent zone

$dig @parent-IP-address DS zone.name [ENTER]

<<>> DiG 9.3.0 <<>> …

;; flags: qr aa rd; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 0

$

The authoritative flag (aa) must be set and no answer should be returned for the DS query.

    1. Generate a new KSK

Follow steps in Section 2 for generation of a new KSK. Update the key-tag table with the new KSK. Delete the older KSK. Mark the status of the new KSK as Current (C).

Zone

ZSK

KSK

Exp

Tag

Size

Creat

S

Tag

Size

Creat

S

Zone.name

zsktag-cur

512

Date

C

ksktag-old

1024

date

C

date

zsktag-pub

512

Date

P

ksktag-new

1024

date

C

    1. Replace the old KSK with new key in the zone file; change the SOA serial number

$vi zonefile [ENTER]

zone.name IN SOA servername contact (

2004042212 ;increase current value by 1

;that this value may be

;different in your zone file

)

;; old ksk

$INCLUDE “/path/to/Kzone.name.+005+ksktag-old.key

;; new ksk

$INCLUDE “/path/to/Kzone.name.+005+ksktag-new.key

;; pub zsk

$INCLUDE “/path/to/Kzone.name.+005+zsktag-pub.key”

;; new zsk

$INCLUDE “/path/to/Kzone.name.+005+zsktag-new.key”

$

    1. Regenerate the ZSKs

The ZSKs can no longer be trusted. Follow steps 12.1-12.2 to create a new ZSKs.

    1. Sign zone with the Current ZSK and the Current KSK

Follow steps 3.3 - 3.8 or steps 4.3 - 4.9 depending on whether the zone contains or does not contain delegations. The ZSK used in the signing process in section 3.6 (or 4.6) must be the key that is marked as the Current key (C) in the key-tag table. The KSK is the new key, which has been marked with the status Current.

    1. Go to section 6 if this zone is a secure delegation from some other zone

Send the keyset generated from the zone signing process in step 13.5 to the parent for completing the secure delegation.

    1. Reload the zone

The name server process is assumed to be already running.

$rndc reload zone.name [ENTER]

The above command reloads the name server configuration files in addition to the zone contents.

    1. Dispose of the old KSK

Delete the old KSK's .private and .key files.

During a KSK compromise the secure status of the child zone is dropped. This is done by deleting the DS record in the parent zone.

    1. Ensure that the notification of KSK compromise came from a secure channel

Authentication and communication between parent and child occurs out-of-band.

    1. Delete the child's keyset file at the parent

The DS record for the child should not be created. This can simply be achieved by not having the child's keyset file available to the dnssec-signzone process.

    1. Increase the zone SOA number

Although there is no change made to the unsigned zone file, the DS record for the child will no longer be present in the signed zone file, which amounts to a change. Thus, the zone serial number must be incremented.

$vi zonefile [ENTER]

zone.name IN SOA servername contact (

2004042213 ;increase current value by 1

; note that this value may

; be different in your zone

; file

)

$

    1. Sign the parent zone

Follow steps 4.3 - 4.9. The ZSK used in the signing process must be the key that is marked as the Current key (C) in the key-tag table. The KSK used as input to dnssec-signzone does not change; hence the keyset does not change and does not have to be re-sent to the parent.

    1. Reload the parent zone

$rndc reload zone.name [ENTER]

References

  1. O. Kolkman, R. Gieben, “DNSSEC Operational Practices”, draft-ietf-dnsop-dnssec-operational-practices-03 (work in progress), December 23, 2004

  2. TBD

Appendix A: Checklists

A.1 ZSK Generation

Correct dnssec-keygen version?

Correct key size?

Correct key expiration date?

Public and private keys are saved at the proper location with the correct set of permissions?

A.2 KSK Generation

Correct dnssec-keygen version?

Included the "-f KSK" option?

Correct key size?

Correct key expiration date?

Public and private keys are saved at the proper location with the correct set of permissions?

A.3 Zone Signing (no delegations)

Included ZSK and KSK in the zone file?

Increased the SOA serial number?

named-checkzone on the unsigned zone file returned OK?

Child keyset files (if any) are saved at the correct location?

Correct version of dnssec-signzone?

Correct signature expiry date?

named-checkzone on the signed zone file returned OK?

Keyset/DSset files are saved at the proper location?

A.4 Zone Signing (with delegations)

Included ZSK and KSK in the zone file?

Increased the SOA serial number?

named-checkzone on the unsigned zone file returned OK?

Child keyset files (if any) are saved at the correct location?

Correct version of dnssec-signzone?

Correct signature expiry date?

named-checkzone on the signed zone file returned OK?

DS records were generated (if zone contains secure delegations)?

A.5 Configuring and serving a signed zone

named configuration file lists the signed zone file for the zone?

dnssec-enabled is set to “yes”?

named-checkconf returned no errors?

The serial number for the SOA record (from dig) corresponds to the most recent SOA value that was entered in the zone file?

A.6 Delegation (Child Zone activity)

Keyset contains correct KSKs?

Keyset was securely sent to the parent?

Parent published the DS record?

A.7 Delegation (Parent zone activity)

Keysets were securely received from the child zones?

Keysets are for the correct zones?

Keysets are stored at the correct place with the correct set of permissions?

All checks in A.4 passed?

A.8 “Current” ZSK Roll-over (Pre-publish)

Sufficient time elapsed since the last ZSK roll-over?

Sufficient time elapsed between serving Zksk,zsk'[KSK, ZSK, ZSK'] and serving Zksk,zsk'[KSK, ZSK', ZSK'']

A.9 KSK Roll-over (Double signature)

Sufficient time elapsed since the last KSK roll-over?

Sufficient time elapsed between serving Zksk,ksk',zsk[KSK, KSK', ZSK, ZSK'] and serving Zksk',zsk[KSK', ZSK, ZSK']

If this is a child zone,

Steps in A.4 were followed?

Parent published the new DS record?

A.10 Emergency Current ZSK roll-over

New key was generated and added to the zone?

“Current” key removed from the zone?

SOA serial number was incremented?

Rolled over to Published key?

Set the status of the new key to Published?

A.11 Emergency Published ZSK roll-over

New key was generated and added to the zone?

“Published” key removed from the zone?

SOA serial number was incremented?

Re-signed the zone with the existing Current ZSK

Set the status of the new key to Published?

A.12 Emergency Current and Published ZSK roll-over

New keys were generated and added to the zone?

New Current and Published status has been set?

Older keys were removed from the zone?

SOA serial number was incremented?

Signed the zone with the new Current ZSK

A.13 Emergency KSK roll-over

Parent has been securely notified about KSK compromise?

Parent has stopped serving the child DS record?

New KSK generated?

New ZSKs generated?

Zone file updated with all new keys?

SOA serial number was incremented?

Signed the zone with the keys?

A.14 Parent action during child KSK compromise

Notification from child was authenticated?

DS for child no longer being served?

Appendix B: Key-tag Table Template

Zone

ZSK

KSK

Exp

Tag

Size

Creat

S

Tag

Size

Creat

S

Appendix C: Picture Illustrations for important DNSSEC operations

C.1 Key Generation

0x08 graphic
0x01 graphic

C.2 Signing zones that have no signed delegations present

0x08 graphic
0x01 graphic

C.3 Signing zones containing signed delegations

0x08 graphic
0x01 graphic

C.4 Signed delegations - child zone activity

0x08 graphic
0x01 graphic

C.5 Signing delegations - parent zone activity

0x08 graphic
0x01 graphic

C.6 Current” ZSK roll-over - pre-publish scheme

0x08 graphic
0x01 graphic

C.7 KSK roll-over - double signature scheme

0x08 graphic
0x01 graphic

C.8 Emergency Current ZSK roll-over

0x08 graphic
0x01 graphic

C.9 Emergency Published ZSK roll-over

0x08 graphic
0x01 graphic

C.10 Emergency KSK roll-over (Published and Current ZSK compromise)

0x08 graphic
0x01 graphic

C.11 Emergency KSK roll-over

0x08 graphic
0x01 graphic

The -cur and -pub tags for the zsk shown in the key-tag table and in other subsections are used for illustration purposes only.

The -cur and -pub tags for the zsk shown in the key-tag table and in other subsections are used for illustration purposes only.

The -cur, -pub and -new tags shown in the key-tag table and in other subsections are used for illustration purposes only.

We retain the -pub and -new tags in the above table and subsequent subsections even though the status for these keys have changed (Published is now Current and New is now Published) in order to reduce confusion. These tags, again, are used for illustration purposes only.

The -cur and -pub tags shown in the key-tag table and in other subsections are used for illustration purposes only.

We retain the -pub tag for the KSK in the key-tag table even though its status has changed (Published is now Current) in order reduce confusion. The -pub tag, again, is used for illustration purposes only.

The -cur, -pub and -new tags shown in the key-tag table and in other subsections are used for illustration purposes only.

The -cur, -pub and -new tags shown in the key-tag table are used for illustration purposes only.

The -cur, -pub and -new tags shown in the key-tag table and in other subsections are used for illustration purposes only.

The -cur, -pub and -new tags shown in the key-tag table are used for illustration purposes only.

The -cur and -pub tags shown in the key-tag table and in other subsections are used for illustration purposes only.

The -cur, -pub, -new and -old tags shown in the key-tag table and in other subsections are used for illustration purposes only.

Step-by-Step DNS Security Operator Guidance Document - Version 0.4

1

End

DSset File

1

KSK (private)

KSK (public)

2

Key Signing Key (KSK) Generation

ZSK (private)

ZSK (public)

Zone Signing Key (ZSK) Generation

Keyset File

Signed Zone File

End

Include public keys in zone file

3.6

3.3

Check Zone for errors

3

Checked Zone File (with keys)

Zone Signing operation

DSset File

private

public

private

private

public

public

Unsigned Zone File

2

Key Signing Key (KSK) Generation

1

Zone Signing Key (ZSK) Generation

Keyset File

Signed Zone File (with child's DS)

Include public keys in zone file

Start

Child Zone

Secure Exchange of the keyset file

Keyset File (from child)

Keyset File

End

Start

KSK

ZSK (Current and published)

KSK

ZSK (Current and published)

4.6

4.3

Check Zone for errors

4

Checked Zone File (with keys)

Unsigned Zone File

Zone Signing operation

2

Key Signing Key (KSK) Generation

1

Zone Signing Key (ZSK) Generation

3.6 or 4.6

Zone Signing operation

DSset

6.2

Parent Zone

6.3

Wait for the correct DS to appear

7

Create Delegation at parent

named process

Secure Exchange of the keyset file

Keyset File

Keyset File

7.1

Public keys at parent (ZSK and KSK)

Unsigned Parent Zone File (containing delegation to child)

named process

7.5

Reload the parent zone

DSset File

Keyset File

Signed Zone File (with child's DS)

7.4

Zone Signing Operation

Secure Exchange of the keyset file

Keyset File (from child)

Child Zone

Keyset File

Keyset

private key

KSK and current ZSK

End

End

Start

Unsigned Zone File

Start

public key

KSK and current ZSK

Keyset

DS set

Signed zone

Keyset

DS set

Signed zone

private

9.10

Unsigned zone

public

11.4

Reload the zone

Signed zone

8.5

Zone Signing Key (ZSK) Generation

Keyset

“Current” ZSK (public)

8.9

Reload the zone

8.8

Zone Signing Operation

8.4

Wait two max zone TTLs

8.3

Reload the zone

8.2

Zone Signing Operation

Private keys Published ZSK and current KSK

Public keys - published ZSK and current KSK

Parent Zone

Secure Exchange of the keyset file

named process

Secure delegation - parent zone activity

7

6.3

Wait for the correct DS to appear

6.2

Keyset

9.11

Reload the zone

End

Signed zone

DS set

Start

Old KSK (public)

Public keys - current and published ZSK

published(private)

Current and published ZSKs (private)

Unsigned Zone File

9.8

Zone Signing Operation

9.6

Wait two max zone TTLs

9.5

Reload the zone

Signed zone

Keyset

DS set

Old KSK (private)

9.4

Zone Signing Operation

private

public

9.2

Key Signing Key (KSK) Generation

End

Unsigned Zone File

Start

public key

KSK and published ZSK

private key

KSK and published ZSK

10.4

Reload the zone

Signed zone

Keyset

DS set

10.3

Zone Signing Operation

private

public

10.1

Zone Signing Key (ZSK) Generation

Published and current (public)

Current (private)

Parent action upon compromise notification

14

13.2

Wait for existing DS to disappear

6.2

Inform parent about KSK compromise

13.1

12.1

ZSK Generation

13.6

Sign the zone

Parent Zone

Secure Exchange of the keyset file

named process

Secure delegation - parent zone activity

7

End

Unsigned Zone File

Start

private

public

6.3

DS set

11.3

Zone Signing Operation

private

public

11.1

Zone Signing Key (ZSK) Generation

Wait for the correct DS to appear

Start

13.8

Reload the zone

Signed zone

DS set

13.3

Keyset

12.4

12.1

ZSK Generation

Published (private)

Published and current (public)

Key Signing Key (KSK) Generation

Current (private)

KSK (public)

KSK (private)

12.3

Sign the zone

Unsigned Zone File

Reload the zone

Signed zone

DS set

private

public

Secure exchange of information