DNSSEC documentation, including ours, uses a lot of acronyms. This is what they mean and whether you ever deal with them.
| Term | What it is | Yours to manage? |
|---|---|---|
| DNSKEY | The public key published in your zone | No — generated on signing |
| KSK | Key-signing key. Signs the DNSKEY set; its hash is the DS | No |
| ZSK | Zone-signing key. Signs everything else | No |
| RRSIG | A signature over one record set | No — written automatically |
| RRSET | All records of one type at one name, signed together | No |
| DS | Delegation signer — a hash of your KSK, at the registry | Yes |
| NSEC / NSEC3 | Signed proof that a name does not exist | No — NSEC3 here |
| Trust anchor | The root's key, known to resolvers in advance | No |
| Chain of trust | Root vouches for TLD, TLD vouches for you | — |
| Validation | The resolver's check that signatures hold | — |
| SERVFAIL | What a resolver returns when validation fails | — |
ad flag | Authenticated data — validation succeeded | — |
+cd | Checking disabled — ask a resolver to skip validation | — |
Only one row says yes. That is the useful summary: of everything DNSSEC involves, the DS record at your registrar is the only piece you handle, and it is where essentially every failure comes from.
Two commands worth remembering
dig +short DS example.com # what the parent publishes about you
dig +cd example.com @1.1.1.1 # the same query, without validationThe first tells you whether the chain is joined. The second, compared against the same query without +cd, tells you whether validation is the thing failing.
Related
Last reviewed 2026-09-16.
Not what you needed?
Open a ticket from the control panel, or use the contact form if you cannot sign in. If a domain is down, the status page is the fastest way to find out whether it is us.