What DNSSEC is and when to turn it on

Every visit to a website begins with a DNS question: what address answers for this name? By default, the resolver asking that question has no way to prove the answer is genuine—it simply trusts what arrives. DNSSEC, the Domain Name System Security Extensions, adds cryptographic signatures so a validating resolver can check that a DNS answer really came from the domain’s zone and was not altered along the way.

What DNSSEC actually does

When a zone is signed, its records are published together with signatures. A resolver that validates DNSSEC checks those signatures against the zone’s public keys, and checks those keys against a DS record held one level up—at the registry for your domain’s ending. That link continues upward to the DNS root, forming a chain of trust: root vouches for the registry, the registry vouches for your domain, and your domain’s keys vouch for its records.

The practical result is integrity. A forged or tampered answer fails validation instead of being silently accepted. This matters for more than the website address: MX, SPF, DKIM, and verification records that email delivery depends on are DNS records too. A public lookup, such as an RDAP registration-data result, will typically show whether a domain is signed.

What DNSSEC does not do

DNSSEC verifies; it does not hide. Queries and answers remain readable in transit—privacy is a separate concern addressed by other transports. It does not encrypt or secure the website itself; that remains the job of TLS and the practices behind the site. It does not stop a look-alike domain from fooling a customer, and it only helps when the resolver on the other end actually validates, which is common but not universal.

No single checkbox makes a domain safe, and DNSSEC is no exception. It removes one class of tampering, nothing more.

The case for turning it on

If your DNS host can sign the zone automatically and your registrar accepts the DS record without friction, DNSSEC adds meaningful integrity at low ongoing effort. Signed zones protect the records that other systems quietly rely on—email routing, sender authentication, service verification—against forged answers. Some industries and counterparties also expect it, and a signed zone is the foundation newer verification technologies build on.

The case for waiting

DNSSEC’s failure mode is unusually unforgiving. If the DS record and the zone’s keys ever disagree—after a DNS provider change, an expired key, or an incomplete setup—validating resolvers do not fall back to the unsigned answer. They return an error, and for much of the internet the domain is simply down until the mismatch is fixed.

That risk concentrates around transitions. Moving DNS providers with DNSSEC enabled requires a deliberate sequence: remove the DS record and let it expire from caches first, or roll keys across both providers. If a provider migration is on the horizon, or if keys would be managed by hand, enabling DNSSEC first creates work in the wrong order. Support also varies—not every domain ending or registrar handles DS records the same way.

A sensible decision path

Enable DNSSEC when three things are true: the DNS host signs and rotates keys automatically, the registrar publishes the DS record for your domain’s ending, and no DNS provider change is planned. Verify resolution after enabling, and record where the keys live. If any of the three is uncertain, the honest answer is not yet—an unsigned zone that resolves reliably serves a business better than a signed one that fails validation.

For domains under Doory’s management, DNSSEC is treated as part of DNS administration: enabled where the provider chain supports it cleanly, sequenced carefully around any migration, and monitored like the rest of the zone.

The useful conclusion

DNSSEC answers one narrow question well: can this DNS answer be trusted as published? Turn it on when your providers automate it and your zone is stable. Leave it off, deliberately and temporarily, when a transition is coming. Either choice should be a decision someone owns—not a default nobody remembers making.

Related service:Search and manage domains.