Enable or migrate DNSSEC safely

DNSSEC enablement joins two control planes: the child zone publishes DNSKEY and signatures, while the parent publishes DS through a registrar or registry workflow. A signed child without DS remains insecure; an incorrect parent DS can cause validating resolvers to reject otherwise reachable data as bogus.

DNSSEC authenticates DNS data. It does not encrypt ordinary DNS queries, secure the registrar account, or prove that a website or mail service is trustworthy [1].

Blast radius and owners

Control or service	Responsible owner
Zone signing, DNSKEY, RRSIG, and denial records	Authoritative DNS or signing owner
Parent DS submission and removal	Registrant or authorized registrar owner
Registry publication and parent response	Registry through the registrar
Key generation, custody, rollover, and recovery	DNSSEC key owner
Resolver validation evidence	DNS operations verifier
Web, email, APIs, and delegated subzones	Respective application owners
Window, stop decision, rollback, communication	Change owner and independent verifier

Prerequisites

a stable, correct authoritative zone with every server in agreement;
authorized access and tested recovery for DNS and registrar accounts;
provider documentation for enabling, disabling, rollover, and emergency recovery;
a named owner for child signing and a separate owner for parent DS;
confirmed algorithm, key tag, digest type, digest, and key-custody model;
baseline parent DS, child DNSKEY, RRSIG, and validation evidence;
exact TTLs and an observation window that covers cached parent data;
monitoring from at least one validating and one diagnostic path;
an application-health baseline; and
a reviewed rollback path that does not toggle parent and child blindly.

Inventory and export

Capture:

domain, parent zone, registrar, registry, and authoritative provider;
parent NS and DS RRsets with TTLs from authoritative observations;
child SOA, NS, DNSKEY, RRSIG, NSEC or NSEC3, and their TTLs;
DNSKEY flags, protocol, algorithm, public key, key tag, and intended role;
DS key tag, algorithm, digest type, and digest exactly as supplied;
signature inception, expiration, refresh, and monitoring thresholds;
whether signing is provider-managed, external, multi-signer, or manual;
every delegated child zone and whether it has an independent DS chain;
current result from named validating resolvers;
web, email, API, and certificate baseline; and
provider-specific disablement order and emergency contacts.

RFC 4034 defines the DNSKEY, DS, RRSIG, NSEC, and related record formats [2]. Record every DS field; a matching-looking digest fragment is not sufficient evidence.

Use the DNS Lookup pathway for named resolver observations of DS and DNSKEY. Use the Domain Registration Lookup pathway to capture available registrar and nameserver context. Neither pathway replaces direct queries to the parent and every child authority.

Preflight

For first enablement:

Enable signing at the child without publishing DS.
Confirm every intended authority serves the same DNSKEY set and valid signatures for positive and negative answers.
Independently derive or compare the provider-supplied DS.
Confirm the registrar accepts the exact algorithm and digest type.
Test the emergency DS-removal path and responsible contacts.
Verify the signed-but-insecure zone still resolves through validating resolvers.

For migration, choose one reviewed strategy:

Maintain a secure chain: use a supported pre-publication, double-DS, double-DNSKEY, or multi-signer sequence with explicit timing; or
Use an intentional insecure interval: remove the old DS, wait for its cached lifetime and safety margin, verify no parent DS remains, migrate authority or keys, then establish the new chain.

RFC 6781 describes operational timing, key rollover, parental interaction, and the need to preserve a valid chain throughout a secure transition [4]. Do not infer that two providers support a multi-signer plan unless both explicitly document it.

Stop conditions

Stop before parent DS publication when:

intended authorities disagree on DNSKEY, signatures, or denial proofs;
any required RRset is unsigned or signatures are expired or not yet valid;
the DS fields lack an independent exact comparison;
registrar support for the algorithm or digest type is unclear;
parent submission, observation, or emergency removal cannot be tested;
the signer or key-custody owner is unavailable;
a nameserver migration or unrelated key rollover is in progress;
cached old DS timing is unknown;
delegated subzone ownership is confused with the apex chain; or
validating-resolver and application baselines are unavailable.

During execution, stop additional changes after any unexpected SERVFAIL, bogus result, missing signature, or parent-child mismatch.

Ordered steps

First enablement

Approve owners, DS fields, observations, window, and emergency path.
Enable child signing and leave the parent unsigned.
Verify DNSKEY, RRSIG, positive answers, and authenticated denial from every authority.
Verify the provider’s reported DS against the intended DNSKEY.
Submit the exact DS once through the authorized parent workflow.
Confirm the parent authorities publish that DS.
Query named validating resolvers and verify the chain becomes secure.
Monitor signatures, validation, and applications through the DS TTL and operational observation window.

Migration

Document whether the transition stays secure or intentionally becomes insecure.
Execute the provider-supported key or multi-signer sequence exactly, with old and new material overlapping for the reviewed TTLs; or remove the old DS and wait before introducing unrelated child keys.
Change one control plane at a time and verify after each state.
Publish the new DS only after the intended child DNSKEY and signatures are stable at every authority.
Retire old keys or signer state only after caches and validators can no longer require them.

RFC 4035 specifies how resolvers use DS, DNSKEY, signatures, and authenticated denial during validation [3].

Verification

Verify and timestamp:

parent authorities return the intended DS or intentional absence;
every child authority returns the intended DNSKEY set;
representative positive RRsets have valid, current RRSIG records;
negative answers carry the intended authenticated denial records;
DS fields match the intended DNSKEY;
named validating resolvers report secure, insecure, or bogus exactly as the planned state requires;
named non-validating diagnostics distinguish reachability from validation;
signature inception and expiry leave the provider’s intended safety margin;
web, email, APIs, certificates, and delegated subzones remain healthy; and
monitoring can alert before signature expiry or a chain mismatch.

Record the resolver, query, flags, answer, EDE when available, TTL, and time. One resolver result does not prove all cached validators have the same parent state.

Rollback

Use the rollback for the current state, not a generic “disable DNSSEC” switch.

Before DS publication: leave the parent insecure. Correct child signing or disable it according to provider procedure; no validating chain exists yet.
After a wrong new DS: use the reviewed emergency parent process to remove or replace the incorrect DS. Keep the child zone and relevant keys stable while cached DS records expire.
During secure rollover: restore or retain the last key and signature set that matches still-cached parent data. Do not remove old material early.
During an insecure migration: preserve the intentional absence of DS until the new child is stable; do not rush to republish trust.
Verify parent, every authority, named validators, and applications after each recovery state.

Removing DS does not instantly clear recursive caches. Disabling child signing while an old DS is cached can extend the validating failure.

Next step

Keep signature and chain monitoring active after the change. If validators return SERVFAIL or report bogus data, use Diagnose DNSSEC bogus after a change before altering more state.