Signing your zone with DNSSEC
DNS was designed with no way to tell a real answer from a forged one. DNSSEC adds that missing signature — so a resolver can prove the address it got for your domain really came from you.
Plain DNS has no authentication: whatever answer a resolver receives, it believes. That is what makes cache poisoning possible — an attacker who slips in a forged answer can send your visitors to their server. DNSSEC closes that by signing your records so forgeries can be detected.
How the trust is built
You sign your zone with a private key. Resolvers check those signatures using your public key — and they trust your public key because its fingerprint, the DS record, is published in the parent zone by your registrar. That chain, from the root down to your domain, is what makes a signature meaningful.
The two moving parts
- Signing the zone — your DNS provider or your own authoritative server does this
- The DS record — you place this at your registrar, linking your keys into the chain
The rollover trap
If you sign your zone but the DS record at the registrar does not match your keys — because a key rolled over and the DS was not updated — validating resolvers will reject your domain entirely. Not slow: gone, for everyone whose resolver checks DNSSEC. Key rollovers must keep the DS in step, which is why automation (or a provider that handles it) matters.
When it is worth it
DNSSEC is most valuable for domains where a forged answer would be costly — anything handling logins, payments or mail. It pairs naturally with hardening TLS: TLS proves you are talking to the right server, DNSSEC helps prove you were sent to the right place to begin with.
Test before you trust it
After enabling, verify the chain validates with a DNSSEC checker before you rely on it. A broken chain fails closed, so a quiet mistake takes the domain down rather than merely weakening it.
Still stuck? Mail support@novogara.com — an engineer answers, at any hour. Back to the knowledge base