.png){kind=logo}
The ZoneFileServerSideSigner signs Domain Name System (DNS) zone files using DNS Security Extensions (DNSSEC). The DNSSEC adds a layer of trust on top of DNS by providing authentication.
Fully qualified class name: org.signserver.module.dnssec.signer.ZoneFileServerSideSigner
Overview
The input should be an unsigned zone file in text format and a parameter specifying the key sequence number to use. The output is the zone file with the signatures, keys, and NSEC3 records added and signed by the Zone Signing Key (ZSK) with the specified sequence number and with the public key including the next sequence number (pre-publishing). The Key Signing Keys (KSK) to use are specified in the Worker configuration.
Key Rollover
This Signer supports the standard DNSSEC rollover strategy for each key type because the two keys have different constraints: a ZSK rollover is entirely under your control, while a KSK rollover also depends on the parent zone/registrar updating its DS record.
ZSK Rollover (pre-publish): Each signed zone includes the DNSKEY for the next ZSK sequence number in addition to the one actively signing, so resolvers have already cached the upcoming key before you switch to it. Set PUBLISH_PREVIOUS_ZSK=true (the default) to also keep the outgoing ZSK's DNSKEY published until you're confident every resolver has moved on.
KSK Rollover (double signature): Because the DS record trusted by resolvers lives in the parent zone, a KSK cannot be rolled purely by pre-publishing. Resolvers may have the old DS cached for as long as its TTL, independent of anything you do to your own zone. ACTIVE_KSKS accepts one or two key aliases specifically to cover this transition: with two configured, the DNSKEY RRset is signed by both the outgoing and incoming KSK, so resolvers validate correctly whichever DS/DNSKEY version they currently have cached. See Using KSK Rollover.
To download a sample configuration file for this Worker, see Sample Worker Configurations.
For information on the interfaces this Worker can be called through, see Supported Interfaces by Worker.
Available Properties
|
Required Property |
Default |
Description |
|---|---|---|
|
|
None |
Specifies the active key signing keys to use. Must specify exactly 1 or 2 key aliases, comma-separated. Example: |
|
|
None |
Specifies the name of the top-level zone in the zone file. Example: |
|
|
None |
Specifies the key alias prefix to use for zone signing. The key used is based on the prefix with the key sequence number appended. Example: |
|
Property |
Default |
Description |
|
|
|
True if the keys configured in |
|
|
|
Disables the key usage counter. As the key usage counter is not supported by this Signer, if set, only the value |
|
|
None |
(Optional) Specifies the fixed, HEX-encoded salt (64-bit value) to use instead of a random salt for testing/troubleshooting purposes. Example: |
|
|
|
(Optional) Specifies if the previous ZSK (if one) should be kept published. |
|
|
|
Specifies the signature algorithm to use for all signatures. Only |
Request Parameters
|
Property |
Description |
|---|---|
|
|
Specifies the sequence number to append after key alias prefix. Example: |
Using KSK Rollover
A KSK rollover using this Signer takes three steps, and the timing between them matters as much as the config change itself:
-
Introduce the new key. Add the new KSK alias to
ACTIVE_KSKSalongside the current one (old_alias,new_alias). The zone's DNSKEY RRset is now double-signed. Wait at least one DNSKEY TTL so the new key set propagates to resolver caches. -
Update the parent. Submit the new KSK's DS record to the parent zone/registrar. Wait for the old DS record's TTL to fully expire from resolver caches before continuing. This is the step outside the Signer's control and usually the longest wait.
-
Retire the old key. Remove the old KSK alias from
ACTIVE_KSKS, leaving only the new one. The zone reverts to single-signing.