Toggling DNSSEC in a panel feels like a security win. An hour later the site and mail stop resolving: validating resolvers return SERVFAIL. The classic cause is a DS mismatch — the DS digest in the parent (registry) does not match the DNSKEY in your zone. When the chain of trust breaks, secure resolvers refuse the answer; it looks like an outage.
On ns1.eurovdc.eu / ns2.eurovdc.eu you manage DNSSEC with the zone. Even if MX securemail.eurovdc.eu and SPF v=spf1 mx ip4:45.84.90.12 -all are correct, a DNSSEC failure blocks A and MX alike. Record management: change nameservers and manage DNS records.
DS, DNSKEY, and the chain
The child zone publishes a DNSKEY (often a KSK). The parent holds a DS digest of that key. Resolvers validate parent DS → child DNSKEY → RRSIG. An old DS, wrong algorithm, or wrong digest type breaks the chain. Leaving a previous provider’s DS after a nameserver move has the same effect.
Mistakes that take the site down
- Enabling DNSSEC in the child without publishing DS at the registry — or DS present with no child keys.
- Rotating keys: publishing a new DNSKEY, deleting the old one before updating DS.
- Moving nameservers to EuroVDC while the old DS remains at the registry.
- Pasting a DS with the wrong keytag or algorithm.
Safe enable order
- Stabilize authoritative nameservers (
ns1/ns2.eurovdc.eu). - Enable DNSSEC on the authoritative side; record the generated DS parameters.
- Add the same DS at the registrar/registry; wait for parent TTL/propagation.
- Verify with
dig +dnssecand an external DNSSEC checker (AD flag / chain). - On rotation: overlap keys first, update DS, then remove the old key.
Emergency recovery
If SERVFAIL is widespread, remove or replace the bad parent DS and repair child signatures per provider docs. Temporarily disabling DNSSEC can restore reachability only if the registry DS is cleaned too. Fix the chain — do not “rewrite” corporate email records as a substitute.
FAQ
Is DNSSEC mandatory?
No. Done right it protects integrity; a bad DS causes outages. Plan parent/child steps before enabling.
Does only the browser fail?
No. Any client using a validating resolver (including mail) can get SERVFAIL. Some recursive resolvers skip validation, so symptoms look partial.
What about DS during a nameserver transfer?
Do not blindly keep the old DS until the new authority is DNSSEC-ready. Republish DS for the new DNSKEY or remove DS temporarily.
dig shows NOERROR but the site is gone?
Your resolver may not validate DNSSEC. Retry with +dnssec and a known validating resolver; inspect DS/DNSKEY match.
Is deleting DS safe?
Removing parent DS breaks the chain and stops validation — often restoring resolution in an emergency. The lasting fix is a correct DNSKEY+DS pair or intentional DNSSEC off.
