DNSSEC adds cryptographic signatures to DNS answers. When a resolver validates the signature, it knows the answer really came from the domain owner and was not altered on the way. It is the strongest known defense against cache poisoning and DNS redirection attacks.
Still, many organizations do not turn it on. The reason is operational, not technical: signatures expire, keys must be rolled, and the DS record published in the parent zone must stay in sync with the key. If any of this slips, every validating resolver ignores your domain. One morning the ministry website simply does not open.
Automation removes the risk
In NameDefence the life cycle of a signed zone is managed by the Manager:
- Signatures are renewed periodically and whenever records change.
- ZSK rollovers are fully automatic: the new key is published, caches are given time to update, then the old key is withdrawn.
- For KSK rollovers the DS record in the parent zone is checked; the old key is not removed until the new DS is visible.
- Algorithm rollovers (for example RSA to ECDSA) follow the conservative order recommended by the RFCs, signing with both algorithms for a while.
Which algorithm?
ECDSA P-256 (algorithm 13) is recommended for new deployments: small signatures, fast validation, broad support. ECDSA P-384 and Ed25519 are also supported for organizations that want a higher security level. Older RSA zones can be moved to these algorithms without an outage.
Where do the keys live?
Public-sector customers ask this most often. By default, private keys are stored encrypted in the Manager database. For stricter requirements, keys can be generated and stored in a PKCS#11-compatible hardware security module (HSM); signing happens inside the HSM and the key never leaves the device.
DNSSEC with dynamic content
Records whose answers change with health status, such as GSLB, are hard to combine with DNSSEC. NameDefence re-signs the affected records when health changes and applies the pool's fallback rule in the signer exactly as Defender does. Load balancing and disaster failover keep working in a signed zone.
Do not forget the validating side
Signing is half of DNSSEC; validation is the other half. Defender's local resolver validates the chain of signatures starting from the root. A forged or badly signed answer is never handed to the client; it is rejected with an error code that explains why.
In short
The hard part of DNSSEC is not signing but running it flawlessly for years. Once that work is left to automation rather than calendars and people, there is no reason left not to turn it on.