EnterraHost
DNSSEC signs a domain's DNS answers so a resolver can tell a forged reply from a real one. Without it, a resolver has no way to know whether the answer it received came from your nameservers or from something that answered first.
Turning it on needs two records in two different places, and that is where most of the confusion comes from.
Signing, and the chain the registry holds
Your DNS provider signs the zone. That produces a public key, published as a DNSKEY record, and a signature attached to every answer.
The registry never reads your zone. It holds one record, the DS, which is a digest of that key. A validating resolver walks down from the top of the DNS tree, reaches the registry, reads the DS, then asks your nameservers for the key and checks that the two agree.
Both halves have to exist. A signed zone with no DS at the registry is simply unsigned as far as the world is concerned. A DS pointing at a key that does not match is worse, because resolvers then refuse to serve the domain at all.
Turning it on
Open DNS Management in the toolbox, open the domain, and press DNSSEC. What the panel asks for depends on who serves your DNS.
If we serve your DNS, the panel says so and signs the zone for you. Press Enable DNSSEC. Once the zone is signed the panel offers Publish to registrar, and that press is what puts the DS in front of the registry. It is separate on purpose, because it writes to the registry and a wrong value there is the one change that stops a domain resolving.
If your DNS is somewhere else, such as Cloudflare, that provider signs the zone and the toolbox only carries the key to the registry. The panel asks for three values. Algorithm, which has to match the key. Flags, which are 257 for a key-signing key. And the public key itself, pasted as base64.
Which record goes where
Cloudflare shows a DS record and tells you to add it at your registrar. Our panel does not want that record. It wants the DNSKEY, and Openprovider computes the DS from it.
Copy the key, not the digest. Both sit inside the same dialog, one under the other, which is how the wrong one gets pasted.
A zone usually publishes two keys. The one needed here is the key-signing key, flags 257. The other is the zone-signing key, flags 256, and adding it produces a second DS that points at the wrong key.
The key is long. Dialogs and dig both wrap it across lines, and a half-copied key produces a DS that looks valid and never matches.
Checking it
| Command | What a working setup returns |
|---|---|
dig DS yourdomain.com | A DS line with a key tag, an algorithm and a digest type |
dig +dnssec yourdomain.com | The ad flag in the header, which means the resolver validated the answer |
The flag is the useful one. A resolver that cannot validate returns the answer without it, and a DS that disagrees with the key produces a failure instead of an answer.
Allow an hour or two before deciding it has not worked. The DS has its own TTL at the registry, and a resolver that already holds the old state keeps it until that expires.
Turning it off
Remove the DS at the registrar first, then stop signing at the DNS provider. The other order leaves a DS pointing at keys that are no longer served, and every validating resolver fails the domain until the DS is gone.
The toolbox disables both from the same panel, which keeps them in that order.