What Is DNSSEC?

DNSSEC adds cryptographic signatures to DNS records so a resolver can verify that an answer genuinely came from the authoritative source and was not altered in transit. It addresses a specific weakness: DNS was designed without authentication, so a forged response that arrives first is accepted.

It is narrower than the general practice of DNS security, and it is the only thing that addresses record integrity.

What it does and does not provide

It provides authenticity and integrity — confirmation that a record is genuine and unmodified, and authenticated denial of existence, so an attacker cannot suppress a record by claiming it does not exist.

It provides no confidentiality. Queries and responses remain readable in transit, which is what DNS over HTTPS and DNS over TLS address. The two are complementary rather than alternatives, and they are frequently confused.

Why adoption remains partial

Signing requires key management, and the operational consequences of getting it wrong are severe: an expired signature or a mismatched delegation makes the domain unreachable for validating resolvers, and the failure is total rather than degraded.

That risk, combined with a chicken-and-egg dynamic — signing helps only where resolvers validate, and validation matters only where domains are signed — has kept deployment uneven. Automation in modern DNS platforms has reduced the operational burden considerably, which is gradually changing the calculation.

The practical position

Enabling validation on your resolvers is low risk and worth doing: it means your users benefit from signatures published by others. Signing your own domains protects your users and customers from response forgery, and is most clearly justified for domains where impersonation would be damaging — authentication endpoints, payment flows, software update infrastructure.

Where the operational risk concentrates

Two moments carry most of the risk. Key rollover, where an incorrectly sequenced change breaks validation until it propagates. And delegation changes, where the record in the parent zone must match the keys in the child — a mismatch makes the domain unresolvable for validating resolvers.

Registrar and DNS provider changes are therefore higher-risk operations for signed domains than for unsigned ones, and they are frequently performed by people who do not know the domain is signed.

Automation handles this well where the platform supports it, which is the strongest practical argument for signing through a managed provider rather than operating the process manually.

It also pairs naturally with certificate transparency monitoring. Both address the same underlying concern — that someone may impersonate your domain — from different angles, and an organisation doing one is generally in a position to do the other cheaply.

A common mistake worth avoiding

Whatever else is on the list, the answer worth establishing first is whether your resolvers validate signatures published by others. It is a question that can be settled in a day, it requires no procurement, and the answer determines whether the rest of the programme is addressing the largest exposure or a smaller one that happened to be easier to see.

Where to start

Enable validation on your resolvers first. It is the lower-risk half, it benefits your users immediately, and it requires no changes to your own published records.

See DNS security. GuardsArm runs security program reviews.