How to Roll Over DNSSEC Keys and Update RRSIG Records

Learn how to roll over DNSSEC keys and update RRSIG records to maintain the security and integrity of your DNS zone.

DNSSEC is a protocol that adds cryptographic signatures to DNS records, allowing resolvers to verify the authenticity and integrity of the DNS responses they receive. However, DNSSEC also requires regular maintenance of the keys and signatures, which can be a complex and error-prone process. In this article, we will explain how to roll over DNSSEC keys and update RRSIG records, and what are the best practices to avoid common pitfalls.

What are DNSSEC keys and RRSIG records?

DNSSEC uses two types of keys to sign and validate DNS records: zone signing keys (ZSKs) and key signing keys (KSKs). ZSKs are used to sign the records in a DNS zone, while KSKs are used to sign the ZSKs. The public keys are published as DNSKEY records in the zone, and the private keys are kept secret by the zone operator.

RRSIG records are the signatures generated by the ZSKs for each record set (RRset) in the zone. An RRset is a group of records with the same name and type, such as all the A records for example.com. RRSIG records contain information such as the algorithm, the expiration date, and the signature itself. Resolvers can use the RRSIG records and the corresponding DNSKEY records to verify the authenticity and integrity of the DNS records they receive.

Why do DNSSEC keys and RRSIG records need to be rolled over?

DNSSEC keys and RRSIG records need to be rolled over periodically for two main reasons: security and operational.

Security-wise, rolling over keys and signatures reduces the risk of compromise and replay attacks. If an attacker manages to obtain a private key or a signature, they can use it to forge DNS responses and redirect traffic to malicious sites. By changing the keys and signatures frequently, the attacker’s window of opportunity is reduced, and the validity of the forged responses is limited.

Operationally, rolling over keys and signatures allows the zone operator to update the parameters of the DNSSEC configuration, such as the algorithm, the key length, or the signature lifetime. For example, if a new algorithm is standardized or an old one is deprecated, the zone operator can switch to the new algorithm by rolling over the keys and signatures.

How to roll over DNSSEC keys and update RRSIG records?

The process of rolling over DNSSEC keys and updating RRSIG records depends on the type of key and the rollover method. There are two types of key rollovers: ZSK rollover and KSK rollover. There are also two methods of rollover: pre-publish and double-signature. We will explain each of them in detail below.

ZSK rollover

A ZSK rollover is the process of replacing the ZSK pair (private and public) with a new one, and updating the RRSIG records accordingly. A ZSK rollover typically happens more frequently than a KSK rollover, because ZSKs are used more often and have shorter lifetimes. A ZSK rollover can be done using either the pre-publish or the double-signature method.

ZSK rollover Method 1: Pre-publish

The pre-publish method is the simplest and most common way to perform a ZSK rollover. It involves publishing the new ZSK as a DNSKEY record in the zone before using it to sign the RRsets. This way, the resolvers have enough time to learn about the new ZSK before they encounter the new signatures. The pre-publish method requires four steps:

1. Generate a new ZSK pair and publish the public key as a DNSKEY record in the zone, along with the old ZSK. The new ZSK should have a publish date in the past and an activate date in the future.
2. Wait for the publish period to pass. This is the time between the publish date and the activate date of the new ZSK, and it should be at least as long as the maximum TTL of the DNSKEY RRset.
3. Sign the RRsets in the zone with the new ZSK, and publish the new RRSIG records, along with the old ones. The new RRSIG records should have an inception date in the past and an expiration date in the future. The old RRSIG records should have an expiration date in the past.
4. Wait for the signature validity period to pass. This is the time between the inception date and the expiration date of the old RRSIG records, and it should be at least as long as the maximum TTL of any RRset in the zone.
5. Remove the old ZSK and the old RRSIG records from the zone.

ZSK rollover Method 2: Double-signature

The double-signature method is an alternative way to perform a ZSK rollover, which does not require a publish period. It involves signing the RRsets in the zone with both the old and the new ZSKs at the same time, and publishing both sets of RRSIG records. This way, the resolvers can verify the signatures with either ZSK, regardless of which one they have cached. The double-signature method requires three steps:

1. Generate a new ZSK pair and publish the public key as a DNSKEY record in the zone, along with the old ZSK. The new ZSK should have a publish date and an activate date in the past.
2. Sign the RRsets in the zone with both the old and the new ZSKs, and publish both sets of RRSIG records. The RRSIG records should have an inception date in the past and an expiration date in the future.
3. Wait for the signature validity period to pass. This is the time between the inception date and the expiration date of the RRSIG records, and it should be at least as long as the maximum TTL of any RRset in the zone.
4. Remove the old ZSK and the old RRSIG records from the zone.

KSK rollover

A KSK rollover is the process of replacing the KSK pair (private and public) with a new one, and updating the DS record in the parent zone accordingly. A KSK rollover typically happens less frequently than a ZSK rollover, because KSKs are used less often and have longer lifetimes. A KSK rollover can only be done using the pre-publish method, because the DS record in the parent zone cannot be double-signed.

KSK rollover Pre-publish method

The pre-publish method for a KSK rollover is similar to the one for a ZSK rollover, but it involves an additional step of updating the DS record in the parent zone. The DS record is a hash of the KSK that is published in the parent zone to establish a chain of trust between the zones. The pre-publish method for a KSK rollover requires five steps:

1. Generate a new KSK pair and publish the public key as a DNSKEY record in the zone, along with the old KSK. The new KSK should have a publish date in the past and an activate date in the future.
2. Wait for the publish period to pass. This is the time between the publish date and the activate date of the new KSK, and it should be at least as long as the maximum TTL of the DNSKEY RRset.
3. Generate a new DS record from the new KSK and send it to the parent zone operator. The parent zone operator should publish the new DS record, along with the old one.
4. Wait for the DS propagation period to pass. This is the time between the publication of the new DS record in the parent zone and its propagation to all resolvers. It should be at least as long as the maximum TTL of the DS RRset in the parent zone.
5. Remove the old KSK and the old DS record from the zone and the parent zone, respectively.

What are the best practices for rolling over DNSSEC keys and updating RRSIG records?

Rolling over DNSSEC keys and updating RRSIG records can be a challenging task, especially if done manually. There are many factors to consider, such as the timing, the synchronization, the communication, and the error handling. Here are some best practices to follow to ensure a smooth and successful rollover:

• Plan ahead and document the rollover process. Define the rollover method, the key parameters, the dates, the steps, and the responsibilities. Communicate the plan to all the parties involved, such as the zone operator, the parent zone operator, the registrar, and the hosting provider.
• Use automation tools and scripts to generate, sign, and publish the keys and signatures. This can reduce the human errors and the operational overhead. There are many tools available for DNSSEC management, such as dnssec-keygen, dnssec-signzone, dnssec-settime, and dnssec-revoke.
• Monitor and test the rollover process. Use tools such as dig, delv, and DNSViz to query and verify the DNSSEC records and signatures. Check for any errors, warnings, or anomalies in the DNSSEC validation and the DNS resolution. Resolve any issues as soon as possible.
• Be prepared for rollover failures and emergencies. Have a contingency plan and a backup of the keys and signatures. Know how to revert to the previous state or to roll forward to the new state. Have a communication channel and a notification system to inform the stakeholders and the users of any problems or changes.

Frequently Asked Questions (FAQs)

Question: What is the difference between ZSK and KSK?

Answer: ZSK stands for zone signing key, and KSK stands for key signing key. They are both types of DNSSEC keys that are used to sign and validate DNS records. The main difference is that ZSKs are used to sign the records in a zone, while KSKs are used to sign the ZSKs. The KSKs are also published as DS records in the parent zone to establish a chain of trust between the zones.

Question: How often should DNSSEC keys and RRSIG records be rolled over?

Answer: There is no definitive answer to this question, as different zones may have different requirements and preferences. However, some general guidelines are:

• ZSKs should be rolled over at least once a year, or more frequently if the security level or the operational needs demand it.
• KSKs should be rolled over at least once every five years, or more frequently if the algorithm or the key length needs to be updated.
• RRSIG records should have a validity period that is appropriate for the TTL and the volatility of the RRsets they sign. A common practice is to set the validity period to 2-4 times the TTL of the RRsets.

Question: What are the risks and challenges of rolling over DNSSEC keys and updating RRSIG records?

Answer: Rolling over DNSSEC keys and updating RRSIG records can introduce some risks and challenges, such as:

• Breaking the DNSSEC validation and causing DNS resolution failures if the keys or signatures are not synchronized, propagated, or verified correctly.
• Exposing the zone to security threats or operational issues if the keys or signatures are compromised, lost, corrupted, or outdated.
• Increasing the complexity and the overhead of the DNSSEC management and the DNS operations.

Summary

In this article, we have explained how to roll over DNSSEC keys and update RRSIG records, and what are the best practices to follow. We have also answered some frequently asked questions about the topic. We hope that this article has helped you to understand and perform the DNSSEC rollover process more easily and effectively.

Disclaimer: This article is for informational purposes only and does not constitute professional advice. The author and the publisher are not liable for any errors, omissions, or damages arising from the use of the information in this article. The user is responsible for verifying the accuracy and the applicability of the information before applying it to their own situation. The user should also consult with a qualified DNSSEC expert before performing any DNSSEC rollover operation.