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.
Scope of Document
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.
Conventions used in this document
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.
Organization of this document
The following procedures are described in the below-mentioned sections of this document:
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.
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.
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.
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.
Configuring and serving a signed zone
This section describes the procedure for serving a signed zone file.
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.
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.
“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.
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.
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.
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.
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.
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.
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.
Identifying Relevant Steps
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 |
Acknowledgements
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.
Comments
Please send any comments and corrections to sparta-dnssec AT tislabs DOT com
Zone Signing Key (ZSK) Generation
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].
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.
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:
Private key contained in Kzone.name.+005+zsktag.private
Public key contained in Kzone.name.+005+zsktag.key
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).
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.
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.
Key Signing Key (KSK) Generation
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].
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.
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:
Private key contained in Kzone.name.+005+ksktag.private
Public key contained in Kzone.name.+005+ksktag.key
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).
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.
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.
Signing a zone with no delegations
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.
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 |
|
|
|
|
|
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”
…
$
Check the zone file for errors
$named-checkzone zone.name zonefile [ENTER]
zone zone.name/IN: loaded serial SerialNumber
OK
$
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.
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.
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:
Signed zone file in zonefile.signed (the .signed is appended by default).
Keyset file in keyset-zone.name (this may have to be sent to the parent zone - see section 6)
DS-set file in dsset-zone.name (this is used to verify if the correct DS record was generated at the parent - see section 6)
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).
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 |
|
|
|
|
|
Check the zone file for errors
$named-checkzone zone.name zonefile.signed [ENTER]
zone zone.name/IN: loaded serial SerialNumber
OK
$
Signing a zone that has delegations
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.
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 |
|
|
|
|
|
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”
…
$
Check the zone file for errors
$named-checkzone zone.name zonefile [ENTER]
zone zone.name/IN: loaded serial SerialNumber
OK
$
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.
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.
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:
Signed zone file in zonefile.signed (the .signed is appended by default)
Keyset file in keyset-zone.name (this may have to be sent to the parent if this zone is also a child - see section 6)
DS-set file in dsset-zone.name (this is used to verify if the correct DS record was generated at the parent - see section 6)
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).
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 |
|
|
|
|
|
Check the zone file for errors
$named-checkzone zone.name zonefile.signed [ENTER]
zone zone.name/IN: loaded serial SerialNumber
OK
$
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.
Configuring and Serving a signed zone
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.
Enable DNSSEC
Add the “dnssec-enable yes;” option in the named.conf file.
$vi named.conf [ENTER]
…
options {
…
dnssec-enable yes;
};
…
$
Check the name server configuration file for errors
$named-checkconf named.conf [ENTER]
$
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.
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
…
)
…
$
Creating a signed delegation - Child Zone Activity
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
$
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.
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).
Creating a signed delegation - Parent Zone Activity
Ensure that the child keysets were received over a secure channel
Secure communication between the parent and child zone is done out-of-band.
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 …
…
$
Store all the child keysets in a separate directory.
This is simply to keep things clean.
Sign the zone
Sign the zone using steps described in section 4.
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.
“Current” ZSK Roll-over (Pre-publish scheme)
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.
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).
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 |
|
|
|
|
|
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.
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).
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 |
|
|
|
|
|
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”
…
$
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 |
|
|
|
|
ksktag |
1024 |
date |
C |
date |
|
zsktag-pub |
512 |
date |
|
|
|
|
|
|
|
zsktag-new |
512 |
date |
|
|
|
|
|
|
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 |
|
|
|
|
|
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.
Dispose of the old zone key
Delete the old ZSK's .private and .key files.
KSK Roll-over (Double Signature scheme)
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).
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 |
|
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”
…
$
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 |
|
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.
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).
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”
…
$
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.
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 |
|
|
|
|
Date |
|
zsktag-pub |
512 |
date |
P |
ksktag-pub |
1024 |
date |
|
|
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.
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.
Dispose of the old KSK
Delete the old KSK's .private and .key files.
Emergency ZSK roll-over (Current ZSK compromise)
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.
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 |
|
|
|
|
|
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”
…
$
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.
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.
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 |
|
|
|
|
ksktag |
1024 |
date |
C |
date |
|
zsktag-pub |
512 |
date |
|
|
|
|
|
|
|
zsktag-new |
512 |
date |
|
|
|
|
|
|
Dispose of the old ZSK
Delete the old ZSK's .private and .key files.
Emergency ZSK roll-over (Published ZSK compromise)
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.
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 |
|
|
|
|
|
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”
…
$
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.
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.
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-new |
512 |
date |
|
|
|
|
|
|
Dispose of the old ZSK
Delete the old ZSK's .private and .key files.
Emergency ZSK roll-over (Published and Current ZSK compromise)
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.
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 |
|
|
|
|
ksktag |
1024 |
date |
C |
date |
|
|
|
|
|
|
|
|
|
|
|
zsktag-cur |
512 |
date |
C |
|
|
|
|
|
|
zsktag-pub |
512 |
date |
P |
|
|
|
|
|
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”
…
$
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.
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.
Dispose of the old ZSKs
Delete the older ZSK's .private and .key files.
Emergency KSK Roll-over (KSK compromise)
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.
Inform parent about the KSK compromise
This must be done securely using out-of-band mechanisms.
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.
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 |
|
|
|
|
date |
|
zsktag-pub |
512 |
Date |
P |
ksktag-new |
1024 |
date |
C |
|
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”
…
$
Regenerate the ZSKs
The ZSKs can no longer be trusted. Follow steps 12.1-12.2 to create a new ZSKs.
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.
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.
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.
Dispose of the old KSK
Delete the old KSK's .private and .key files.
Parent action during child KSK compromise
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.
Ensure that the notification of KSK compromise came from a secure channel
Authentication and communication between parent and child occurs out-of-band.
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.
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
…
)
…
$
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.
Reload the parent zone
$rndc reload zone.name [ENTER]
References
O. Kolkman, R. Gieben, “DNSSEC Operational Practices”, draft-ietf-dnsop-dnssec-operational-practices-03 (work in progress), December 23, 2004
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)
ZA[B] represents a signed zone signed using keys listed in A, and containing keys listed in B in its apex DNSKEY-set.
ZSK, ZSK' and ZSK'' represent the current, published and new values of the zone signing key respectively.
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)
ZA[B] represents a signed zone signed using keys listed in A, and containing keys listed in B in its apex DNSKEY-set.
KSK and ZSK' represent the current and the new values of the key signing key respectively.
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
C.2 Signing zones that have no signed delegations present
C.3 Signing zones containing signed delegations
C.4 Signed delegations - child zone activity
C.5 Signing delegations - parent zone activity
C.6 “Current” ZSK roll-over - pre-publish scheme
C.7 KSK roll-over - double signature scheme
C.8 Emergency Current ZSK roll-over
C.9 Emergency Published ZSK roll-over
C.10 Emergency KSK roll-over (Published and Current ZSK compromise)
C.11 Emergency KSK roll-over
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