DNSSEC keys are the cryptographic backbone of DNSSEC, enabling domain owners to cryptographically sign their DNS records and allowing resolvers to verify the authenticity and integrity of those records. Managing these keys effectively is crucial for maintaining a secure and trusted DNS infrastructure.
Let’s see DNSSEC key management in action with BIND.
Imagine you have a zone, example.com, that you want to secure with DNSSEC. You’ll need to generate a Key Signing Key (KSK) and a Zone Signing Key (ZSK). The KSK is used to sign the DNSKEY record set (which includes the ZSK), and the ZSK is used to sign the rest of your zone data.
Here’s how you might generate these keys using dnssec-keygen:
# Generate a KSK (key type RSA, algorithm RSASHA256, key size 2048 bits)
dnssec-keygen -a RSASHA256 -b 2048 -n ZONE example.com
# Generate a ZSK (key type RSA, algorithm RSASHA256, key size 2048 bits)
dnssec-keygen -a RSASHA256 -b 2048 -n ZONE -f KSK example.com
This will produce two files for each key: a .key file (containing the public key) and a .private file (containing the private key). The filenames will look something like Kexample.com.+008+12345.key and Kexample.com.+008+12345.private.
Next, you need to incorporate these keys into your BIND zone file. You’ll add the public keys to your zone file, typically at the beginning:
$TTL 3600
@ IN SOA ns1.example.com. admin.example.com. (
2023102701 ; serial
3600 ; refresh
1800 ; retry
604800 ; expire
86400 ; minimum TTL
)
; DNSSEC Keys
@ IN NS ns1.example.com.
@ IN NS ns2.example.com.
; KSK
Kexample.com. +008+12345 IN DNSKEY 257 3 8 AwEAAa... (rest of public key)
; ZSK
Kexample.com. +008+54321 IN DNSKEY 256 3 8 AwEAAb... (rest of public key)
; Signed Records (example A record)
www IN A 192.0.2.1
With these keys in place, you can then sign your zone using dnssec-signzone:
dnssec-signzone -A -N INCREMENT -o example.com -t example.com.zone
The -A flag tells dnssec-signzone to automatically generate inline RRSIG records. -N INCREMENT ensures that the serial number of the zone is incremented after signing. This command will create a example.com.zone.signed file.
Your BIND configuration (named.conf) would then point to this signed zone:
zone "example.com" {
type master;
file "example.com.zone.signed";
key-directory "/etc/bind/keys/example.com"; // Where your .private files are
};
When BIND reloads this zone, it will use the private keys (from the key-directory) to generate the RRSIG records for all your DNS records. Resolvers fetching example.com will receive the DNSKEY records and the RRSIG records, allowing them to verify the authenticity of the zone data.
The most surprising true thing about DNSSEC keys is that the KSK is not used to sign the zone data directly; its primary role is to sign the DNSKEY record set itself. This creates a chain of trust where the KSK’s public key is published in the parent zone (e.g., .com), and the KSK’s corresponding private key is used to sign the ZSK’s public key, which is then used to sign the actual zone records. This separation allows for more frequent ZSK rollovers without impacting the parent zone’s trust anchor.
A common point of confusion arises with key rollovers, especially when using dnssec-signzone directly. While dnssec-signzone can manage the signing process, BIND’s built-in dnssec-policy feature offers a more automated and robust way to handle key generation, activation, and rollovers. Using dnssec-policy involves defining policies in named.conf that dictate key types, algorithms, key lengths, and rollover schedules. BIND then takes over the lifecycle management of the keys, including generating new keys, publishing them, activating them for signing, and eventually retiring old ones. This significantly reduces the manual effort and potential for error associated with key management.
The core mechanism for DNSSEC validation relies on the resolver having a trusted "trust anchor." This trust anchor is typically the public KSK of the root zone, but for your own zones, it’s the public KSK that has been uploaded to the parent zone. When a resolver receives a DNSSEC-signed response, it first verifies the signature on the DNSKEY record set using the KSK’s public key. Then, it uses the ZSK’s public key (found within that signed DNSKEY record set) to verify the signatures on all other records in the zone. This recursive validation process ensures that the entire zone is trustworthy.
The next hurdle you’ll encounter is managing the transition of keys to the parent zone, which involves secure delegation and DNSKEY submission.