DNSSEC for .ie Domains: What the DS Record Does and How to Avoid SERVFAIL
DNSSEC helps a resolver verify that DNS answers came from the authorised zone and were not altered in transit. It does this through signed records, public keys and a chain of trust that begins at the parent registry. For an Irish business domain, DNSSEC can be an important security control—but only when the parent DS record and the active DNS zone agree.
The most damaging DNSSEC mistake is not “DNSSEC is on”. It is an incomplete change: the old DS record remains at the .ie registry while the domain now points to a provider serving an unsigned or differently signed zone. Validating resolvers can then return SERVFAIL, even though some non-validating checks appear normal.
The DNSSEC chain in plain language
A zone signs its DNS records with a private key. It publishes a DNSKEY and signatures. The parent zone publishes a DS record that identifies the child’s signing key. A validating resolver follows the chain from the trusted root to the .ie parent and then to the domain’s zone. If the signatures and key digests match, the answer is authenticated.
If a domain is intentionally unsigned, the parent must not publish a stale DS record. If it is signed, the DS must match the current key rollover state. DNSSEC is therefore a coordination problem between the DNS provider, registrar and registry—not just a checkbox in one dashboard.
DNSSEC terms you should recognise
- DS record: the delegation signer record published by the parent, such as .ie. It points to a child DNSKEY digest.
- DNSKEY: a public key published by the signed child zone.
- RRSIG: a signature covering a DNS record set.
- KSK and ZSK: key-signing and zone-signing roles used by many DNS providers. The provider manages their rollover details.
- SERVFAIL: a resolver failure often seen when validation cannot complete. It is not the same as “the domain does not exist”.
When should DNSSEC remain enabled?
Keep DNSSEC enabled when the DNS provider supports a documented rollover process and the team can monitor the chain. It reduces the risk of forged DNS answers, particularly for services that rely on DNS for authentication or trust. Make it part of the domain change runbook rather than enabling it once and forgetting it.
For a high-value business domain, document who controls the DNS provider, who can edit the registrar DS record and how an emergency rollback is approved. Store recovery information securely and test the process with a non-critical domain if possible.
Moving a signed domain to another DNS provider
Do not delete the old zone or nameservers first. Confirm that the new provider can import or recreate the zone and publish DNSSEC keys. Follow the provider’s key-rollover procedure and add or update the DS record only when the new key is live and verified.
- Inventory website, email, verification and service records.
- Prepare the new unsigned or signed zone without changing delegation.
- Confirm the new provider’s DNSSEC algorithm, key tag, digest and rollover instructions.
- Coordinate the nameserver and DS changes in the documented order.
- Query the parent, authoritative servers and validating recursive resolvers.
- Keep the old configuration available until every critical service is tested.
For Cloudflare, use the assigned nameservers and its DNSSEC workflow. For another provider, use that provider’s exact instructions. Never copy a key tag or digest from a screenshot or an unrelated zone.
Removing DNSSEC safely
Sometimes a customer intentionally moves to a provider that does not support the existing signing setup. The safe sequence is to follow the registrar or registry procedure for removing the DS record, then wait for the parent change to publish before assuming an unsigned zone is healthy. The old DNS provider may also require DNSSEC to be disabled.
Removing a DS record is a security change and should be documented. It is not a workaround for an unexplained DNS failure. If a domain is still signed at the authoritative provider, do not remove the parent DS without understanding the consequences.
How to investigate SERVFAIL
- Check the parent’s DS response from more than one authoritative .ie nameserver.
- Check the domain’s NS delegation and query each authoritative nameserver directly.
- Compare DNSKEY and RRSIG records with the DNS provider’s current status.
- Query a validating resolver such as Google Public DNS or Cloudflare DNS.
- Check whether a recent nameserver, DNSSEC or provider migration is still pending.
If the parent publishes a DS but the child returns no DNSKEY, or if the digest does not match, stop making repeated changes. Capture the timestamps and exact responses, then ask the registrar or DNS provider to review the chain. A local dashboard value is not authoritative until the registry and validating resolvers agree.
DNSSEC and email
DNSSEC does not replace SPF, DKIM or DMARC. Those controls address email authentication and policy, while DNSSEC authenticates DNS responses. A DNSSEC failure can still make mail records unreachable, so test MX and TXT answers after a change. Conversely, valid DNSSEC does not prove that a mailbox is protected from spoofing.
Operational checklist for an Irish business
- Record the DNS provider and registrar separately.
- Record who is allowed to change DS, nameservers and DNS records.
- Keep a zone export and a dated change plan.
- Use provider-supported key rollover, not manual guesses.
- Verify parent DS, authoritative data and validating resolver answers.
- Monitor website, API, payment, verification and mail records after the change.
- Keep a manual-review path for uncertain registry operations.
For a domain managed through Hoster, use the domain dashboard to review the registrar state. If a DNSSEC status is inconsistent or a change is rejected, contact support with the domain and the intended DNS provider rather than repeatedly submitting the same request.