DNS was designed without authentication. When your computer asks where a domain lives, it accepts the first plausible answer it receives, and has no way to tell a genuine reply from a forged one.
DNSSEC adds signatures to DNS records so a resolver can verify that an answer came from the domain's real operator and was not altered on the way.
What it protects against
The attack is cache poisoning: an attacker persuades a resolver to store a wrong answer, and everyone using that resolver goes to the attacker's server while typing your domain correctly.
Nothing on your website prevents this, because the visitor never reaches your website. HTTPS helps (the attacker's server would not have a valid certificate) unless they can also obtain one, which is exactly what DNS control makes possible.
That connection is the reason DNSSEC and CAA records belong in the same conversation: one protects the answer, the other narrows who can issue for you.
What it does not do
Worth being direct about, because DNSSEC is often described as broader than it is.
It does not encrypt DNS. Queries and answers are still visible to anyone watching the network, DNSSEC proves that an answer is genuine, not that it is private.
It does not protect a domain whose registrar account is compromised. An attacker who can log in can change the records and re-sign them legitimately.
And it only helps visitors whose resolver validates signatures. Many do; not all.
How the chain works
The mechanism is a chain of trust, and understanding it in outline explains every failure mode.
Your zone is signed with a key. The public part of that key is published as a DS record, not in your zone, but at your registrar, who passes it to the registry for the top-level domain.
A resolver checking your domain asks the registry for the DS record, then verifies your zone's signatures against it. The registry's own records are signed by the root, which is trusted directly.
So the signature lives in one place and the proof lives in another, and both have to agree.
Enabling it
Two steps, in this order.
Sign the zone. In WHM, DNSSEC management lets you generate keys and sign a zone. On shared hosting, ask support. This is a server-level operation.
Publish the DS record at the registrar. Signing produces a DS record. Log in to wherever the domain is registered and enter it there.
Missing the second step is the usual outcome of a half-finished attempt: the zone is signed, no resolver knows to check, and nothing is protected. It also causes no visible problem, which is why it goes unnoticed.
The failure mode is total
This is what makes DNSSEC different from most DNS settings, and it deserves emphasis.
An ordinary DNS mistake affects one record. A DNSSEC mistake makes the entire domain unresolvable for anyone using a validating resolver: not slow, not partially broken: it does not exist.
And the failure is invisible to you if your own resolver does not validate. The site works from your desk and is gone for a large share of the internet.
That asymmetry is the reason for the care described below.
Turning it off, and moving a domain
Removing DNSSEC has to happen in the reverse order of adding it.
Remove the DS record at the registrar first. Wait for it to expire from caches: hours, based on the TTL. Then unsign the zone.
Doing it the other way round leaves resolvers expecting signatures from a zone that no longer has them, which is the total failure above.
The same applies to transfers. Moving a domain to another provider or another DNS host with DNSSEC still enabled breaks it, because the new provider's keys do not match the DS record at the registry. Disable DNSSEC, complete the move, re-enable it afterwards.
Key rollover
Keys are replaced periodically. Where the software handles this automatically, it is not something you manage.
Where it does not, a rollover done incorrectly produces the same total failure. If you are signing zones manually, understand the rollover process before the first key needs replacing rather than at the moment it does.
Checking it
Query the DS record and confirm the registry has it:
dig DS example.com +short
Then confirm validation succeeds. The ad flag in a response from a validating resolver means the answer was authenticated:
dig example.com +dnssec @1.1.1.1
Online DNSSEC analysers walk the whole chain and are worth using after any change. They show exactly where a broken chain breaks, which the command line does not.
Check from outside your own network. A local resolver that does not validate will report success for a domain that is failing everywhere else. The DNS troubleshooting guide explains querying properly.
Should you enable it
For a domain handling payments, credentials or mail that matters, yes, with the caution above.
For a small site whose DNS you rarely touch, it is a reasonable thing to skip. The risk it addresses is real and uncommon; the risk of a mishandled key or a transfer done in the wrong order is neither.
If you enable it, write down that it is enabled. The person who moves the domain in three years needs to know, and by then it will not be you.
The commoner attack is not on DNS itself but on the account that can change it. How to Monitor DNS and Detect Unauthorised Changes walks through watching for that.