The problem it solves
DNS is how a name becomes an address. Someone types your domain, their computer asks a chain of servers where it lives, and an answer comes back.
Plain DNS has no way to prove that answer is genuine. It is a shouted reply with no signature on it. If an attacker can slip a fake answer in first, the visitor goes to their server, sees your domain in the address bar, and has no reason to doubt it.
DNSSEC closes that gap. Every answer for your zone gets signed, and the resolver asking the question can verify the signature before it believes the answer. A forged reply has no valid signature, so it gets thrown away.
Worth being clear about the boundary: DNSSEC protects the lookup, not the connection. Encrypting the traffic afterwards is HTTPS. They solve different halves of the same trust problem.
The chain of trust
A signature is only worth as much as your confidence in the key behind it. DNSSEC handles that by making each level of DNS vouch for the one below it.
- →Your DNS host signs the zone. It holds the keys and signs every record you publish.
- →Your registrar publishes a DS record. DS stands for Delegation Signer. It is a fingerprint of your signing key, handed up to the parent zone, for example .com.
- →The parent vouches for you. A resolver walks down from the root, to .com, to your domain, checking each link. Break any link and verification fails.
How you actually turn it on
The mechanics are less intimidating than the theory. There are two places involved, and the order matters.
- 1.Enable DNSSEC at your DNS host, wherever your records actually live. It generates the keys and signs the zone.
- 2.It then shows you a DS record, a short set of values including a key tag, an algorithm number, a digest type and a digest.
- 3.Add that DS record at your registrar, where the domain is registered. This is often a different company to your DNS host, which is the part that confuses people.
- 4.Wait. Propagation can take hours. Do not judge it after five minutes, and do not change anything while it settles.
The genuine risk, stated plainly
Most DNS mistakes are partial. A bad TXT record breaks one thing. DNSSEC is different, and you should know this before you switch it on.
A broken DNSSEC setup takes your whole domain offline. Not slow, not degraded. Resolvers that validate will refuse every answer for your domain, because a bad signature is treated as evidence of an attack. Website, email, everything.
There are two common ways to get there:
- →A DS record pointing at keys that no longer exist. This happens when you move DNS hosts, or turn DNSSEC off at the host, while leaving the DS record sitting at the registrar. The parent still says "verify against this key" and there is no key.
- →Removing it in the wrong order. To disable DNSSEC safely, remove the DS record at the registrar first, wait for that to propagate fully, and only then turn off signing at the DNS host. Doing it the other way round is exactly the broken state above.
Should you bother?
Honestly, it depends on what you have to lose. If your domain handles logins, payments or anything a convincing impostor could profit from, DNSSEC is worth doing properly and worth documenting so the next person does not undo it.
If it is a brochure site and nobody in your team is comfortable with DNS, a well configured certificate and solid email records earn you more safety per hour spent. DNSSEC is not a box to tick casually. It is a commitment to maintaining a chain, including the day you change providers.
You can see what your domain looks like from the outside right now with our free check.
We have step by step instructions for every major platform, including the ones that will not let you.
See the DNS fixes for your platform