What is DNSSEC and how does it work?

DNSSEC adds digital signatures to DNS data. A validating resolver can detect a forged response or a broken chain of trust. It protects the origin and integrity of records, but does not encrypt DNS queries or automatically make a website trustworthy.

How does the chain of trust work?

The zone operator signs records with a private key and publishes DNSKEY and RRSIG records. The parent zone holds a DS record that connects it to the child zone’s key. A validating resolver follows the chain from a trusted root to the answer. It accepts correctly signed data and can return an error when the chain is broken. RFC 4033 describes the purpose and limits of DNSSEC.

Proof that a record does not exist can also be authenticated, preventing an attacker from simply replacing a negative answer. Most visitors never see signatures directly; the result depends on whether their resolver validates them. A DNSSEC switch in a control panel alone does not prove that the parent DS, published keys and signatures match on every authoritative server.

What does DNSSEC protect, and what does it not?

With validation, DNSSEC makes undetected modification of DNS answers harder. It does not conceal the queried name from the resolver or encrypt traffic to it; DoH and DoT address a different transport privacy problem. DNSSEC also does not replace a TLS certificate, honest website content, registrar account protection or sound zone administration.

If the domain owner publishes a wrong address, DNSSEC can faithfully authenticate that wrong address. Maintain correct A, AAAA, MX and other records regardless of signing. Use a DNS lookup to compare ordinary and validating resolver responses when troubleshooting. Avoid disabling validation for everybody merely to make one broken domain appear to work.

Why might a signed domain stop resolving?

A common cause is a stale parent DS record after changing DNS providers or keys. Expired signatures, inconsistent authoritative servers or a failed key rollover can also break validation. Inspect delegation, current DNSKEY and DS values, RRSIG validity times and the answer from each authoritative server. Record the exact error and test time before changing settings.

Before migrating a signed zone, coordinate the DS update with the new operator and verify its keys. After repair, allow for cached positive and negative answers to expire. For a domain used by mail or an API, prepare a change window and rollback path. Reliable signing automation and monitoring are more valuable than an unchecked enabled status in a dashboard.