To assure data integrity and allow origin verification, DNSSEC (Domain Name System Extension) uses public key cryptography signatures. However, over time, the security of deployed keys decreases. The more time they are exposed to the world, the higher the chance they will eventually be compromised. So the key factor in maintaining the security of a DNSSEC environment is renewing keys on a regular basis. However, this is not a trivial task since DNS relies on cached information. A change made in a zone is not immediately reflected on every system that can resolve this zone, but it gradually propagates as outdated information about this zone expires from the caches of DNS resolvers. If we don’t take this effect into account, a simple key renewal may lead to temporary problems with resolving the zone. In fact, instead of “key renewal”, a more popular term is used in DNSSEC - “key rollover”. This is because every DNSSEC key renewal must consider all DNS time constraints, and therefore, it must be a process stretched in time rather than a single event.
To accommodate this challenge, different DNSSEC key rollover strategies have been developed to ensure that the trust between all parts of the DNSSEC environment is maintained at any one time. This article briefly describes the most common key rollover techniques.
The following article is the 3rd part of a longer series revolving around DNSSEC. If you are interested in learning more about DNS and DNSSEC basics, please visit the first article in the series – “Introduction to DNSSEC” (https://codilime.com/blog/introduction-to-dnssec/). If you want to get more familiar with DNSSEC configuration on BIND, you can check out our dedicated article covering this topic – “Practical implementation of DNSSEC” (https://codilime.com/blog/practical-implementation-dnssec/).
DNSSEC key types
Depending on the design choice, we may have several types of DNSSEC keys used for signing and validation purposes. Figure 1 depicts two possible scenarios:
- A DNSSEC zone with two keys: ZSK (Zone Signing Key) and KSK (Key Signing Key),
- A DNSSEC zone with only one key – CSK (Combined Signing Key).
In both of those scenarios, we can identify the following common components:
- RRset (resource record sets) - sets of records of the same type (e.g., A, NS), related to the same resource (name)
- RRSIG (resource record signature) - records containing a cryptographic signature of a specific RRset. The signature is created using a private DNSSEC key (KSK/ZSK/CSK, depending on the scenario and the type of the signed RRset).
- DNSKEY (DNS key) RRset - one or more records associated with the same domain containing public KSK/ZSK/CSK keys. These records are used to validate signatures maintained in the RRSIG records.
- DS (delegation signer) - contains a hash of KSK or CSK public key, used to create trust between a child domain and its parent.
For more information, please visit the first article in the DNSSEC series. (https://codilime.com/blog/introduction-to-dnssec/).
ZSK (Zone Signing Key) and KSK (Key Signing Key) pair
In the first scenario shown in Figure 1, the DNSKEY RRset is signed by the private KSK key. All other resource records in the zone are signed by the ZSK private key. The KSK public key is also used to maintain trust with the parent domain by means of a DS record. ZSK keys are recognized by the value 256 in the Flags Field of the DNSKEY record, while KSK keys have the number 257 assigned (see the output below with the DNSKEY RRset from a domain using a ZSK/KSK key pair).
$ dig @8.8.8.8 ns-testing.com. DNSKEY +dnssec +multiline
; <<>> DiG 9.11.5-P4-5.1-Debian <<>> @8.8.8.8 ns-testing.com. DNSKEY +dnssec +multiline
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 53395
;; flags: qr rd ra ad; QUERY: 1, ANSWER: 4, AUTHORITY: 0, ADDITIONAL: 1
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags: do; udp: 512
;; QUESTION SECTION:
;ns-testing.com. IN DNSKEY
;; ANSWER SECTION:
ns-testing.com. 600 IN DNSKEY 256 3 13 (
3fpXX5G0NaucQoYWgFQyT96UXMfxL6aiYpbevPAnUTjB
C8DajuvNcc8T2Rreaki4ajq4pAeRuXVEXbzaryKPHA==
) ; ZSK; alg = ECDSAP256SHA256 ; key id = 64664
ns-testing.com. 600 IN DNSKEY 257 3 13 (
xStQGvplWIM7roZyXLyKfkMWOSgVs5qcbwCoP0B0tlLW
dG+/pai0CPNu6Bs4UJaJtA1Q+YEpglSo/txjOGtzHg==
) ; KSK; alg = ECDSAP256SHA256 ; key id = 54249
ns-testing.com. 600 IN RRSIG DNSKEY 13 2 600 (
20241231092755 20241216082755 54249 ns-testing.com.
DHuRdzRAksmYPd9eU5rbSbvhbU0JerYIlBOm6qJ+1Y1q
wICkql5dYcuaIKaP0lWHI9qMIWemz1JF3saafa1CDA== )
;; Query time: 66 msec
;; SERVER: 8.8.8.8#53(8.8.8.8)
;; WHEN: Mon Dec 16 13:01:59 CET 2024
;; MSG SIZE rcvd: 393
CSK (Combined Signing Key)
In this case, we use only one key to sign both the DNSKEY and other resource records, as well as to maintain the trust with the parent domain (scenario 2 in Figure 1). This type of key is used by the default DNSSEC policy on BIND (one of the most popular DNS systems, covered in more detail in the previous article (https://codilime.com/blog/practical-implementation-dnssec/)). Like KSK, CSK keys have a value of 257 in the Flags Field within the DNSKEY record. The output below shows a DNSKEY RRset from a zone configured to use the CSK key.
$ dig @localhost test.com. DNSKEY +multiline
; <<>> DiG 9.18.18-0ubuntu0.22.04.2-Ubuntu <<>> @localhost test.com. DNSKEY +multiline
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 57106
;; flags: qr aa rd; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1
;; WARNING: recursion requested but not available
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 1232
; COOKIE: b562cd185c7711d501000000676999b5bbf10dc9866e399b (good)
;; QUESTION SECTION:
;test.com. IN DNSKEY
;; ANSWER SECTION:
test.com. 3600 IN DNSKEY 257 3 13 (
sHoeFI1XbevdGxqpNlXsJ/h/NepHR5qOoAy+bLBbXA0E
K6RhA8+GNMImLNHot0pu03MOfaz0A4Tib297e2vjCw==
) ; KSK; alg = ECDSAP256SHA256 ; key id = 64190
;; Query time: 0 msec
;; SERVER: 127.0.0.1#53(localhost) (UDP)
;; WHEN: Mon Dec 23 17:11:17 UTC 2024
;; MSG SIZE rcvd: 145
Although the single key concept is less complicated when it comes to implementation, the usage of two separate keys (ZSK and KSK) has some significant advantages during the key renewal (rollover) process. This is because the change of a combined key requires more effort and planning. This includes both interacting with the parent domain to maintain trust during the rollover process and making sure that, at any one time, all signed records are correctly validated by all the resolvers having access to the signed zone.
By using two separate keys, we can split the key rollover process into two less complicated subprocesses. The KSK rollover focuses on maintaining trust with the parent zone, while the ZSK rollover, which is a completely independent process, ensures that all resource records stay valid when the key is being replaced.
By having two separate keys, we can use different lengths of each key and therefore manage DNS server resources more granularly. The ZSK key, which is used more frequently, can be much shorter, at the cost of more frequent rollovers. On the other hand, the KSK key signs only one RRset (DNSKEY) and therefore is used less frequently, which allows using longer key lengths and storage methods with more access overhead, e.g., HSMs (Hardware Security Modules).
The third factor is the effort required to rollover a DNSSEC key. The ZSK rollover process can be easily automated since it is done internally within a DNS server. Changing the KSK key requires an interaction with the parent domain (installing a new DS record), which is, by default, a manual process. Having longer KSK keys allows us to implement longer key lifetimes without a significant impact on security. This way, the troublesome task of changing KSK keys can be less frequent.
However, lately, the choice between the single-key and double-key design has become less obvious with the significant growth in hardware performance and introduction of methods allowing automated interactions between parent and child zones (CDS/CDNSKEY records – more on that later).
DNSSEC key rollover strategies
ZSK rollover methods
The ZSK public/private key pair is used to sign and validate all resource records within a zone, except DNSKEY. So the main goal of any ZSK rollover strategy is to ensure that a resolver at any one time can successfully validate these resource records. RFC7583 (https://datatracker.ietf.org/doc/html/rfc7583 
) defines three ways of performing a ZSK rollover:
- Double-Signature – This is the most straightforward method of changing the ZSK key. As shown in Figure 2, a new public key is introduced to the zone (added to the DNSKEY RRset) and the new private ZSK key is immediately used to sign all other records, while retaining signatures created using the old key (step 1 in the Figure). This means that every RRset will have two RRSIG records associated – one associated with the old private ZSK key and one signed by the new key. Regardless of any version of DNSKEY and RRSIG that a potential resolver may have (before or after introducing the new ZSK), it should still be able to properly validate the response. After some time, when we are sure that all resolvers have updated their caches with the new information, we can remove the old key and all related signatures (step 2).
- Double-RRSIG – Depicted in Figure 3. Somewhat similar to the first method, however, in this case, we are not adding a new public ZSK key to the DNSKEY RRset, but only new RRSIG records (1). Old signatures are left intact at this point. For a resolver, to successfully validate a record, it is enough to have only one trusted signature. After some time, when we are sure that all resolvers have updated their caches with the new information, we can replace the old key in the DNSKEY RRset and remove all signatures related to the old private ZSK key (2).
- Pre-Publication – In this method (Figure 4), we start by introducing a new public key into the DNSKEY RRset, but without adding any new signatures (1). We wait until all resolvers learn about the new key. Next, we replace signatures of regular resource records (either gradually or all at once) (2). Resolvers, which already have information about the old and the new public ZSK key, should successfully validate records signed by either the old or the new private key. Finally, when all resource records are signed by the new key, and after waiting enough time to ensure that records signed by the old key have expired from caches, we can proceed with removing the old ZSK key from the DNSKEY RRset (3).
Of the three methods described above, the Pre-Publication seems to be the most complicated. However, it has one significant advantage, which makes it a preferable method for the ZSK rollover process. It allows keeping the responses as small as possible. Typically, only one signature is sent along with the requested record during the rollover process. In the case of the Double-Signature or Double-RRSIG method, we always get records with two signatures.
KSK rollover methods
The KSK private key is used to sign only one resource record set – DNSKEY. The key rollover strategies don’t need to consider having a large number of different resource records accompanied by their signatures. Instead, the main challenge during the rollover process is maintaining trust with the parent domain. Normally, this is done by installing a DS record in the parent domain. In such a case, every KSK rollover mechanism must include some way of interacting with the parent domain in order to replace the old DS record with the new one, containing a hash of the new public KSK key.
Similar to ZSK, RFC7583 (https://datatracker.ietf.org/doc/html/rfc7583 ) describes three ways to perform a KSK rollover:
- Double-KSK – In this scenario (Figure 5), a new public KSK key is added to the DNSKEY RRset, which is then signed by both the old and the new private key (1). After waiting some time for the old RRset to expire from caches, the DS record in the parent domain is changed, and from that moment it is associated with the new public KSK key (2). After additional time needed to propagate this change, the old KSK key is removed from the DNSKEY RRset (3), along with the associated RRSIG record.
- Double-DS – In this case (Figure 6), instead of publishing a new KSK key, we first introduce its DS record to the parent zone, while still keeping the old DS record (1). After the time needed to propagate this change into caches, the public KSK key is replaced in the DNSKEY RRset, accompanied by the new RRSIG signature (2). In the final step, the old DS record is removed from the parent domain (3).
- Double-RRset – This method (depicted on Figure 7) combines both strategies presented above. In the first step we add a new public KSK key to the DNSKEY RRset and a new DS record to the parent zone (1). After waiting a while to propagate this change, we proceed with removing the old KSK key, associated RRSIG signature and the DS record.
From the three presented methods, the first one (Double-KSK) keeps the interactions with the parent zone to a minimum (only one). The main advantage of the second method (Double-DS) is the minimal size of the DNSKEY RRset. Finally, the third method (Double-RRset) provides the fastest rollover time but has the drawbacks of the two other methods: a larger DNSKEY RRset and multiple interactions with the parent zone.
CSK rollover methods
Since the CSK key combines the roles of the ZSK and KSK keys, its rollover process must consider both the interaction with the parent zone and time constraints related to caching regular DNS records and their signatures. In practice, the CSK rollover strategy is usually a combination of one ZSK and one KSK method. BIND9, in its automated rollover process, uses a method that combines ZSK Pre-Publication with Double-KSK. The figure below depicts this scenario.
First, a new public CSK key is published and added to the DNSKEY RRset, already containing the old key. The DNSKEY is then signed by the old and the new private key (1). After meeting all the time constraints related to the propagation of this new version of the DNSKEY RRset, the DS record can be replaced, and at the same time, a gradual replacement of other signatures can begin (2). When all RRSIG records associated with the old CSK key are replaced and the downstream recursive servers don’t contain any cached entries related to the old key, it can be removed from the zone (3).
DNSSEC chain of trust maintenance automation
The biggest drawback of any KSK/CSK rollover process is the necessity of manual interaction with the parent domain. At a specific time, an operator is supposed to replace the DS record, e.g., using the registrar’s Web UI. This makes the whole process prone to human error and requires additional engagement from the administrators managing DNS servers. However, there is a method that allows automating these kinds of interactions by introducing additional record types, which are then read by the parent zone. Those new records are:
- CDS (Child DS) – has the same format as DS record and contains a hash of the public KSK/CSK key that should form a trust relationship with the parent zone:
$ dig @8.8.8.8 ns-testing.com. CDS +dnssec +multiline
; <<>> DiG 9.11.5-P4-5.1-Debian <<>> @8.8.8.8 ns-testing.com. CDS +dnssec +multiline
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 39363
;; flags: qr rd ra ad; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 1
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags: do; udp: 512
;; QUESTION SECTION:
;ns-testing.com. IN CDS
;; ANSWER SECTION:
ns-testing.com. 600 IN CDS 54249 13 2 (
6BEC2190EA809EF19FC39EE9FEF05FAAB32E6403847F
7D295B3B5F6A4C2E6112 )
ns-testing.com. 600 IN RRSIG CDS 13 2 600 (
20250112122755 20241228112755 54249 ns-testing.com.
4ygoHI8n0ZURXhQN9gp3aP0RsNSUUFaq9trAkbvKRfPf
yHde1teQ+TN/gRlGyDq1P6sRLLqy2tv58aQGHj2WYg== )
;; Query time: 81 msec
;; SERVER: 8.8.8.8#53(8.8.8.8)
;; WHEN: Wed Jan 01 12:51:58 CET 2025
;; MSG SIZE rcvd: 201
- CDNSKEY (Child DNSKEY) – has the same format as regular DNSKEY records and contains information about the KSK/CSK key that should form trust with the parent (ZSK records are excluded):
$ dig @8.8.8.8 ns-testing.com. CDNSKEY +dnssec +multiline
; <<>> DiG 9.11.5-P4-5.1-Debian <<>> @8.8.8.8 ns-testing.com. CDNSKEY +dnssec +multiline
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 64405
;; flags: qr rd ra ad; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 1
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags: do; udp: 512
;; QUESTION SECTION:
;ns-testing.com. IN CDNSKEY
;; ANSWER SECTION:
ns-testing.com. 600 IN CDNSKEY 257 3 13 (
xStQGvplWIM7roZyXLyKfkMWOSgVs5qcbwCoP0B0tlLW
dG+/pai0CPNu6Bs4UJaJtA1Q+YEpglSo/txjOGtzHg==
) ; KSK; alg = ECDSAP256SHA256 ; key id = 54249
ns-testing.com. 600 IN RRSIG CDNSKEY 13 2 600 (
20250112122755 20241228112755 54249 ns-testing.com.
coXqvOsRXMZy9so0oUYXQLDouGTSU9axHBQQbIn7uOV9
XZgSl9R5jmb7gtISszW+NNZA6VaBheARj8I4VB7pKg== )
;; Query time: 85 msec
;; SERVER: 8.8.8.8#53(8.8.8.8)
;; WHEN: Wed Jan 01 12:52:14 CET 2025
;; MSG SIZE rcvd: 233
The role of these records is to inform the parent zone about the desired DS record content that should be used by that parent. These records are optional and may or may not be used by the parent zone. On the other hand, the lack of these records on the child side simply means that there is no need to modify any information on the parent side. So, registrars who support this method may still work with DNS servers that are not capable of creating CDS/CDNSKEY records. This also means that when a parent and a child zone are in sync, CDS/CDNSKEY records may be removed from the child zone, which reduces the size of that zone and the workload on the parent side (if CDS/CDNSKEY records exist, their content needs to be constantly compared by the parent with the currently used data).
It is possible to derive information needed to create DS records from both record types (either directly from CDS records or indirectly by creating a hash of the public key found in a CDNSKEY record). It is up to the parent to choose which one will be used. There is also a special use case of the CDS/CDNSKEY record that allows the removal of DS records from the parent zones. This is done if CDS/CDNSKEY uses 0 as the cryptographic algorithm. The format of such a record must be as follows:
CDS 0 0 0 0
CDNSKEY 0 3 0 0
More information about CDS/CDNSKEY records can be found in RFC7344 (https://datatracker.ietf.org/doc/html/rfc7344 ) and RFC8078 (https://datatracker.ietf.org/doc/html/rfc8078 ). A practical example of using CDS/CDNSKEY records can be found here (https://blog.apnic.net/2021/11/02/dnssec-provisioning-automation-with-cds-cdnskey-in-the-real-world/ ).
Key takeaways
DNSSEC key maintenance is a complicated task but yet very important to maintain a high level of security. Although many related processes may be automated, a DNS administrator should still be aware of those processes and fully understand them. DNSSEC is not forgiving, and any incorrect step in the process of changing keys may lead to serious consequences, like breaking the chain of trust with the parent domain, or leaving users with responses signed by the wrong key. In any case, for hosts using DNSSEC validation, this means partial or even total zone unavailability.
In this article, we covered some of the most important topics related to DNSSEC key maintenance. First of all, we mentioned different types of keys and provided some reasoning for when to use them:
- ZSK (Zone Signing Key),
- KSK (Key Signing Key),
- CSK (Combined Signing Key).
We explained several standard DNSSEC key rollover strategies described in RFC7583 (https://datatracker.ietf.org/doc/html/rfc7583 ):
-
ZSK keys:
- Double-Signature
- Double-RRSIG
- Pre-Publication
-
KSK keys:
- Double-KSK
- Double-DS
- Double-RRset
-
CSK keys:
- a combination of Pre-Publication and Double-KSK
We also described CDS and CDNSKEY records as a way of automating trust maintenance between parent and child zones.
