ZONESIGNER(1)

📦

version 2.2.3 · 2 versions

2.2.3 · fedora 43 (latest)
2.2.3 · fedora 44

, in fedora 43

ZONESIGNER 💖 (that's the `zonesigner` command, section 1 of the manual, filed under User Contributed Perl Documentation, bestie 🎀)

okay so. buckle up. this is the girl that does everything for your DNS zone and she does it flawlessly, no cap.

✨ NAME ✨

zonesigner — generates encryption keys and signs a DNS zone. that's it. that's the whole personality. 💅

🌸 SYNOPSIS 🌸

zonesigner [options] <zone-file> <signed-zone-file>

and here are the "get started immediately" examples, because you know we're not reading all of this first:

# first run on a zone for example.com:
zonesigner -genkeys -endtime +2678400 example.com

# future runs before expiration time (reuses the same keys):
zonesigner -endtime +2678400 example.com

🦋 DESCRIPTION 🦋

This script combines into a single command many actions that are required to sign a DNS zone. it literally does the whole group project by herself. 🫶 It generates the required KSK and ZSK keys, adds the key data to a zone record file, signs the zone file, and runs checks to ensure that everything worked properly. she's thorough like that. It also keeps records about the keys and how the zone was signed in order to facilitate re-signing of the zone in the future — so future-you doesn't have to remember anything, which is the dream tbh.

The zonesigner-specific zone-signing records are kept in keyrec files. Using keyrec files, defined and maintained by DNSSEC-Tools, zonesigner can automatically gather many of the options used to previously sign and generate a zone and its keys. This allows the zone to be maintained using the same key lengths and expiration times, for example, without an administrator needing to manually track these fields. like, she remembers the vibe so you don't have to. iconic.

⭐ QUICK START ⭐

The following are examples that will allow a quick start on using zonesigner:

🌈 first run on example.com

The following command will generate keys and sign the zone file for example.com, giving an expiration date 31 days in the future. The zone file is named example.com and the signed zone file will be named example.com.signed.

zonesigner -genkeys -endtime +2678400 example.com

🌈 subsequent runs on example.com

The following command will re-sign example.com's zone file, but will not generate new keys. The files and all key-generation and zone-signing arguments will remain the same.

zonesigner example.com

🎀 USING ZONESIGNER 🎀

zonesigner is used in this way:

zonesigner [options] <zone-file> <signed-zone-file>

The zone-file argument is required. (yes bestie. required. you can't skip it.)

zone-file is the name of the zone file from which a signed zone file will be created. If the -zone option is not given, then zone-file will be used as the name of the zone that will be signed. Generated keys are given this name as their base.

Once zonesigner has created a set of keys for a zone and signed the zone, it may be used to re-sign the as the zonefile changes. When run without any options, zonesigner will consult the zone's keyrec to find the appropriate set of keys and will then sign the specified zone with them. effortless. main character energy. 💅

The zone file is modified to have include commands, which will include the KSK and ZSK keys. These lines are placed at the end of the file and should not be modified by the user. (do not touch. hands off. 🙈) If the zone file already includes any key files, those inclusions will be deleted. These lines are distinguished by starting with "$INCLUDE" and end with ".key". Only the actual include lines are deleted; any related comment lines are left untouched.

An intermediate file is used in signing the zone. zone-file is copied to the intermediate file and is modified in preparation of signing the zone file. Several $INCLUDE lines will be added at the end of the file and the SOA serial number will be incremented.

signed-zone is the name of the signed zone file. If it is not given on the command line, the default signed zone filename is the zone-file appended with ".signed". Thus, executing zonesigner example.com will result in the signed zone being stored in example.com.signed.

Unless the -genkeys, -genksk, -genzsk, or -newpubksk options are specified, the last keys generated for a particular zone will be used in subsequent zonesigner executions. DS records will be included in signing operations unless the -nogends option is used.

zonesigner can be used with a rollover manager, such as rollerd, to provide automated management of a zone, its keys, and the signing of the zone. If a rollerd-managed zonefile changes while rollerd is waiting for a zone rollover to begin or a rollover phase to complete, zonesigner may be used to sign the zone with the proper set of keys; rollerd will not be disrupted by this. they just coexist. besties fr fr. 🫶

💜 KEYREC FILES 💜

keyrec files retain information about previous key-generation and zone-signing operations. If a keyrec file is not specified (by way of the -krfile option), then a default keyrec file is used. If this default is not specified in the system's DNSSEC-Tools configuration file, the filename will be the zone name appended with .krf. If the -nokrfile option is given, then no keyrec file will be consulted or saved. (she'll just rawdog it. 💀)

Each keyrec contains a set of "key/value" entries, one per line. Example 4 below contains the contents of a sample keyrec file.

keyrec files contain three types of entries: zone keyrecs, set keyrecs, and key keyrecs. Zone keyrecs contain information specifically about the zone, such as the number of ZSKs used to sign the zone, the end-time for the zone, and the key signing set names (names of set keyrecs.) Set keyrecs contain lists of key keyrec names used for a specific purpose, such as the current ZSK keys or the published ZSK keys. Key keyrecs contain information about the generated keys themselves, such as encryption algorithm, key length, and key lifetime.

As a zone proceeds through key rollover, new cryptographic keys will be generated for the zone. The various key parameters (e.g., key length and crypto algorithm) will be the same as the parameters previously used to generate keys for that zone. The keymod command allows these key parameters to be modified as needs change. If a particular parameter is changed, such as the KSK length changing from 1024 to 2048, then future keys will reflect that change; current and past keys will not be modified. (the past is the past, babe. 🦋)

🧚 Keyrec Files and RFC5011 KSK Revocation

If RFC5011 processing is enabled, there is special handling of the zone's set keyrec of revoked KSK keys. The "kskrev" field in the zone's keyrec points to a set keyrec, marked as being of type "kskrev". This set keyrec, in turn, points to a number of other set keyrecs, all of which are also marked as being of type "kskrev". The group of all revoked KSK keys is found by consulting that subsidiary set of "kskrev" set keyrecs. When the ages of these revoked keys exceeds their revocation periods, they are marked as being obsolete ("kskobs"). If this happens as part of normal rollover, these revoked key and set keyrecs are all removed from the chain of active, revoked keyrecs. If this happens to a key that's part of a larger set of keys, it is removed from that signing set and put in its own new signing set. very "you can sit with us but at your own table" of her tbh.

🔥 ENTROPY 🔥

On some systems, the implementation of the pseudo-random number generator requires keyboard activity. This keyboard activity is used to fill a buffer in the system's random number generator. If zonesigner appears hung, you may have to add entropy to the random number generator by randomly striking keys until the program completes. Display of this message is controlled by the entropy_msg configuration file parameter.

bestie she is not frozen she is just ✨gathering vibes✨. smash those keys. go feral on the keyboard. it's for cryptography. 😭

🌟 DETERMINING OPTION VALUES 🌟

zonesigner checks four places in order to determine option values. In descending order of precedence, these places are:

command line options
keyrec file
DNSSEC-Tools configuration file
zonesigner defaults

Each is checked until a value is found. That value is then used for that zonesigner execution and the value is stored in the keyrec file.

🌸 Example

For example, the KSK length has the following values:

-ksklength command line option:     8192

keyrec file:                        1024

DNSSEC-Tools configuration file:     512

zonesigner defaults:                2048

If all are present, then the KSK length will be 8192.

If the -ksklength command line option wasn't given, the KSK length will be 1024.

If the KSK length wasn't given in the configuration file, it will be 8192.

If the KSK length wasn't in the keyrec file or the configuration file, the KSK length will be 8192.

If the -ksklength command line option wasn't given and the KSK length wasn't in the configuration file, it'll be 1024.

If the command line option wasn't given, the KSK length wasn't in the keyrec file, and it wasn't in the configuration file, then the KSK length will be 512.

👑 OPTIONS 👑

Three types of options may be given, based on the command for which they are intended. These commands are dnssec-keygen, dnssec-signzone, and zonesigner.

💅 zonesigner-specific Options

-archivedir — The key archive directory. If a key archive directory hasn't been specified (on the command line or in the DNSSEC-Tools configuration file) and the -nosave option was not given, then zonesigner will leave the keys in the current directory.

When the files are saved into the archive directory, the existing file names are prepended with a timestamp. The timestamp indicates when the files are archived.

This directory may not be the root directory. 🚫

-droprevoked — Explicitly obsolete currently revoked KSKs and remove them from the signing set before resigning. This is mutually exclusive from -nodroprevoked. If neither -droprevoked nor -nodroprevoked are given, then -droprevoked functionality is assumed..
-dsdir — Specify a directory for storing dssets. This directory will be created if it does not exist.

The directory must be writable and may not be the root directory. 🚫

-genkeys — Generate new KSKs and ZSKs for the zone.
-genksk — Generate new Current KSKs for the zone. Any existing Current KSKs will be marked as obsolete. If this option is not given, the last KSKs generated for this zone will be used.
-genzsk — Generate new ZSKs for the zone. By default, the last ZSKs generated for this zone will be used.
-help — Display a usage message.
-intermediate — Filename to use for the temporary zone file. The zone file will be copied to this file and then the key names appended.
-keydirectory — The directory in which KSK and ZSK keys will be stored. The default is to store the keys in the directory in which zonesigner is executed.

This directory may not be the root directory. 🚫

-krfile — keyrec file to use in processing options. See the man page for Net::DNS::SEC::Tools::tooloptions.pm for more details about this file.
-ksignset — The name of the KSK signing set to use. If the signing set does not exist, then this must be used in conjunction with either -genkeys or -genksk. The name may contain alphanumerics, underscores, hyphens, periods, and commas.

The name may contain alphanumerics, underscores, hyphens, periods, and commas. The default signing set name is "zone-signset-N", where zone is the zone being signed and N is a number.

If -ksignset is not specified, then zonesigner will use the default and increment the number for subsequent signing sets.

-kskcount — how many KSK keys to generate and sign the zone with. Default vibe is just one single KSK, keeping it simple bestie.
-kskdirectory — the directory where your KSK keys get stored. Default is wherever you happened to run zonesigner from — very "wherever I am is home" of it.

Heads up: this directory may not be the root directory. No / shenanigans, okay?

-ksklife — the time between KSK rollovers, measured in seconds.
-newpubksk — generate brand new Published KSKs for the zone. Any Published KSKs you already had? They get marked obsolete. Out with the old, periodt.
-nodroprevoked — explicitly turn off obsoleting currently revoked KSKs and removing them from the signing set before resigning. This is mutually exclusive from -droprevoked. If neither -droprevoked nor -nodroprevoked is given, then -droprevoked functionality is assumed.
-nokrfile — no keyrec file will be consulted or created. Zero keyrec energy.
-norfc5011 — disable RFC5011 KSK revocation when rolling or replacing existing KSK key sets. By default, zonesigner performs RFC5011 KSK revocation, and this option supersedes that behavior and any option setting inside the keyrec file.
-nosave — don't save obsolete keys to the key archive directory. The default behavior is to save obsolete keys (so like, this is the opposite of default).
-phase — specify a rollover option based on the rollover phase, instead of using the option that names the specific action to be performed. The whole point of this option is to bring clarity and greater understanding to how zonesigner is used in the rollover process. iykyk.

Here's the mapping between the -phase options and the action options:

    Phase Option             Action-based Option
    -phase ksk2              -newpubksk
    -phase ksk4              -rollksk
    -phase zsk2              -usezskpub
    -phase zsk4b             -rollzsk
    -phase zsk4b             (no option)

Warning: The -phase option should only be used if you know what you're doing. Like, actually know. Fr fr. 💀

-rollksk — force a rollover of the KSK keys. The Current KSK keys get marked as Obsolete, the Published KSK keys get marked as Current, and then the zone is signed with the new set of Current KSK keys. If your zone's keyrec doesn't list a Current or Published KSK, an error message is printed and zonesigner stops execution. 🛑

The zone's keyrec file is updated to show the new key state.

The keyrecs of the KSK keys are adjusted like this:

The Current KSK keys are marked as Obsolete.
The Published KSK keys are marked as Current.
The Obsolete KSK keys are moved to the archive directory.

If RFC5011 processing is enabled, then the KSK rollover sequence gets modified like this:

The Current KSK keys are marked as Revoked.
The Published KSK keys are marked as Current.
The Revoked KSK keys are checked to see if they are still within their revocation period. If not, they are marked as Obsolete.
The Obsolete KSK keys are moved to the archive directory.

Warning: The timing of key-rolling is critical. Great care must be taken when using this option. In the future, rollerd will automate the KSK rollover process and may be used to safely take care of this aspect of DNSSEC management.

Warning: Using the -rollksk option should only be used if you know what you're doing. 👑

Warning: This may be a temporary method of KSK rollover. It may be changed in the future.

-rollmgr — the zone's rollover manager. This says that the zone is under the control of a rollover manager. If a user wants to sign a zone in the middle of a rollover wait phase, this field helps zonesigner and the rollover manager figure out how best to handle the zone-signing operation. Teamwork, bestie. 🤝
-rollzsk — force a rollover of the ZSK keys using the Pre-Publish Key Rollover method. The rollover process adjusts the keys used to sign the specified zone, generates new keys, signs the zone with the appropriate keys, and updates the keyrec file. The Pre-Publish Key Rollover process is described in the DNSSEC Operational Practices document.

Three sets of ZSK keys are used in the rollover process: Current, Published, and New. Current ZSKs are the ones actually used to sign the zone. Published ZSKs are available in the zone data — and therefore in cached zone data — but are not yet used to sign the zone. New ZSKs are not available in zone data, nor used to sign the zone yet; they're just waiting in the wings for future use. ✨

The keyrecs of the ZSK keys are adjusted like this:

The Current ZSK keys are marked as obsolete.
The Published ZSK keys are marked as Current.
The New ZSK keys, if they exist, are marked as Published.
Another set of ZSK keys are generated, which will be marked as the New ZSK keys.
The Published ZSK keys' zsklife field is copied to the new ZSK keys' keyrecs.
The obsolete ZSK keys are moved to the archive directory.

The quick summary of proper ZSK rolling (which rollerd does for you if you use it):

wait 2 * max(TTL in zone)
run zonesigner using -usezskpub
wait 2 * max(TTL in zone)
run zonesigner using -rollzsk
wait 2 * max(TTL in zone)

Warning: The timing of key-rolling is critical. Great care must be taken when using this option. rollerd automates the rollover process and may be used to safely take care of this aspect of DNSSEC management. Using the -rollzsk option should only be used if you know what you're doing.

-showkeycmd — display the actual key-generation command (with all its options and arguments) that gets executed. It's like, a tiny little subset of verbose level 3 output. 🫶
-showsigncmd — display the actual zone-signing command (with all its options and arguments) that gets executed. Also just a small subset of verbose level 3 output.
-signonly — sign the zone without doing any key generation or key rollover operations. The keys used in the most recent zonesigner signing of this zone are the keys used for this signing. Reuse era. ♻️
-signset — the name of the ZSK signing set to use as the Current ZSK signing set. The zone gets signed and the given signing set becomes the zone's new Current ZSK signing set. If the signing set doesn't exist, then this must be used together with either -genkeys or -genzsk.

The name may contain alphanumerics, underscores, hyphens, periods, and commas. The default signing set name is "zonesignset-N", where zone is the zone being signed and N is a number.

If -signset is not specified, then zonesigner will use the default and increment the number for subsequent signing sets.

-threshold — sign the zone only if a threshold condition is met. Depending on how the threshold is specified, it may be relative to the last time the zone was signed, or to the zone's expiration date.

threshold-time is the threshold value, given as a numeric value, with an optional unit specifier. The unit may be 's', 'm', 'h', or 'd', for seconds, minutes, hours, or days. If the unit isn't given, then the value is in seconds. The threshold value must have either the - prefix or the + prefix to indicate which threshold to measure. The threshold value +10d refers to ten days prior to a zone's expiration date.

If the - prefix is used, then the zone will be re-signed if zonesigner is executed no more than threshold-time after the last time the zone was signed. threshold-time is determined by subtracting the threshold value from the upcoming midnight. If this would put the threshold time in the future, then it is calculated from the current time.

If the + prefix is used, then the zone will be re-signed if zonesigner is executed no more than threshold-time before the zone's expiration date. threshold-time is determined by subtracting the threshold value from the previous midnight. If this would put threshold-time in the past, then it is calculated from the current time.

-useboth — use the existing Current and Published ZSKs to sign the zone.
-usezskpub — use the existing Published ZSKs to sign the zone.
-Version — display the version information for zonesigner and the DNSSEC-Tools package.
-verbose — verbose output will be given. The more times you stack -verbose on the command line, the more levels of verbosity you unlock. 🎚️

    level       output
    -----       ------
      1         operations being performed
                (e.g., generating key files, signing zone)
      2         details on operations and some operation results
                (e.g., new key names, zone serial number)
      3         operations' parameters and additional details
                (e.g., key lengths, encryption algorithm,
                executed commands)

Higher levels of verbosity are cumulative. Specifying two instances of -verbose will get you the output from the first and second levels of output.

-xc — display a message associated with a zonesigner exit value. This option is intended for use by those programs who wish for zonesigner to run silently, but need a description for why zonesigner exited with an error.

The following are the exit codes and their associated messages.

0 — successful execution 💅
1 — -rfc5011 and -norfc5011 may not be specified together
2 — -droprevoked and -nodroprevoked may not be specified together
3 — -keydirectory and -kskdirectory may not be specified together
4 — -keydirectory and -zskdirectory may not be specified together
5 — KSK count must be positive
6 — ZSK count must be positive
7 — no key archive directory was specified
8 — key archive directory is not a directory
9 — key archive directory must not be /
10 — -savekeys and -nosave may not be specified together
11 — either a KSK or a ZSK directory was incorrectly specified
12 — either a specified KSK or a specified ZSK directory is not a directory
13 — neither the KSK nor the ZSK directory may be the root directory
14 — zone file, output file, and intermediate file must all have distinct names
15 — zone file does not exist
16 — zone file is empty
17 — zone file already signed
18 — specified signing set does not exist
19 — specified Current ZSK signing set does not exist
20 — specified Published ZSK signing set does not exist
21 — specified new signing-set name already exists
22 — specified KSK signing set already exists
23 — no KSK signing set was specified
24 — specified Current KSK signing set does not exist
25 — specified Published KSK signing set does not exist
26 — unable to generate KSK key file
27 — ZSK keyrec does not exist in keyrec file
28 — unable to generate ZSK key file
29 — unable to archive keys because key archive directory is not a directory
30 — KSK repository is not a directory
31 — ZSK repository is not a directory
32 — unable to update serial number in zonefile
33 — zone file's modified contents are empty
34 — unable to sign zone
35 — no Published KSKs have been created
36 — zone has no Published ZSKs to rollover to Current ZSKs
37 — no keys defined for a particular signing set for zone
38 — no keyrec exists for required signing set
39 — error in keyrec file -- a particular signing set keyrec is not a set keyrec
40 — specified signing set does not contain any keys
41 — no key keyrec exists for a particular key
42 — keyrec of specified key has an unexpected type
43 — usage message printed
44 — invalid exit code given to -xc
45 — named-checkzone returned an error
46 — unable to create dsset archive directory
47 — dsset archive directory is not a directory
48 — dsset archive directory is not writable
49 — dsset archive directory must not be /
50 — invalid threshold
51 — invalid format end-date

bestie if you hand it an invalid exit code it's gonna print an error message at you. it's giving "no 💀"

-Cthulhu — okay so. this option is for internal use only and should never be used by a user. and if this warning gets ignored?? then undefined, unnameable eldritch horrors may be visited upon your zone files. like, actual ones. do not use. 🦑🔮
-zone — the name of the zone that's getting signed. you can hand it over with this option, or just drop it as the first non-option command line argument. if you go the argument route and it's got directory separators in it, then the final element of the path is what gets used for the zone name. cute, right? ✨
-zskcount — how many ZSK keys to generate, and how many to sign the zone with. the default is just a single ZSK key. simple. iconic. 💅
-zskdirectory — the directory where the ZSK keys are gonna be stored. default? wherever you ran zonesigner from. home sweet home 🏠

heads up though: this directory may not be the root directory. 🚫

-zsklife — the time between ZSK rollovers, measured in seconds. ⏳

🌸 dnssec-keygen-specific Options 🌸

-algorithm — the cryptographic algorithm used to generate the zone's keys. default value is RSASHA1. this value gets passed straight to dnssec-keygen as the -a flag. go check dnssec-keygen's manual page to figure out the legal values, ok? 🔐
-kgopts — extra options for dnssec-keygen go here. you pass them all as a single string value as the argument to -kgopts. one string, bestie, one ✋
-ksklength — bit length of the zone's KSK key. default is 2048.
-nsec3optout — when this flag and the -usensec3 flag are set, the zone gets signed using the Opt-Out support described in RFC5155. quick summary: only sub-domains with valid DS or public keys available get signed, and the rest don't. this greatly reduces the computational and memory requirements of extremely large zones with lots of unsigned children. it's giving efficiency queen 👑
-random — the source of randomness used to generate the zone's keys. it's assumed to be a file, for example /dev/urandom. 🎲
-usensec3 — signs the zone using NSEC3 (see RFC5155) proof-of-non-existence records instead of NSEC records. the keys used to sign the zone must support NSEC3, or else zone-signing will fail — no cap. zonesigner will automatically generate new keys of the correct type if one of the -genkeys or similar options is used. 🦋
-zsklength — bit length of the zone's ZSK key. default is 1024.

✨ dnssec-signzone-specific Options ✨

-endtime — the time that the zone expires, measured from the current time. if it's given as a number, that's a count of seconds. if it's a number followed by 's', 'm', 'h', or 'd', then it's seconds, minutes, hours, or days. the default value is 2764800 seconds (32 days.) ⏰
-gends — forces dnssec-signzone to generate DS records for the zone. this option gets translated into -g when it's passed to dnssec-signzone.

this option is obsolete. DS records are generated by default. use the -nogends option if DS records should not be generated. 🙈

-ksdir — specify a directory for storing keysets. this is passed to dnssec-signzone as the -d option. 📁
-nogends — stops dnssec-signzone from generating DS records for the zone.
-szopts — extra options for dnssec-signzone go here. the additional options are passed as a single string value as an argument to the -szopts option.

the default value for this option is "-i local", set in defaults.pm. this value has been found to greatly improve the amount of time it takes named-checkzone to run. lowkey a glow-up for your runtime ✨

💜 Other Options 💜

-zcopts — extra options for named-checkzone go here. the additional options are passed as a single string value as an argument to the -zcopts option. 🫶

✨ EXAMPLES ✨

bestie, this is the part where it all clicks, i promise 🫶 we're gonna walk through four little scenarios and by the end you're gonna be like "oh that's IT?" — iconic behavior.

Example 1.

so like, in example one we've already got a keyrec file just vibing in the folder, and we're using it to help sign the example.com domain. The zone data lives in example.com, and the keyrec is chillin' in example.krf. The final signed zone file is gonna be db.example.com.signed. You run this:

# zonesigner -krfile example.krf example.com db.example.com.signed

and boom, these files appear like magic ✨:

Kexample.com.+005+45842.private
Kexample.com.+005+45842.key
Kexample.com.+005+50186.private
Kexample.com.+005+50186.key
Kexample.com.+005+59143.private
Kexample.com.+005+59143.key

dsset-example.com.
keyset-example.com.

db.example.com.signed

okay so the first six files? those are the KSK and ZSK keys the zone literally needs, no cap. The next two files get made by the zone-signing process itself. And the very last file is the final signed zone file — the main character of this whole operation 💅.

Example 2.

same energy as example one honestly: an existing keyrec file is used to assist in signing the example.com domain. Zone data lives in example.com, keyrec is in example.krf. But this time the generated keys, an intermediate zone file, and the final signed zone file all use example.com as a base. You run:

# zonesigner -krfile example.krf -intermediate example.zs example.com

and you get:

Kdb.example.com.+005+12354.key
Kdb.example.com.+005+12354.private
Kdb.example.com.+005+82197.key
Kdb.example.com.+005+82197.private
Kdb.example.com.+005+55888.key
Kdb.example.com.+005+55888.private

dsset-db.example.com.
keyset-db.example.com.

example.zs
example.com.signed

first six files = the KSK and ZSK keys the zone needs, same as before. next two = made by the zone-signing process. the second-to-last file is an intermediate file that's gonna get signed. and the last file is the final signed zone. slay 🌸

Example 3.

okay so this time there's NO keyrec file specified for signing the example.com domain. Which means — plot twist — in addition to all the files created like in the previous examples, a brand new keyrec file gets born 🦋. That new keyrec file uses the domain name as its base. You run:

# zonesigner example.com db.example.com

and the keyrec file that gets created is:

example.com.krf

and the signed zone file is created in:

db.example.com

Example 4.

this one's just showing off a keyrec file that zonesigner generated, so you can see what the tea actually looks like ☕

The command executed is:

# zonesigner example.com db.example.com

The generated keyrec file contains six keyrecs: a zone keyrec, two set keyrecs, one KSK keyrec, and two ZSK keyrecs. Look at her:

zone        "example.com"
    zonefile        "example.com"
    signedzone      "db.example.com"
    endtime         "+2764800"
    kskcur          "example.com.signset-24"
    kskdirectory    "."
    zskcur          "example.com.signset-42"
    zskpub          "example.com.signset-43"
    zskdirectory    "."
    keyrec_type     "zone"
    keyrec_signsecs "1115166642"
    keyrec_signdate "Wed May  4 00:30:42 2005"

set         "example.com.signset-24"
    zonename        "example.com"
    keys            "Kexample.com.+005+24082"
    keyrec_setsecs  "1110000042"
    keyrec_setdate  "Sat Mar  5 05:20:42 2005"

set         "example.com.signset-42"
    zonename        "example.com"
    keys            "Kexample.com.+005+53135"
    keyrec_setsecs  "1115166640"
    keyrec_setdate  "Wed May  4 00:30:40 2005"

set         "example.com.signset-43"
    zonename        "example.com"
    keys            "Kexample.com.+005+13531"
    keyrec_setsecs  "1115166641"
    keyrec_setdate  "Wed May  4 00:30:41 2005"

key         "Kexample.com.+005+24082"
    zonename        "example.com"
    keyrec_type     "kskcur"
    algorithm       "rsasha1"
    random          "/dev/urandom"
    keypath         "./Kexample.com.+005+24082.key"
    ksklength       "2048"
    ksklife         "15768000"
    keyrec_gensecs  "1110000042"
    keyrec_gendate  "Sat Mar  5 05:20:42 2005"

key         "Kexample.com.+005+53135"
    zonename        "example.com"
    keyrec_type     "zskcur"
    algorithm       "rsasha1"
    random          "/dev/urandom"
    keypath         "./Kexample.com.+005+53135.key"
    zsklength       "1024"
    zsklife         "604800"
    keyrec_gensecs  "1115166638"
    keyrec_gendate  "Wed May  4 00:30:38 2005"

key         "Kexample.com.+005+13531"
    zonename        "example.com"
    keyrec_type     "zskpub"
    algorithm       "rsasha1"
    random          "/dev/urandom"
    keypath         "./Kexample.com.+005+13531.key"
    zsklength       "1024"
    zsklife         "604800"
    keyrec_gensecs  "1115166638"
    keyrec_gendate  "Wed May  4 00:30:38 2005"

like, she's structured, she's organized, she's doing the most and we love her for it 💜

📝 NOTES 📝

okay a couple of things you genuinely need to know, no skipping 🙈

One Zone in a keyrec File — There's a bug in the signing-set code that means you can only store ONE zone in a keyrec file. That's just how it is bestie, don't fight it 💀
SOA Serial Numbers — In this version, serial numbers in SOA records are merely incremented, that's it. The future plans are to allow for more flexible serial number manipulation. so like, for now? incremented. periodt.

💖 COPYRIGHT 💖

👑 AUTHOR 👑

Wayne Morrison, tewok@tislabs.com

🌈 SEE ALSO 🌈

keymod(8), lskrf(1), rollerd(1)
dnssec-keygen(8), dnssec-signzone(8)
Net::DNS::SEC::Tools::conf.pm(3), Net::DNS::SEC::Tools::defaults.pm(3), Net::DNS::SEC::Tools::keyrec.pm(3), Net::DNS::SEC::Tools::tooloptions.pm(3)
keyrec(5)

and that's a wrap on ZONESIGNER(1) bestie!! 🎉 this page is running perl v5.42.0, dated 2025-07-23, and yes the page itself is literally called ZONESIGNER(1) — she's been here since forever and she's still serving. go forth and sign some zones, i'm so proud of you 🫶✨

📦 where this page comes from

fedora 43: dnssec-tools 2.2.3-30.fc43 · LicenseRef-Callaway-BSD
💖 girlified by deepseek-ai/DeepSeek-V4.1-Flash on 2026-10-18: a language model's rewrite of the original, under its terms