What a DNSKEY record contains
Every DNSSEC-signed zone publishes its public keys in DNSKEY records at the apex. The wire format is four fields: flags, protocol, algorithm and the key itself. A typical record reads 257 3 13 followed by a base64 blob. Flags 257 means bit 7 (zone key) and bit 15 (secure entry point) are set, protocol is always 3, and algorithm 13 is ECDSA P-256 with SHA-256.
Splitting keys into a KSK and a ZSK is a convenience, not a requirement. The KSK changes rarely because changing it means updating the DS at the parent. The ZSK can be rolled often without touching the registrar. This tool labels the role from the secure entry point bit alone.
Reading the table and the status box
Each row shows Role, Key Tag, Algorithm as number and name, Flags, TTL and the public key with a Copy button. The records are fetched over DNS-over-HTTPS from a validating resolver with the DNSSEC OK bit set, so the TTL is the remaining cache time at that resolver.
The box above the table reads the resolver's AD (authenticated data) flag. DNSSEC validated means the resolver checked signatures from the root down to this zone. Records found but not validated means keys exist but the resolver could not authenticate them, which almost always means the zone is signed but the parent has no DS record for it.
No DNSKEY records at all means the zone is not signed, or you queried a subdomain that is not its own zone. An error naming a DNS status (for example status 2, SERVFAIL) is different: the validating resolver refused to answer, which happens when a DS exists but matches no key.
Rollovers and why you may see extra keys
During a key rollover, old and new keys are published together so that resolvers holding cached signatures keep validating. A ZSK pre-publish rollover shows two 256 rows for a while. A KSK rollover shows two 257 rows until the parent's DS is switched and the old key is withdrawn. Keys that linger for months usually mean a rollover was started and never finished.
Changing DNS providers is the rollover people forget: the new provider signs with its own keys, so the DS at the registrar must be replaced before the old provider is switched off. If the DS still points at the old key, validating resolvers fail the whole domain. The DS Record Lookup shows what the parent currently publishes.
- Two ZSKs, one KSK: ZSK rollover in progress, expected to clear within a few TTLs.
- Two KSKs: KSK rollover. Make sure the DS at the parent covers the key that will remain.
- KSK tag absent from every DS record: the chain is broken for that key. Fix the DS before withdrawing any other key.
- Only a 257 key: a combined signing key, a valid and increasingly common setup.
Algorithms: what to run and what to retire
The algorithm column decides both security and response size. RSA keys of 2048 bits produce large records that push responses past the UDP limit. ECDSA P-256 (13) gives shorter keys and signatures with no loss of security, and Ed25519 (15) is smaller still. RFC 8624 lists 5 and 7 as not recommended for signing because they rely on SHA-1, and some validators already treat SHA-1 signatures as insecure, which quietly turns a signed zone into an unsigned one.
A row labelled Unknown with a number means the resolver returned an algorithm this tool does not name. That is rare. Check the signing configuration.
What this lookup does not check
The tool reads keys and the resolver's verdict. It does not verify RRSIG signatures itself, check signature expiry dates, or confirm that the DS digest matches the key byte for byte. For the DS side use the DS Record Lookup, and for a single pass/fail on the whole chain run the DNS Health Checker, which compares DS key tags with the published KSKs.