Self-Hosted DNSSEC Key Management: dnssec-keygen vs ldns-keygen vs Knot DNS keymgr

Introduction

DNSSEC protects DNS responses from forgery by cryptographically signing zone data. But the operational challenge isn’t the signing itself — it’s key management. Generating, rotating, and revoking DNSSEC keys securely is critical: a compromised ZSK can poison an entire domain’s cache, and misconfigured KSK rollovers can make your zone unreachable. This article compares three battle-tested DNSSEC key management toolchains: dnssec-keygen (BIND), ldns-keygen (NLnet Labs), and keymgr (Knot DNS).

dnssec-keygen: The BIND Standard

dnssec-keygen is part of ISC BIND 9, the most widely deployed DNS server. It generates DNSSEC key pairs and outputs them in BIND’s .key/.private file format. It supports every DNSSEC algorithm from RSA/SHA-1 (algorithm 5) to Ed25519 (algorithm 15).

Key Generation Examples

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12

# Generate a Zone Signing Key (ZSK) with ECDSA P-256
dnssec-keygen -a ECDSAP256SHA256 -n ZONE example.com

# Generate a Key Signing Key (KSK)
dnssec-keygen -a ECDSAP256SHA256 -n ZONE -f KSK example.com

# Generate with Ed25519 (algorithm 15)
dnssec-keygen -a ED25519 -n ZONE example.com

# Output files:
# Kexample.com.+013+12345.key    (public key)
# Kexample.com.+013+12345.private (private key)

Key Rotation with dnssec-settime

BIND handles key rotation manually using dnssec-settime:

1
2
3
4
5
6
7
8

# Publish the new ZSK immediately but don't activate for signing yet
dnssec-settime -P now -A +2d Kexample.com.+013+12345

# After 2 days (propagation), start signing with the new key
dnssec-settime -I +30d -D +60d Kexample.com.+013+12345

# Revoke the old key after the new key's signatures have propagated
dnssec-settime -D now Kexample.com.+013+11111

The BIND toolchain requires careful manual orchestration of timing parameters (-P publish, -A activate, -I inactive, -D delete). A single misconfigured time window can create a DNSSEC validation gap.

HSM Integration

1
2
3
4
5

# Generate key in a PKCS#11 HSM (SoftHSM2 for testing)
softhsm2-util --init-token --slot 0 --label "DNSSEC"
dnssec-keygen -a ECDSAP256SHA256 -n ZONE -E pkcs11 example.com

# The private key stays in the HSM; only the public key file is created

ldns-keygen: The NLnet Labs Tool

ldns-keygen from NLnet Labs offers a more scriptable, Unix-philosophy approach. It’s part of the ldns library, which provides C and Python bindings for DNS operations.

Key Generation

1
2
3
4
5
6
7
8

# Generate ECDSA P-256 ZSK
ldns-keygen -a ECDSAP256SHA256 example.com

# Generate Ed25519 KSK
ldns-keygen -a ED25519 -k example.com

# Output RSA key with specific size
ldns-keygen -a RSASHA256 -b 2048 example.com

Scripting Key Rotation

ldns-keygen doesn’t have built-in rollover scheduling, but its clean output format makes scripting easy:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22

#!/bin/bash
# Automated ZSK rotation script for ldns
DOMAIN="example.com"
KEYDIR="/etc/dns/keys"

# Create new ZSK
NEWKEY=$(ldns-keygen -a ECDSAP256SHA256 "$DOMAIN")
echo "New ZSK: $NEWKEY"

# Wait for DNS propagation (TTL × 2)
sleep 7200

# Sign zone with both keys
ldns-signzone -n -o "$DOMAIN" "$DOMAIN.zone" "$NEWKEY" "$CURRENT_KSK"

# Mark old key for deletion after signature expiry
CURRENT_EPOCH=$(date +%s)
EXPIRY=$((CURRENT_EPOCH + 2592000))
echo "Old key expires at: $(date -d @$EXPIRY)"

# Schedule removal via cron
echo "0 0 $(date -d @$EXPIRY +%d) $(date -d @$EXPIRY +%m) * rm $KEYDIR/$OLDKEY.*" >> /etc/crontab

Docker Compose for Testing

1
2
3
4
5
6
7
8

version: "3.8"
services:
  dnssec-lab:
    image: ubuntu:24.04
    command: >
      sh -c "apt-get update && apt-get install -y ldnsutils bind9-dnsutils knot-dnsutils &&
             ldns-keygen -a ECDSAP256SHA256 test.example &&
             cat Ktest.example.*"

Knot DNS keymgr: Automated Key Management

Knot DNS’s keymgr takes a declarative approach: you define a policy, and it handles generation, rotation, and cleanup automatically. This is the most operationally mature solution for teams that want minimal DNSSEC key management overhead.

Policy-Based Key Management

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23

# Define a DNSSEC policy
keymgr example.com init

# Configure policy in Knot's configuration
cat >> /etc/knot/knot.conf << 'EOF'
policy:
  - id: default
    algorithm: ecdsap256sha256
    ksk-lifetime: 365d
    zsk-lifetime: 30d
    zsk-rollover: 14d

zone:
  - domain: example.com
    dnssec-signing: on
    dnssec-policy: default
EOF

# keymgr automatically generates and rotates keys
keymgr example.com status
# Output:
# KSK: active (ID: abc123, expires in 340d)
# ZSK: active (ID: def456, expires in 28d, rollover in 12d)

Automated Rollover

Knot handles the entire ZSK rollover process without manual intervention:

1
2
3
4

Day 0:  ZSK1 active (signing)
Day 16: ZSK2 published (not yet signing)
Day 20: ZSK2 active (signing) + ZSK1 published
Day 30: ZSK1 removed, ZSK2 active

1
2
3
4
5
6

# Force immediate rollover for emergency key compromise
keymgr example.com ds-generate
keymgr example.com rollover

# Check rollover status
keymgr example.com status --verbose

HSM Integration

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12

# PKCS#11 HSM configuration
cat >> /etc/knot/knot.conf << 'EOF'
keystore:
  - id: hsm
    backend: pkcs11
    config: "pkcs11:token=DNSSEC;pin-value=secret /usr/lib/softhsm/libsofthsm2.so"

policy:
  - id: hsm-policy
    keystore: hsm
    algorithm: ecdsap256sha256
EOF

Security Comparison

Why Self-Host Your DNSSEC Infrastructure?

Running your own DNSSEC signing infrastructure gives you complete control over your cryptographic material. When you delegate DNSSEC to a managed DNS provider, they hold your private keys — a compromise at the provider level can poison your entire zone. Self-hosting with HSM-backed key storage ensures that only you control the signing keys, and automated monitoring can alert you to any unexpected zone changes.

The operational burden of manual DNSSEC key rotation is one of the primary reasons many organizations still avoid deploying DNSSEC. Tools like Knot DNS’s keymgr eliminate this pain point by automating the entire lifecycle — from initial key generation to emergency rollover — reducing the risk of misconfiguration that can make your domain unreachable. For teams managing dozens of zones, the difference between manual BIND scripts and Knot’s declarative policy approach is measured in hours of maintenance per month.

For a comprehensive comparison of authoritative DNS servers, see our guide to PowerDNS vs BIND9 vs NSD vs Knot DNS. If you’re interested in DNS-layer security beyond DNSSEC, check our guide to DNS firewall and RPZ implementation.

Understanding DNS protocol internals is essential for secure zone management. Our DNS-over-QUIC encryption guide covers the latest transport-layer security improvements for DNS queries.

FAQ

How often should I rotate DNSSEC keys?

ZSK: Every 30-90 days. Frequent rotation limits the impact of key compromise. KSK: Every 12-24 months. KSK rotation requires updating the DS record at your registrar, so it’s a more involved process.

What happens if my DNSSEC keys expire?

DNSSEC keys don’t technically “expire” — validators check signature validity periods, not key expiry. If signatures expire before new ones are published, validators will reject your zone’s responses (SERVFAIL). Always ensure your signer refreshes signatures before the previous set expires.

Can I use Ed25519 for DNSSEC signing?

Yes. Ed25519 (algorithm 15) is supported by all three tools and is the recommended algorithm for new deployments. It offers 128-bit security with smaller keys and faster signing than RSA. Major resolvers (Google Public DNS, Cloudflare, Quad9) all validate Ed25519-signed zones.

How do I validate that my DNSSEC configuration is correct?

1
2
3
4
5
6
7
8
9

# Check DNSSEC chain with delv (BIND tool)
delv @8.8.8.8 +dnssec example.com

# Online validators
# https://dnsviz.net/ — visual DNSSEC chain analysis
# https://dnssec-analyzer.verisignlabs.com/ — Verisign's validator

# Local validation with ldns
ldns-verify-zone example.com.zone

What’s the difference between algorithm rollover and key rollover?

Key rollover: Replace the key but keep the same algorithm (e.g., new ECDSA P-256 key). This is routine. Algorithm rollover: Switch from one algorithm to another (e.g., RSA to Ed25519). This requires updating DS records, waiting for propagation, and ensuring all resolvers support the new algorithm. Knot DNS’s keymgr is the only tool that handles algorithm rollovers automatically.

Do I need a Hardware Security Module (HSM) for DNSSEC?

For most self-hosted deployments, filesystem-based key storage with strict permissions (0400) is sufficient. HSMs (including software HSMs like SoftHSM2) become important when: (a) you manage high-value domains, (b) you need compliance (PCI-DSS, FIPS), or (c) you want physical separation between your DNS server and signing keys.

💰 想测试你的市场判断力？我用 Polymarket 做预测市场交易——这是全球最大的预测市场平台，从大选结果到技术监管时间线，什么都可以押注。和赌博不同，这是真正的信息市场：你懂的信息越多，胜率越高。我靠预测技术相关事件的走向已经赚了不少。用我的邀请链接注册：Polymarket.com