DNSSEC

Each record set in a signed zone is accompanied by an RRSIG record holding a signature. A validating resolver checks that signature against a public key published as a DNSKEY record in the same zone.

The parent zone publishes a DS record — a hash of the child's key — which is what links the child to the parent. That chain continues up to the root, whose key is distributed with resolver software.

Proving that a name does not exist is handled separately, by NSEC or NSEC3 records, because an unsigned denial would otherwise be forgeable.

The guarantee is integrity and origin authenticity of the DNS data. It says nothing about the server the address points to.

Cache poisoning, where an attacker injects a forged answer into a resolver's cache and sends everyone using that resolver to the wrong address.

On-path tampering with DNS answers, which is otherwise trivial because plain DNS has no integrity protection at all.

It does not encrypt anything. DNS over HTTPS and DNS over TLS address confidentiality, and the two concerns are orthogonal — a domain can have either, both, or neither.

It does not make a website secure. A perfectly signed zone can point at a compromised server, and it does not replace TLS.

A signature has an expiry. If re-signing fails and the signatures lapse, validating resolvers refuse the answers and the domain becomes unreachable for anyone using one — which is a large and growing share of the internet.

A key rollover done incorrectly, where the DS record at the parent no longer matches the key in the zone, produces the same outcome.

The failure is total and it is not gradual: the domain does not degrade, it stops resolving for validating clients while continuing to work for non-validating ones, which makes the reports confusing.

This is why DNSSEC is best operated by a provider that automates signing and rollovers rather than managed by hand.

`dig example.com +dnssec` shows RRSIG records alongside the answer when the zone is signed.

The `ad` flag in the response header indicates that a validating resolver checked the chain and it held.

`dig example.com DS +short` queried at the parent shows whether the delegation is actually linked; a signed zone with no DS record at the parent is not validated by anyone.

After enabling it, verify with a validating resolver from outside your network. A zone that validates internally and fails externally is the case the parent DS record explains.