A DNSKEY record publishes public key material for a signed zone. RRSIG
records identify the DNSKEY algorithm and key tag used to validate a signature.
A parent DS can authenticate selected child DNSKEY data and extend the chain of
trust into the child zone.
Purpose and type code
IANA registers DNSKEY as type code 48
[1]. RFC 4034
defines its flags, protocol, algorithm, and public-key fields
[2].
The fields are:
- flags: bit field describing properties such as Zone Key and Secure Entry Point;
- protocol: value 3 for DNSSEC;
- algorithm: numeric DNSSEC algorithm identifier; and
- public key: algorithm-specific public material, normally shown in base64.
Common flag values are 256 for a zone key and 257 when the Secure Entry Point bit is also set. Operational labels such as ZSK and KSK describe how an operator uses keys; validate the actual flags, signatures, and DS relationship.
Presentation format
example.com. 3600 IN DNSKEY 257 3 13 (
EXAMPLEBASE64PUBLICKEYMATERIALNOTFORPRODUCTION
)The example is illustrative and is not valid production key material. Long public keys can be split across whitespace in zone-file presentation. DNS carries one public-key field.
The private signing key is never published in DNS. Do not paste private keys, provider secrets, or recovery material into ClueDNS or a public zone.
Owner-name and coexistence rules
The DNSKEY RRset normally appears at the signed zone apex. It can contain several keys during routine operation, rollover, algorithm transition, or a supported multi-signer design.
DNSKEY coexists with SOA, NS, and other apex data. The RRset itself is signed by one or more RRSIG records. A DS in the parent identifies child key material; a DS placed only in the child does not authenticate the delegation.
Delegated subzones have independent DNSKEY RRsets and parent DS relationships. Do not copy apex keys into a child or assume one signed zone covers another delegation.
Caching and changes
DNSKEY, RRSIG, and parent DS data have separate TTLs and lifetimes. Removing a key because the current provider no longer uses it can break validators that still rely on cached DS, DNSKEY, or signatures.
RFC 6781 documents key rollover and parent interaction timing [4]. Prepublish and retain key material for the procedure’s required overlap. Do not combine an unreviewed key change with a nameserver migration.
Security and operational limits
DNSKEY contains public material; publishing it does not reveal the private key. Security depends on private-key custody, supported algorithms, correct signing, timely rollover, and a matching trust path.
RFC 4035 defines how validators authenticate DNSKEY and use it to validate signed RRsets [3]. A present DNSKEY RRset does not prove that signatures are current, negative answers are authenticated, parent DS matches, or validation succeeds.
DNSSEC authenticates DNS data. It does not encrypt queries or verify website, email, or application behavior.
Verify
Use the DNS Lookup pathway to observe DNSKEY through named resolvers, then query every intended authority directly:
- capture the complete DNSKEY RRset and TTL;
- compare flags, protocol, algorithm, key tag, and public key;
- confirm every authority publishes the intended set;
- inspect the DNSKEY RRset’s RRSIG inception and expiration;
- verify representative positive and negative signed answers;
- query the parent DS and match every field to the intended key; and
- test a named validating resolver and record the validation state.
A provider-generated key tag alone is not sufficient comparison evidence.
Next step
Use Enable or migrate DNSSEC safely for an ordered parent-and-child change. If validation already fails, use Diagnose DNSSEC bogus after a change.