What is DNSKEY?
DNS public key record
A DNSKEY (DNS public key) record publishes a zone's DNSSEC public key at the zone's apex, so resolvers can check the zone's signatures.
Each signed zone publishes its public keys as DNSKEY records on the zone's own name, for example example.net. IN DNSKEY 257 3 13 JwbF…. The four fields are:
- Flags: 256 for a zone-signing key (ZSK), and 257 for a key with the Secure Entry Point bit set, normally a key-signing key (KSK).
- Protocol: always 3.
- Algorithm: 8 is RSA/SHA-256, 13 is ECDSA P-256 with SHA-256 and 15 is Ed25519.
- Public key: the key itself, in Base64.
The private half signs the zone's record sets, producing RRSIG records. A resolver doesn't trust a DNSKEY just because it's there: it hashes the key and compares the result with the DS record in the parent zone. The DNSKEY set is itself signed, so once the key the DS points to is trusted, every key in the set is trusted.
The traditional design uses two keys: a KSK, referenced by the DS and used only to sign the DNSKEY set, and a ZSK that signs everything else and can be replaced without involving the parent. Many setups now use a single combined signing key (CSK) instead. PowerDNS's pdnsutil secure-zone creates one ECDSA P-256 CSK with flags 257, which keeps things simple with no loss of security. Whichever design you use, a key change has to be coordinated with the parent's DS. If the DS points at a key the zone no longer publishes, validation fails, and resolvers report it as Extended DNS Error 9, "DNSKEY Missing". The PowerDNS on Debian lesson signs a zone, looks at its key, and reproduces that error.
Lessons that use DNSKEY
- PowerDNS on Debian: authoritative, secondary, DNSSEC and recursorTeaches this term · Intermediate · 60 min
Build a complete DNS service on Debian with PowerDNS: authoritative primary and secondary servers with NOTIFY and AXFR, zones by pdnsutil and the HTTP API, DNSSEC signed all the way from a lab root, and a validating recursor for the office.