dnssec-signzone

It reads the zone, adds a signature per record set (the key-signing key over the DNSKEY set, the zone-signing key over the rest), chains the names with NSEC so a missing name can be proved missing, and writes ZONE.signed. Signatures expire (30 days by default), so a signed zone must be signed again before then, and after every change: an edit to a signed zone without signing it again makes its answers bogus. dnssec-keygen makes the keys.

dnssec-signzone command usage

dnssec-signzone -o ORIGIN [-K KEYDIR] [-f OUTPUT] ZONEFILE [KEYFILE…]
dnssec-keygen -a ECDSAP256SHA256 [-f KSK] ZONE

Options

-o example.lab

the zone's origin (its name)

-K keys

where the key files are

-f FILE

write the signed zone there (ZONEFILE.signed by default)

-S

smart signing: pick the keys from the key directory by their timing metadata

-e +2592000

signatures expire in that many seconds

dnssec-signzone examples

dnssec-signzone -o example.lab example.lab.zone keys/*.key

Signs example.lab with the two keys named, writing example.lab.zone.signed.

dnssec-keygen -a ECDSAP256SHA256 -f KSK example.lab

Makes a new key-signing key for example.lab (a .key and a .private file).

Reading the output

$ dnssec-signzone -o example.lab example.lab.zone keys/*.key
Verifying the zone using the following algorithms:
- ECDSAP256SHA256
Zone fully signed:
Algorithm: ECDSAP256SHA256: KSKs: 1 active, 0 stand-by, 0 revoked
                            ZSKs: 1 active, 0 stand-by, 0 revoked
example.lab.zone.signed

• Zone fully signed: every record set has a valid signature from an active key.
• KSKs: 1 active, ZSKs: 1 active: the keys it used. A KSK alone also works (it then signs everything).
• The last line is the file to serve; the server must be told to reload it.

Pitfalls

• The signed file is what is served: editing it by hand breaks the signatures; edit the zone file and sign again.
• A new key-signing key needs a new DS in the parent before the old one goes, or the zone turns bogus.

Run it on real machines