DNSKEY DNS Record

What the DNSKEY record does

The split into KSK and ZSK is a convenience, not a protocol requirement. One key could do both jobs, but then every rotation would need a parent update. Separating them means the KSK signs only the DNSKEY RRset and changes rarely, while the ZSK signs the ordinary records and can be rolled entirely inside the zone.

The DNSKEY RRset is also the largest answer most zones serve. It carries every active key plus a signature from every key-signing key, and it is what a resolver fetches first when validating a zone it has not seen before.

Zone-file and wire format

The RDATA is flags, protocol, algorithm and the base64-encoded key. Protocol is always 3; any other value makes the record invalid. In flags, bit 7 is the Zone Key flag and bit 15 is the Secure Entry Point hint, which is why you see 256 for a plain zone-signing key and 257 for one marked as an entry point, normally the KSK. The SEP bit is a hint for tooling and changes nothing about validation. Algorithm identifies the signature scheme: 8 is RSA with SHA-256, 13 is ECDSA P-256, 15 is Ed25519. The keys below are truncated.

; flags  protocol  algorithm  public key (base64)
;  257      3         13       KSK — 257 has the Secure Entry Point bit set
example.com.  3600  IN  DNSKEY  257 3 13 oJB1W6WNGn9pJ4CFrbhCFTvNfKZ...

;  256      3         13       ZSK — signs the ordinary RRsets
example.com.  3600  IN  DNSKEY  256 3 13 kR2xQfLm8yTaVd7pNc0BhGsWuE9...

; protocol is always 3. Algorithm 13 = ECDSA P-256/SHA-256,
; 8 = RSA/SHA-256, 15 = Ed25519.

Common uses

Choice of algorithm is mostly a size decision now. An RSA-2048 key is roughly 256 bytes of key material and an ECDSA P-256 key is 64, and since the DNSKEY set is fetched over UDP first, that difference decides whether resolvers get a clean answer or a truncated one followed by a TCP retry. Algorithm 13 is the sensible default for a new zone. For an island of trust with no signed parent, the DNSKEY is what you hand resolver operators as a static trust anchor.

Troubleshooting

Response size is the failure mode people forget. Ask for the DNSKEY set with DNSSEC records included and read the message size dig reports. Once it approaches the 1232-byte EDNS buffer most resolvers advertise, answers get truncated and retried over TCP, and a middlebox blocking DNS over TCP turns that into an outage. Trimming retired keys is the cheapest fix.

The other recurring problem is a partial rollover. If a key is withdrawn while resolvers still hold signatures made by it, validation fails. Overlap generously.

# the key set, with signatures, in readable multi-line form
dig example.com DNSKEY +dnssec +multiline

# how big is the answer? watch for MSG SIZE near the EDNS buffer limit
dig example.com DNSKEY +dnssec | grep 'MSG SIZE'

# force TCP to confirm fallback works from your network
dig +tcp example.com DNSKEY +dnssec +noall +answer

# full validation, showing which key signed what
delv +vtrace example.com SOA

The defining RFC

DNSKEY is type 48, defined in RFC 4034 §2, with resolver behaviour in RFC 4035 and an overview of the suite in RFC 9364. Algorithm numbers are the IANA DNSSEC Algorithm Numbers registry; guidance on which to pick is RFC 8624, rollover procedure is RFC 6781, and static trust anchors are RFC 5011.

Reference and tooling

Every record type and its assigned numeric value is listed in theIANA DNS Parameters registry. To query a live zone from the browser, use theDNS lookup tool. If the record you are chasing is TLS-related, the TLS inspector andCertificate Transparency lookup are usually the next two stops.

DNSKEY record

Zone-file example