DNSSEC Calculator — DS Record & NSEC3 Hash
Turn a DNSKEY into the DS record your registrar wants — key tag and all three digest types — or hash a name the way NSEC3 does.
How to use
- For a DS record, put in the owner name of the key — the zone being delegated — and paste the DNSKEY. Flags, protocol, algorithm and base64 key is enough, and a whole zone-file line works too because the owner, TTL, class and type are stripped off.
- Read the key tag and the flags first. Flags 257 means the SEP bit is set, which is the key-signing key a delegation normally points at; 256 is a zone-signing key and the page says so rather than letting you submit it by accident.
- Copy the DS line for the digest type your registrar wants — SHA-256 unless told otherwise. The CDS line below it is the same RDATA under a different type, for registrars that pick the DS up from the child zone automatically.
- For an NSEC3 hash, switch mode and give the name, the zone apex it sits under (the NSEC3 record lives one label below it), the salt as hex (empty for none) and the iteration count. The preset reproduces RFC 5155 Appendix A, so you can confirm the page against the specification before trusting it on your own zone.
About this tool
ShowHide
Two DNSSEC values have to be computed rather than looked up, and neither is something a zone file will hand you. The DS record your registrar asks for is a hash of the DNSKEY together with its owner name, prefixed by a 16-bit key tag. The NSEC3 owner name a resolver returns is an iterated hash of the queried name. This page computes both in your browser, against the published test vectors, and says what is wrong with the input rather than encoding it anyway.
The detail people leave out of the DS is the owner name. RFC 4034 §5.1.4 takes the digest over the canonical wire form of the name followed by the DNSKEY RDATA, so the same key at example.com and at example.net gives two different DS records, and a DS copied between zones is simply wrong. Canonical means lowercased and uncompressed, which is why the page normalises the name before hashing it and not after.
The key tag is not an identifier, though it is usually treated as one. It is a 16-bit one’s-complement sum over the RDATA — a checksum — so two different keys can land on the same tag, and RFC 4035 requires a resolver to try every DNSKEY whose tag and algorithm match rather than assuming the first is the right one. Algorithm 1, RSAMD5, does not use the sum at all: its tag is taken straight out of the modulus, an exception the page implements because the specification does.
Three digest types exist and they are not interchangeable in practice. Type 2, SHA-256, is the one to hand over unless asked otherwise. Type 1 is SHA-1 and is deprecated for new delegations though still validated. Type 4 is SHA-384 and correct but not accepted by every registrar. The page emits all three so you can match whichever form a form demands, and the CDS variant alongside, which publishes the same RDATA inside the child zone for automated rollover under RFC 7344.
On the NSEC3 side the substance is mostly a warning. The hash is SHA-1 over the wire name and the salt, re-hashed with the salt once more for each iteration, then written in base32 with the extended hex alphabet. RFC 9276 now recommends zero iterations and an empty salt, and the reasoning is worth understanding: the iterations cost a validating resolver real work on every negative answer, while an attacker enumerating names offline pays that cost once per guess against a dictionary they already hold. The defence never worked, and the page says so when you ask for more than zero.
What this cannot do is tell you the delegation is live. A DS is only meaningful once the parent zone publishes it and the child still signs with the matching key; getting the digest right and the timing wrong takes a domain off the internet for validating resolvers just as thoroughly as getting the digest wrong. Keep the old key in the zone until the new DS has propagated past its TTL.
Frequently asked questions
Why does my DS not match the one my registrar generated?
Almost always the owner name. The digest covers the canonical wire form of the name as well as the key, so a DS computed for example.com does not work at www.example.com or at example.net, and the same key rolled into a different zone needs a fresh DS. Check next that you used the key-signing key (flags 257) rather than the zone-signing key, and that the digest type matches what the registrar stored.
Can two keys really have the same key tag?
Yes. The tag is a 16-bit checksum over the RDATA, so with enough keys collisions are expected rather than surprising, and they have happened in production during rollovers. RFC 4035 §5.3.1 therefore has a resolver try every DNSKEY in the set whose tag and algorithm match the RRSIG, and stop at the first that validates. Nothing breaks; it just costs an extra signature check.
Which digest type should I use?
SHA-256, digest type 2, which RFC 4509 made mandatory to implement and every registrar accepts. SHA-1, type 1, is still validated by resolvers but RFC 8624 says not to publish it for new delegations. SHA-384, type 4, is fine cryptographically and occasionally rejected by registrar interfaces, which is the only reason not to prefer it.
Should I use NSEC3 with a salt and lots of iterations?
No. RFC 9276 recommends zero additional iterations and an empty salt, reversing the earlier advice. The hashing was meant to stop zone enumeration, but an attacker works offline against a dictionary and pays once per guess, while a validating resolver pays for every iteration on every negative answer it handles — so the cost lands almost entirely on the defender. Resolvers now cap or refuse high iteration counts, and this page flags anything above zero.
Is the NSEC3 hash reversible?
Not directly, but it does not have to be. The hash is unsalted-or-barely-salted SHA-1 over a name from a small, guessable space, so the practical attack is to hash a dictionary and compare — which tools like nsec3walker have done for years. NSEC3 raises the cost of enumerating a zone; it does not prevent it. If the names in a zone are genuinely sensitive, the answer is NSEC3 with opt-out plus not putting them in DNS, or online signing with RFC 9077 style minimal responses.
Related tools
DNS Record Reference
Searchable cheat sheet for DNS record types — A, AAAA, CNAME, MX, TXT, NS, SOA, PTR, SRV, CAA, DNSSEC, SVCB / HTTPS — with examples.
Network
Hash Generator (SHA)
Generate SHA-1, SHA-256, SHA-384, and SHA-512 hashes from text.
Developer
File Hash (Checksum)
Compute SHA-1, SHA-256, and SHA-512 checksums of any file.
File
TLSA Record Generator (DANE) & Checker
Turn a certificate into its TLSA records — every selector and matching type — and check an existing record against the certificate you are serving.
Network
PBKDF2 Key Derivation
Derive a key from a password with PBKDF2-HMAC in your browser — pick the hash, iteration count and output length, and read the result as hex or Base64.
Developer
HKDF Key Derivation (RFC 5869, extract-expand)
Derive keys with HKDF and see both halves: the PRK from extract, every T block from expand, and the OKM in hex and base64. RFC 5869 cases built in.
Developer