DNSSEC on Microsoft DNS Server

Note: I have practically tested this on Windows Server 2016 and 2019.

The main description of DNSSEC is in the previous article DNSSEC - Domain Name System Security Extensions.

This article first describes specific details and principles for Microsoft - Microsoft and DNSSEC. The second part contains a practical description of zone signing, publishing the DS record with CZ.NIC, and key rollover - DNSSEC on an Authoritative DNS Server.

Microsoft and Domain Name System Security Extensions

Documentation

• Overview of DNSSEC

DNSSEC Support

Microsoft supports DNSSEC on the DNS Server role of the Windows server. It seems that not much has changed since Windows Server 2012 R2. In fact, there is no mention of it in the newer documentation. When enabling DNSSEC on Windows Server 2019, the documentation refers to the 2012 version.

DNSSEC support on the DNS server came with Windows Server 2008 R2, but only with offline signing. It was expanded in Windows Server 2012, where online signing of dynamic zones, support for NSEC3, RSA/SHA-2, and RFC 5011 were added. Signing keys are generated automatically, and automatic key rollover is supported. For zone signing, we can specify parameters or use the settings of another zone. When the zone is updated, it is automatically re-signed. If the zone is integrated into AD, the keys are automatically replicated.

For full DNSSEC functionality, we need:

• the primary authoritative DNS server must support zone signing
• the primary and secondary authoritative DNS servers must support hosting the signed zone
• the recursive DNS server must support DNSSEC validation of the DNS response

DNSSEC requires support for the EDNS0 extension, which supports large UDP packets in the DNS response. These must be able to pass through the entire network (they must not be blocked by active network devices).

DNS Client in Windows

• DNS Clients

Client-side support is available from Windows 7. The DNS client (even in the server OS) is DNSSEC-aware, meaning it supports DNSSEC, but does not perform validation. The exact designation is Non-Validating Security-Aware Stub Resolver. It can be configured to require DNSSEC verification from its DNS server. Even a client that does not support DNSSEC can be protected by DNSSEC if its DNS server performs the verification (it will not send the client a DNS response if the verification fails).

The DNS client in Windows does not automatically require validation of DNS responses. This must be specifically enabled for a particular namespace using the Name Resolution Policy. In the policy, you can set the requirement for verification for certain DNS zones (Namespace).

Description of The NRPT, Procedure: Review Name Resolution Policy Settings, Checklist: Deploy DNSSEC Policies to DNS Clients.

If the DNS Server has installed the Trust Anchor for a certain zone and has DNSSEC validation enabled, it will automatically try to verify the DNS response, even if it is not required in the NRPT Policy. So even a Non-Security-Aware Client is protected because it will not receive a response to an invalid record. If a zone is not signed (unsigned), a Trust Anchor must not be set for it on the DNS servers, otherwise the verification will always fail.

Microsoft DNS Server

Microsoft uses the following terms for the main two Name Server types:

• Authoritative DNS Server - a server that manages (and signs) records for a zone (domain)
• DNSSEC-aware Recursive (or Forwarding) DNS Server - (sometimes also Non-Authoritative DNS Server) a server that, when it receives a query for a signed zone from a DNS client, requests the DNSSEC records from the Authoritative DNS Server as well. It then attempts to perform signature verification.
  • it recognizes that the zone supports DNSSEC by the existence of the DNSKEY (Trust Anchor) for the zone
  • if verification is successful, it provides the answer
  • if not, it responds with the SERVFAIL message
  • if the DNS client is DNSSEC-aware, it can be configured to require the DNS server to perform DNSSEC validation

When a zone is signed using DNSSEC, the DNS Server automatically creates all DNSSEC records, except for the DS record. This must be created in the parent zone or in a child zone and propagated to the parent. NSEC or NSEC3 (which cannot be used together) are also automatically created.

The Microsoft DNS server or DNS zone can be:

• Active Directory-integrated - the server is in the domain, the data is stored in AD DS
• File-backed - a standalone server, the data is stored in a file (DNS database)

On the authoritative DNS server, we can create a domain (zone) that is:

• public, delegated on the internet - it belongs to the Internet namespace, which starts with the root zone (.), trust is handled within the DNS tree
• local, internal (non-public) - available only on the internal network, we run a separate namespace (Private DNS zone) on local DNS servers, where the root DNS server is

When operating a Microsoft DNS Server on an internal network, it often serves as recursive for DNS queries from internal clients (it is set as their DNS server in the TCP/IP network adapter settings), but also as authoritative for a certain internal or public domain.

For our DNS server to verify domains on the internet, we must install the root Root Trust Anchor (.) and enable DNSSEC Validation. Otherwise, we can install a Trust Anchor only for a selected zone.

Key Master

Key Master is the DNS server responsible for generating and managing the keys for a signed zone using DNSSEC. Only one DNS server for a given zone can be the Key Master, and it must be the primary authoritative server. One server can be the Key Master for multiple zones. The Key Master function can be moved to another DNS server (that meets the requirements).

RFC 5011

Microsoft supports RFC 5011 for updating Trust Anchors within defined Trust Points (when acting as a recursive DNS Server - Resolver) and also for key rollover on a signed zone (when acting as an authoritative DNS Server). The description of this RFC seems rather vague to me, but I've tried to outline some of the main points as I understood them.

The document describes means for automated, authenticated, and authorized DNSSEC Trust Anchor updates. Based on the trust established by the presence of the current Trust Anchor, additional Trust Anchors can be added further up the hierarchy, and eventually replace the existing one.

It adds a new flag (Flag/bit) to the DNSKEY record called REVOKE (bit 8). A key marked with this flag must not be used by the Resolver as a Trust Anchor (it can only be used to verify the DNSKEY signature for the purpose of verifying the revocation). A DNSKEY with the REVOKE bit set has a different digest (and thus Key Tag) than a key without the bit set. This affects the DNSKEY-DS match in the parent zone.

• (Remove) Hold-Down Time - adds a delay where the Resolver accepts a new (or removes an old) Trust Anchor only after (typically) 30 days have elapsed
• Active Refresh - a Resolver set to automatically update keys from a certain Trust Point must query (find the set of DNSKEY records and their signature) at least once an hour, but at least once every 15 days (or half the TTL for DNSKEY or half the signature expiration interval).

Considerations for Enabling DNSSEC for a Domain

Public DNS zones that are connected to the internet (not part of AD DS) and must be publicly accessible are particularly vulnerable to attack. Therefore, it is often worth deploying DNSSEC for them. The significance of the domain must be considered.

Internal DNS zones used for the AD DS domain are usually less vulnerable to attacks because they are not exposed to the internet or are protected by other security mechanisms. Therefore, the administrative burden associated with running DNSSEC may not be worth it.

DNSSEC deployment means adding many records (increasing the size of the zone) and requires encryption and decryption of records. It has an impact on the performance of the DNS infrastructure and increases the administrative burden. The length of the cryptographic keys affects the ability to be compromised by a Brute Force Attack versus a greater impact on performance. Description of DNSSEC Performance Considerations.

Enabling DNSSEC on the DNS Server

Initially, I thought it was just about enabling DNSSEC validation on the DNS server. But in practice, I found that the configuration (activation) is common for the entire DNSSEC operation. If DNSSEC is not enabled on the DNS server, we can still sign the zone, but the server will not return the signatures (DNSSEC records) when queried.

On Windows Server 2012 R2, it was possible to configure using the DNS Manager in the properties of the DNS server on the Advanced tab, the item Enable DNSSEC validation for remote responses. In newer versions, we must use the command line, either a PowerShell cmdlet or the dnscmd command.

Checking the status to see if DNSSEC is enabled.

PS C:\> Get-DnsServerSetting | FL EnableDnsSec
EnableDnsSec : False

C:\>dnscmd /info /enablednssec
Query result:
Dword:  0 (00000000)
Command completed successfully.

Under certain conditions, DNSSEC is automatically enabled. Or we can perform manual activation (the easier way is using the dnscmd command).

$a = Get-DnsServerSetting -All
$a.EnableDnsSec = 1
$a | Set-DnsServerSetting

DnsCmd.exe /Config /enablednssec 1

DNS queries (and NRPT) using PowerShell

For DNSSEC DNS queries, we cannot use nslookup, but there is a PowerShell cmdlet Resolve-DnsName with the DnssecOk parameter.

PS C:\> Resolve-DnsName -name www.seznam.cz -type A -Server 8.8.8.8 -DnssecOk 

Name                                           Type   TTL   Section    IPAddress                                
----                                           ----   ---   -------    ---------                                
www.seznam.cz                                  A      299   Answer     77.75.75.172                             
www.seznam.cz                                  A      299   Answer     77.75.74.172                             

Name        : www.seznam.cz
QueryType   : RRSIG
TTL         : 299
Section     : Answer
TypeCovered : A
Algorithm   : 13
LabelCount  : 3
OriginalTtl : 300
Expiration  : 25.01.2022 6:40:29
Signed      : 11.01.2022 5:10:29
Signer      : seznam.cz
Signature   : {156, 187, 169, 33...}
 
Name      : .
QueryType : OPT
TTL       : 32768
Section   : Additional
Data      : {}

In the example above, the client requests DNSSEC information, but not response verification, because the Name Resolution Policy Table (NRPT) is not set to require it.

We can list the policy with the following command, if it is not set (using Group Policy), the result will be empty.

Get-DnsClientNrptPolicy

If the policy exists, we can modify the values for a specific NameSpace. For example, to require verification (if set, the DNS query will always have the DO bit set, even if the DnssecOk parameter is not used)

(Get-DnsClientNrptPolicy -NameSpace secure.contoso.com).DnsSecValidationRequired

Trust Anchors and Trust Points

Microsoft uses the term Trust Anchor a lot, and in some places (even interchangeably) the term Trust Point. It describes that it is a public cryptographic key for a signed zone (i.e., obtaining trust in the signatures in that zone). It can be a DNSKEY Trust Anchor, a public key from a DNSKEY record (Keyset - DNSKEYset), or a DS Trust Anchor, a DSset hash of the public key (as in Microsoft documentation, but correctly it is a hash of the DNSKEY record).

The Trust Anchor must be set on each non-authoritative (recursive) DNS server that attempts to verify the signed zone data. Thanks to the Chain of Trust, the root Trust Anchor is sufficient. The authoritative DNS server (hosting the given zone) does not need it for verification, as it trusts its own records (it does not verify its own records).

Delegation is the transfer of authority from one DNS server to another DNS server for a certain namespace. Delegation is commonly used to assign permissions for subordinate zones. For DNSSEC, delegation is done using the DS record, thereby creating a chain of trust.

On the authoritative DNS server, where we sign the zone using DNSSEC and which is also the Key Master, the Trust Anchors are automatically stored in the text files dsset-<zone.name> and keyset-<zone.name> in %windir%\system32\dns\. If it is a public domain on the internet (or there is a parent domain), we must insert the Trust Anchor (as a DS record) into the parent zone.

Trust Points for Validation

I understand a Trust Point as a configured Trust Anchor for verifying a certain zone. Or in other words, a container for a domain that contains the Trust Anchor and performs their automated renewal. It is set on the validating DNS server (DNSSEC-aware Recursive DNS Server with DNSSEC validation enabled). It then performs signature verification for all zones for which it has a Trust Point. If we want to verify DNSSEC on the internet, we must create a Root Trust Point.

We can manage Trust Points on a DNS server with DNSSEC validation enabled using the DNS Manager in the Trust Points container. If the DNS server is integrated into AD DS (and running on a domain controller), the Trust Anchors are stored within the Forest and replicated to all DNS servers running on the DCs. On a standalone DNS server, they are stored in the file %windir%\system32\dns\TrustAnchors.dns (local Trust Anchor Store).

Displaying Trust Points

On a DNS server with DNSSEC validation enabled, we can view the list of Trust Points (we see when they were last refreshed).

Get-DnsServerTrustPoint

Displaying Trust Anchors

For each Trust Point, we can display its Trust Anchors.

Get-DnsServerTrustAnchor -Name firma.cz

Exporting Trust Anchors

Since the DSset and Keyset Trust Anchors are automatically stored in a text file, we can just copy the files, which we can then use to import into the parent zone.

Or we can use a PowerShell cmdlet (the first is for exporting DNSKEY and the second for DS).

Export-DnsServerDnsSecPublicKey -ComputerName DC2.firma.cz -ZoneName sec.firma.cz -Path \\Myshare\keys
Export-DnsServerDnsSecPublicKey -ComputerName DC2.firma.cz -ZoneName sec.firma.cz -Path \\Myshare\keys -DigestType sha256

Importing or Creating Trust Points (Trust Anchors)

• Procedure: Import a Trust Point

On a validating DNS server, we can import a Trust Point using the DNS Manager:

• right-click on the Trust Points container
• under Import, choose DNSKEY or DS
• select the file

Similarly, we can create a record manually:

• right-click on the Trust Points container
• under Add, choose DNSKEY or DS
• enter the values

Or we can use a PowerShell cmdlet.

Import-DnsServerTrustAnchor -KeySetFile \\File1\DNSKeys\keyset-sec.firma.cz
Import-DnsServerTrustAnchor -DSSetFile \\File1\DNSKeys\dsset-sec.firma.cz

Importing the DS Record (Trust Anchor)

The DS record is not automatically created on the parent DNS server. We can add it manually or import the created file with the DS record set (DSset).

Import-DnsServerResourceRecordDS -ZoneName firma.cz -DSSetFile "c:\windows\system32\dns\dsset-firma.cz"

Deploying the Root Trust Point

• Procedure: Deploy a Root Trust Point, Updating of DNS Validating Resolvers with the Latest Trust Anchor

If we want our DNS server to verify DNSSEC for the internet, we must add a Trust Point for the root zone (.), i.e., the IANA Root Trust Anchor. We won't use this method if we only want to verify DNSSEC in our network, where the local DNS server is the root server.

For deployment, the IANA URL set in the DNS server parameters is used. We can check the settings

PS C:\> Get-DnsServerSetting -All | Select RootTrustAnchorsURL
RootTrustAnchorsURL
-------------------
https://data.iana.org/root-anchors/root-anchors.xml

Adding the Root Trust Point. After creating it, the current DNSKEY record is automatically downloaded and the Trust Anchor is updated. It supports RFC 5011 for automatic Trust Anchor updates, where the existing Trust Anchors can be used to verify the new one.

Add-DnsServerTrustAnchor -Root

DNSSEC on the Authoritative DNS Server

Let's look at a situation where we are the holder of a public domain on the internet and operate our own DNS server running on a Microsoft DNS server. When we want to secure this domain using DNSSEC, we must:

• sign the zone (the firma.cz domain)
• publish the DS record with the parent authority (to the TLD domain, CZ.NIC)
• when the KSK key changes, update the DS record

Signing the Zone

• DNS Zone - Zone Signing Wizard

Signing records can be activated for a specific zone (domain name - domain). When signing a zone on a Microsoft DNS server, we must first set up a number of parameters. The basis is generating ZSK and KSK key pairs. We can set automatic key rollover for them, so that new keys are generated and swapped after a specified number of days. After activation, the necessary DNSSEC records (DNSKEY, NSEC3, NSEC3PARAM, RRSIG) are created, and all existing records are signed (an RRSIG record is created for them). When a new record is created, it is immediately signed. During automatic ZSK rollover, all records are re-signed.

We can sign the zone using PowerShell cmdlets or the wizard in DNS Manager, which we will focus on. We can also display and edit the set parameters and unsign the zone. The DNS Manager shows the signed zone with a lock. The list shows the signed state and indicates who the Key Master is.

• in the DNS Manager console, use the Zone Signing Wizard
• right-click on the selected zone and choose DNSSEC - Sign the Zone

The wizard includes the following steps

• Signing options - choose Customize zone signing parameters
• Key Master - choose The DNS server … is the Key Master
• Key Signing Key (KSK) - add a new key
• Zone Signing Key (ZSK) - add a new key
• Next Secure (NSEC) - choose Use NSEC3
• Trust Anchors (TAs)
• Signing and Polling Parameters
• a summary of the set parameters is displayed
• complete the wizard and the entire zone will be signed

We'll describe some of the steps in a bit more detail.

Signing options

To set the DNSSEC parameter values, we can use

• Customize zone signing parameters - enter custom parameters
• Sign the zone with parameters of an existing zone - use the parameters of an existing zone
• Use default settings to sign the zone - use the default parameters

Key Signing Key (KSK)

We must use at least one KSK and one ZSK. If we enable automatic key rollover, another signing key will be generated for each ZSK and KSK. For the KSK, the double signature rollover method is supported, and for the ZSK, the pre-publish rollover method.

The KSK is used to sign the keys (DNSKEY records).

• DNSKEY RRSET signature validity period - the validity period of signatures using the KSK (i.e., the DNSKEY record set), default 168 hours (the documentation states 72)
• Key Rollover - automatic key rollover, we specify the frequency, default 755 days (a shorter period is recommended)

Zone Signing Key (ZSK)

The ZSK signs the data in the zone. It changes more frequently and can have a shorter key length than the KSK.

• we set the validity period of the signatures for certain record types
  • DNSKEY signature validity period (168 hours)
  • DS signature validity period (168 hours)
  • Zone record validity period (240 hours) - what is the validity of the signatures of records in the zone, here 10 days (in practice, e.g., 14 days)
• Key Rollover - automatic key rollover, we specify the frequency, default 90 days (a shorter period is recommended)

Trust Anchors (TAs)

• Enable the distribution of trust anchors for this zone

If we enable this, and the DNS server is a domain controller, the Trust Anchor is distributed to all DNS servers running on DCs in the same Forest. If it's not a DC, it's stored in the local Trust Anchor Store %windir%\system32\dns\TrustAnchors.dns. Trust Anchors are not needed for DNS servers that are authoritative for the zone. Within the AD forest, we should only enable it if other DNS servers (running on DCs) will provide non-authoritative responses for the zone with DNSSEC.

• Enable automatic update of trust anchors on key rollover (RFC 5011)

When enabled, the RFC 5011 procedure is followed during key rollover (described at the end of the article). In PowerShell, it's called EnableRfc5011KeyRollover. (Automatic) update (distribution) of Trust Anchors takes place. According to the mention in the documentation, the configuration is stored in %windir%\system32\dns\RFC5011.csv, but I haven't seen such a file anywhere.

From observations in practice: If it's not checked, only one KSK key will be created when the zone is signed. Key rollover happens quickly within an hour (a new key is added, records are signed, the old one is removed).

Signing and Polling Parameters

During zone signing (key rollover), a file with the DS record set (DSset) and Keyset (DNSKEY record set) is automatically created. The values used for their creation are:

• DS record generation algorithm
• DS record TTL
• DNSKEY record TTL

Additional configurable parameters:

• Secure delegation polling period - how often the parent zone queries the DNSSEC-signed subordinate (I would guess this is the interval at which it queries the DS record in the parent zone during KSK rollover, but I couldn't find a proper description)
• Signature inception - how many hours earlier the created signature is valid

Completing the Zone Signing

We will see a summary of the entered parameters (which we can copy) and click Finish to complete the wizard. Immediately, the zone will be signed. To see the result, we may need to perform a Refresh in the DNS Manager.

Two KSK keys and two ZSK keys are created, and a DNSKEY record is created for each (a total of 4). The entire DNSKEY record set is signed with the private key of the active KSK. The Microsoft DNS server also signs the DNSKEY record set with the private key of the active ZSK. From my understanding of DNSSEC, I would think this shouldn't happen. But maybe the information that all record sets in the zone are signed using the ZSK also means the DNSKEY. Conversely, I would expect the DNSKEY to be signed using the backup KSK as well, since the double signature rollover method is to be used for KSK rollover.

I tried queries on various signed domains on the internet. Most of them have one published KSK and one ZSK, and only one DNSKEY set signature using the KSK. Some domains have signatures using the ZSK as well.

Information about the DNSSEC zone settings can also be retrieved using PowerShell.

Get-DnsServerDnsSecZoneSetting -ZoneName firma.cz

Publishing DS Records in the .cz Domain Registry

To create DS records in the TLD domain (registry), we must use our registrar. In the registry for the CZ domain, the DS records are generated automatically from the signing key data. A KEYSET (key set) must be created, the complete DNSKEY record data inserted into it, and it must be attached to your domain. How it works with the registrar Active24 is described in DNS Security (DNSSEC).

The actual process of creating a DS record

• on the DNS server, open the file %windir%\system32\dns\keyset-<zone.name> (e.g., C:\Windows\System32\dns\keyset-firma.cz), where we have all the necessary data (for all keys) to create the KEYSET
• in the registrar's web system (changes in the registry) create a new KEYSET for the .CZ domain
• we must enter a unique name (KEYSET ID), technical contact, Flag 257 (KSK), algorithm, protocol 3 (DNSSEC) and the public KSK key
• we can enter multiple keys in one KEYSET (in the case of Microsoft DNS, we enter two)
• after a while, we receive an email confirmation from CZ.NIC that the KEYSET has been created
• in the registrar's web system (changes in the registry), we enter the change on the domain, where we assign the KEYSET to the domain, the operation must be confirmed by the holder or admin (link in the email)
• after a short time (15 minutes), we receive confirmation from CZ.NIC that the change on the domain has been made
• when searching for the domain in the registry (https://www.nic.cz), we should see that it is secured using DNSSEC, and also the assigned key set (and its data)

Automatic Key Rollover

Key rollover is important and must be performed correctly, otherwise the domain may stop working. Doing it manually is quite cumbersome, so it's better to use Automatic Rollover. It's safer to perform automatic KSK key rollover using RFC 5011 (which is our focus here). ZSK rollover is fully automatic, but when rolling over the KSK, we need to manually update the data with CZ.NIC.

If we enable automatic key rollover with RFC 5011, another signing key is immediately generated for each ZSK and KSK when the zone is signed. We then always have an active key (Active key). And for the KSK, we also have a standby key (Standby key), and for the ZSK, a next key (Next key) is created.

For the KSK, the double signature rollover method is supported, and for the ZSK, the pre-publish rollover method.

• Double Signature - the future key and signatures generated using it are published in the DNS zone before removing the existing key and its signatures, there are always two sets of keys and related signatures in the zone, during key rollover we make the active one from it, remove the old one including the signatures, and add a new standby key and signatures
• Pre-Publication - the future key is added for future use and published in the DNS zone without generating any signatures, so its record is distributed, during key rollover we make it the active one and sign the records in the zone with it, and prepare a new standby key

Unfortunately, I couldn't find an exact description of how the automatic key rollover works. I tried to observe it in practice and describe it below. With RFC 5011 enabled, the description in RFC 5011 Key Roll-Over should be used. To get an overview of how the key rollover is performed, the event log is the most helpful. The events logged during various operations are listed at the end of the article.

Key Rollover Information

Using PowerShell, we can list the signing keys (or a specific key) for a given zone. Various data is displayed, including the state and other key rollover parameters.

Get-DnsServerSigningKey -ZoneName firma.cz
Get-DnsServerSigningKey -ZoneName firma.cz -KeyId d7a93f55-31b9-46a7-8057-f7cf3625f7de | FL *
Get-DnsServerSigningKey -ZoneName firma.cz | FT KeyType, CurrentState, CurrentRolloverStatus, NextRolloverAction, NextRolloverTime, LastRolloverTime, RolloverType

PS C:\> Get-DnsServerSigningKey -ZoneName firma.cz | FT KeyType, CurrentState, CurrentRolloverStatus, NextRolloverAction, NextRolloverTime, LastRolloverTime, RolloverType

KeyType        CurrentState CurrentRolloverStatus           NextRolloverAction NextRolloverTime    LastRolloverTime RolloverType
-------        ------------ ---------------------           ------------------ ----------------    ---------------- ------------
KeySigningKey  Active       WaitingForRFC5011RemoveHoldDown Normal             3/9/2022 5:21:32 PM                  DoubleSignature
ZoneSigningKey Active       Queued                          Normal             2/1/2022 7:55:30 AM                  PrePublish

Rollover State

The key rollover state (CurrentRolloverStatus) is important. Unfortunately, I couldn't find any explanations, only a list of possible values (and I would say with some errors).

• NotRolling
• Queued
• RollStarted
• ZskWaitingForDnsKeyTtl
• ZskWaitingForMaxZoneTtl
• KskWaitingForDSUpdate
• KskWaitingForDSTtl
• KskWaitingForDnsKeyTtl
• WaitingForRFC5011RemoveHoldDown
• RollError

Before the time for key rollover arrives, the state is NotRolling.

When ZSK is being renewed, the DNS server waits at least 1 hour (3600 seconds) to allow cached records to expire. If the DNSKEY TTL or the maximum TTL used on another record in the zone is longer than an hour, it waits longer (ZskWaitingForDnsKeyTtl, ZskWaitingForMaxZoneTtl).

When KSK is being renewed, the DNS server waits for the DS record to be updated in the parent zone (which it checks at regular intervals). The state is displayed as KskWaitingForDSUpdate. We can manually proceed to the next step (if the server, for example, cannot verify the DS record) using the Step-DnsServerSigningKeyrollover cmdlet. Then the process reaches the WaitingForRFC5011RemoveHoldDown state, which is 30 days according to RFC 5011.

KSK Key Rollover Process (RFC 5011) and Changing the DS Records in the .cz Domain Registry

• we have an Active key and a Standby key, when the time for key rollover arrives (we see it as NextRolloverTime), a new KSK is generated as the Next key
• its DNSKEY record is created, the state switches to RollStarted

• then we wait until the corresponding DS record for the new key is created in the parent zone, the state is KskWaitingForDSUpdate
• in the registrar's web system (changes in the registry), we edit the KEYSET for the .CZ domain, where we add the new key, which we can find again in the file %windir%\system32\dns\keyset-<zone.name>, the change must be confirmed (link in the email)
• after a few minutes, we receive an email confirmation from CZ.NIC that the KEYSET has been changed
• when the DNS server verifies that the correct record exists, it switches to the KskWaitingForDSTtl state
• after the time expires (default 1 hour), it switches to WaitingForRFC5011RemoveHoldDown
• sometime during this period, a new signature of the DNSKEY record set is created using the standby KSK (Standby key), and the DNSKEY record with the active KSK (Active key) has its flag (from 257) changed to 385 (the Revoke bit is set), which also changes its Key Tag

• now the Hold-Down Time is running, the originally active key (Active key) is revoked, the standby (Standby key) becomes the active one, and the next key (Next key) will become the standby after the time expires
• after the Hold-Down Time expires, typically 30 days, the oldest key (originally active - Active key) and its DNSKEY record (and the signature using it) are removed, the standby (Standby key) becomes the active (Active key), and the next key (Next key) becomes the standby (Standby key)
• we remove the key from the KEYSET at CZ.NIC (i.e., the old DS record)

Note: It's unclear to me what the purpose is of keeping the DS record for the old key during the Hold-Down Time. Since the flag on the DNSKEY record has changed, the hash in the DS record no longer matches this DNSKEY.

ZSK Key Rollover Process

• we have an Active key and a Next key, when the time for key rollover arrives (we see it as NextRolloverTime), a new key is generated
• the Active key becomes the Standby key, the Next key becomes the Active key, and the new key is set as the Next key
• the set of DNSKEY records is re-signed using the Active key
• we wait for the max Zone TTL
• a DNSKEY record is created for the new key (Next key) and the oldest DNSKEY record (Standby key) is removed
• the Standby key is deleted, so we have the Active key and the Next key again

Logged Events in Various Situations

Interesting information can be found in the event log (Event Log) of the DNS Server. It can be found in Event Viewer - Applications and Services Logs - DNS Server. Again, I couldn't find any description or list of possible events. So the events from practical test scenarios are listed below.

Signing the Zone

• 25.1. 7:55:30 7650 The DNS server has started signing the zone firma.cz.
• 25.1. 7:55:30 7675 The DNS server has started signing the scope Default of zone firma.cz.
• 25.1. 7:55:30 7676 The scope Default of zone firma.cz is signed with DNSSEC. The server will give DNSSEC compliant responses to DNSSEC queries for this scope.
• 25.1. 7:55:30 7646 The zone firma.cz is now signed with DNSSEC.

Unsigning the Zone

• 20.1. 14:01:38 776 The DNS server has started to unsign the zone firma.cz on server dns1.
• 20.1. 14:01:38 7675 The DNS server has started signing the scope Default of zone firma.cz.
• 20.1. 14:01:38 7678 The scope Default of zone firma.cz is no longer signed with DNSSEC. The server will not provide DNSSEC compliant responses to DNSSEC queries for this scope.
• 20.1. 14:01:38 7647 The zone firma.cz is no longer signed with DNSSEC.

KSK Key Rollover with RFC 5011

• 31.1. 15:07:25 7667 Keys for the Signing Key Descriptor {D7A93F69-31B9-46A7-8057-F7CF3625F7DE} in zone firma.cz will be rolled over in less than 1 day.
• 1.2. 7:55:29 784 The key signing key with GUID {D7A93F69-31B9-46A7-8057-F7CF3625F7DE} of zone firma.cz has moved to stage DNS_SKD_STATUS_ROLL_STARTED of rollover.
• 1.2. 7:55:29 7669 Keys for the Signing Key Descriptor {D7A93F69-31B9-46A7-8057-F7CF3625F7DE} in zone firma.cz are starting the rollover process.
• 1.2. 7:55:29 784 The key signing key with GUID {D7A93F69-31B9-46A7-8057-F7CF3625F7DE} of zone firma.cz has moved to stage DNS_SKD_STATUS_KSK_WAITING_FOR_DS_UPDATE of rollover.
• every minute the same event 784 is logged
• 7.2. 15:51 KEYSET edited at CZ.NIC (new DS record created)
• 7.2. 16:21:32 784 The key signing key with GUID {D7A93F69-31B9-46A7-8057-F7CF3625F7DE} of zone firma.cz has moved to stage DNS_SKD_STATUS_KSK_WAITING_FOR_DS_TTL of rollover.
• 7.2. 17:21:32 784 The key signing key with GUID {D7A93F69-31B9-46A7-8057-F7CF3625F7DE} of zone firma.cz has moved to stage DNS_SKD_STATUS_KSK_WAITING_FOR_5011_REMOVE_HOLD_DOWN of rollover.
• 9.3. 17:21:31 784 The key signing key with GUID {D7A93F69-31B9-46A7-8057-F7CF3625F7DE} of zone firma.cz has moved to stage DNS_SKD_STATUS_ROLL_ERROR of rollover.
• 9.3. 17:21:31 7670 The rollover process for Signing Key Descriptor {D7A93F69-31B9-46A7-8057-F7CF3625F7DE} in zone firma.cz is complete.

KSK Key Rollover without RFC 5011

• 22.2. 21:22:52 7667 Keys for the Signing Key Descriptor {FE806F2E-93CC-44F4-BA50-0B445582B7BB} in zone firma.cz will be rolled over in less than 1 day.
• 23.2. 14:10:59 784 The key signing key with GUID {FE806F2E-93CC-44F4-BA50-0B445582B7BB} of zone firma.cz has moved to stage DNS_SKD_STATUS_ROLL_STARTED of rollover.
• 23.2. 14:10:59 7669 Keys for the Signing Key Descriptor {FE806F2E-93CC-44F4-BA50-0B445582B7BB} in zone firma.cz are starting the rollover process.
• 23.2. 14:10:59 784 The key signing key with GUID {FE806F2E-93CC-44F4-BA50-0B445582B7BB} of zone firma.cz has moved to stage DNS_SKD_STATUS_KSK_WAITING_FOR_DS_UPDATE of rollover.
• 23.2. 14:11:59 784 The key signing key with GUID {FE806F2E-93CC-44F4-BA50-0B445582B7BB} of zone firma.cz has moved to stage DNS_SKD_STATUS_KSK_WAITING_FOR_DNSKEY_TTL of rollover.
• 23.2. 15:11:59 784 The key signing key with GUID {FE806F2E-93CC-44F4-BA50-0B445582B7BB} of zone firma.cz has moved to stage DNS_SKD_STATUS_ROLL_ERROR of rollover.
• 23.2. 15:11:59 7670 The rollover process for Signing Key Descriptor {FE806F2E-93CC-44F4-BA50-0B445582B7BB} in zone firma.cz is complete.

ZSK Key Rollover

• 18.2. 19:10:02 785 The zone signing key with GUID {A47164FC-8C89-4F92-9EBA-8F1A54050BC2} of zone firma.cz has moved to stage DNS_SKD_STATUS_QUEUED of rollover.
• 18.2. 19:10:02 785 The zone signing key with GUID {A47164FC-8C89-4F92-9EBA-8F1A54050BC2} of zone firma.cz has moved to stage DNS_SKD_STATUS_ROLL_STARTED of rollover.
• 18.2. 19:10:02 7669 Keys for the Signing Key Descriptor {A47164FC-8C89-4F92-9EBA-8F1A54050BC2} in zone firma.cz are starting the rollover process.
• 18.2. 19:10:02 785 The zone signing key with GUID {A47164FC-8C89-4F92-9EBA-8F1A54050BC2} of zone firma.cz has moved to stage DNS_SKD_STATUS_ZSK_WAITING_FOR_DNSKEY_TTL of rollover.
• 18.2. 19:10:02 785 The zone signing key with GUID {A47164FC-8C89-4F92-9EBA-8F1A54050BC2} of zone firma.cz has moved to stage DNS_SKD_STATUS_ZSK_WAITING_FOR_MAXZONE_TTL of rollover.
• 20.2. 20:10:01 785 The zone signing key with GUID {A47164FC-8C89-4F92-9EBA-8F1A54050BC2} of zone firma.cz has moved to stage DNS_SKD_STATUS_ROLL_ERROR of rollover.
• 20.2. 20:10:01 7670 The rollover process for Signing Key Descriptor {A47164FC-8C89-4F92-9EBA-8F1A54050BC2} in zone firma.cz is complete.