DNSSEC signing is a surprisingly complex dance of cryptographic keys and zone file management, often more about operational diligence than deep cryptographic theory.
Let’s watch CoreDNS sign a zone. Imagine we have a zone example.com. with a simple A record:
example.com. IN A 192.168.1.100
To sign this, CoreDNS needs to generate a Zone Signing Key (ZSK) and a Key Signing Key (KSK). The ZSK signs the actual records in the zone, while the KSK signs the ZSK and other keys.
First, we need to configure CoreDNS to enable DNSSEC signing. In our Corefile, we’ll add the dnssec plugin to our zone stanza:
. {
file db.example.com.
dnssec
cache 30
forward . 8.8.8.8
}
db.example.com. is our zone file. The dnssec plugin will automatically read and write this file, adding the necessary RRSIG and NSEC (or NSEC3) records.
When CoreDNS starts with this configuration, it will look for existing keys. If none are found for example.com., it will generate a new KSK and ZSK. This process involves generating cryptographic keys (typically RSA or ECDSA) and publishing them as DNSKEY records in the zone.
Let’s say CoreDNS generates a KSK and a ZSK. It will then create RRSIG records for every record in the zone, signed by the ZSK. For our example.com. A record, we’d see something like this added to db.example.com.:
example.com. IN A 192.168.1.100
example.com. IN RRSIG A 8 2 3600 20231027100000 20231020100000 example.com. <key_tag> <signature_data>
The RRSIG record tells us which record type it’s signing (A), the algorithm used (e.g., 8 for RSA/SHA-256), the number of original records covered (here, 1 for the single A record), the TTL of the original record, the expiration and inception times of the signature, the signer’s name (example.com.), the key tag of the signing key, and the signature itself.
The KSK, being the master key, is also signed by itself (a self-signed signature) and published as a DNSKEY record. It also signs the ZSK’s DNSKEY record. This chain of trust is crucial.
The KSK’s public key needs to be uploaded to the parent zone (e.g., .com.) as a DS (Delegation Signer) record. This is typically a manual step, often done through the domain registrar’s portal. The DS record contains a hash of the KSK, linking the parent zone’s trust anchor to our zone’s KSK.
CoreDNS will periodically re-sign records as their signatures expire. It also handles key rollovers, where it generates new ZSKs and KSKs, publishes them, signs records with the new keys, and eventually retires the old keys. This is managed by the dnssec plugin’s internal logic and configuration parameters.
One critical aspect is managing the zone file itself. If you manually edit the zone file and forget to restart or reload CoreDNS, the dnssec plugin might not pick up the changes correctly, or worse, it might generate signatures based on an outdated zone file, leading to validation failures. Always ensure CoreDNS is aware of zone file changes.
The dnssec plugin can be configured to use NSEC or NSEC3 for authenticated denial of existence. NSEC provides a linked list of signed records, while NSEC3 uses hashing to obscure the names of non-existent records, mitigating "zone walking" attacks. The choice between them impacts performance and privacy.
The next hurdle is managing the DS record in the parent zone, especially during KSK rollovers, which requires careful coordination.