DNSSEC setup and migration

DNSSEC lets validating resolvers check that DNS answers belong to the signed zone. Enabling signing at a DNS provider is only half of the setup. The parent zone must also publish the matching DS record to create a chain of trust.

Enable DNSSEC

You need edit permission for the zone.

  1. Open the zone and select the DNSSEC tab.
  2. Enable DNSSEC and choose Save.
  3. Wait for the tab to display a DS record. The signing keys and signed DNSKEY/CDNSKEY/CDS records are generated and served by the DNS servers and are read-only in the interface.

If the DS record is temporarily unavailable, do not invent one or copy one from another zone. Leave signing enabled and retry later. Contact support@echo-reply.net if it persists.

Complete the chain of trust

What happens next depends on who manages the registration:

  • Domain registered through echo reply: the platform sends the DS change to the configured registrar. The DNSSEC tab distinguishes a pending request, a confirmed submission, and a registrar error. Wait for the registrar state and verify the public parent response.
  • Domain registered elsewhere: copy the complete DS record from the DNSSEC tab and lodge it with the current registrar. Field names vary by registrar. The displayed record contains the key tag, algorithm, digest type and digest.

Verify what the parent publishes and then test validation:

dig DS example.dk +short
dig example.dk SOA +dnssec

The DS answer must match the value shown in the DNSSEC tab. A signed response alone does not prove a complete chain of trust. Use a validating resolver or a DNSSEC diagnostic tool as an additional check.

Disable DNSSEC safely

Removing signatures while the parent still publishes a DS record causes validating resolvers to reject the zone.

  • For a domain registered through echo reply, turn DNSSEC off in the tab and wait while the platform asks the registrar to remove the DS record. Treat the withdrawal warning as unresolved until the parent no longer returns the DS.
  • For a domain registered elsewhere, remove the DS at that registrar first. Wait until the parent no longer publishes it, then turn DNSSEC off in echo reply.

Check before and after the change:

dig DS example.dk +short

Moving a signed zone

echo reply does not document a coordinated multi-signer migration in the current customer interface. Use this conservative sequence when the old and new providers use different signing keys:

  1. Keep the old signed zone and delegation active.
  2. Remove the old DS record at the registrar.
  3. Wait until the parent no longer returns that DS and allow previously cached DS data to expire.
  4. Create and verify the new zone, then change its nameserver delegation.
  5. Wait for the new delegation to stabilise.
  6. Enable DNSSEC in echo reply and publish the new DS as described above.
  7. Confirm the new DS and validation path before retiring the old service.

This creates a deliberate unsigned interval, but avoids a bogus chain caused by an old DS pointing at a new signer. If your policy does not permit an unsigned interval, plan a coordinated migration with both providers and support before changing anything.

Recovery

If validating resolvers return SERVFAIL, compare the DS published by the parent with the DS shown in the active provider. Do not repeatedly toggle signing. Restore consistency in one direction:

  • publish the DS that matches the currently delegated signer, or
  • remove the mismatched DS and wait for caches to expire.

Keep the zone and keys in place while diagnosing. If you also need to revert nameservers, use the rollback steps in the migration guide.