DNSSEC explained

DNS answers can be forged: an attacker who races or poisons a resolver can send users to the wrong server. DNSSEC adds digital signatures so a validating resolver can prove an answer came from the zone owner.

How the chain works

• The zone publishes public keys in DNSKEY records: a key-signing key (KSK) and a zone-signing key (ZSK).
• Every record set is signed with the ZSK; the signature lives in an RRSIG record with validity dates.
• The parent zone publishes a DS record containing a hash of the child's KSK, and the parent's own DS is in its parent, up to the root, whose key resolvers trust by configuration.

A resolver that validates successfully sets the AD (authenticated data) flag, which the DNS facet reports as "DNSSEC validated".

The two failure modes

1. DS does not match any DNSKEY. Usually the zone rolled its keys without updating the DS at the registrar, or the DS was copied wrongly. Validating resolvers return SERVFAIL for the whole zone.
2. Expired signatures. Signatures carry an expiry; if re-signing stops, the zone goes dark for validators after the expiry date even though the records are fine.

Both look like "the site is down for some people" because non-validating resolvers keep working.

Should you enable it

If your DNS provider offers automatic signing and key rollover, and your registrar can accept the DS record, yes. If you would be managing keys by hand, weigh the operational risk; a broken DNSSEC setup causes more outages than the attacks it prevents.

Findings on whois.me.uk

DNSSEC-VALIDATED, DNSSEC-NOT-VALIDATED (records exist but validation fails), DNSSEC-DS-WITHOUT-KEY (dangerous), DNSSEC-UNSECURED-DELEGATION (signed but no DS) and DNSSEC-OFF.