DNSSEC has always had an operational Achilles' heel: the parent-child key handoff. When you sign your zone, you generate a Key Signing Key (KSK), and a hash of that key — the DS (Delegation Signer) record — must live in your parent zone. Without a matching DS record at the parent, resolvers have no anchor to validate your signatures, and DNSSEC does nothing. Worse, when you rotate your KSK, you need to coordinate a new DS with your registrar, usually through a web form, an EPP transaction, or (historically) an email to a support desk. This friction is a major reason DNSSEC adoption stalled for a decade.

RFC 7344 introduced the idea of publishing CDS ("Child DS") and CDNSKEY ("Child DNSKEY") records inside the child zone itself, signaling to the parent: "here is what my DS record should look like." But RFC 7344 deliberately punted on the hardest question: how does the parent bootstrap trust the very first time, before any DS exists to validate the child's signatures?

RFC 8078 is the answer. It defines two things:

• Bootstrapping: how a parent can accept the initial DS for a previously insecure delegation.
• Deletion: how a child signals "please remove my DS entirely and return me to insecure state" — done by publishing a special CDS 0 0 0 00 record (all zeros).

The bootstrapping problem is genuinely hard. If the child publishes a CDNSKEY record and the parent just trusts it, an attacker who briefly hijacks the child's DNS can lock in their own key. RFC 8078 sidesteps this with a menu of "acceptance policies" the parent operator can choose from:

• Accept after a stability period: query the CDS/CDNSKEY from multiple vantage points over hours or days; only accept if it's consistent.
• Accept with out-of-band confirmation: registrar sends an email or requires a manual click.
• Accept if seen from a trusted network path (e.g., the registrar's own resolvers plus a couple of external ones).
• Accept only if the CDNSKEY is signed by an existing key — trivially not applicable to bootstrap, but useful for rollovers.

The deletion mechanism is elegant. Rather than invent a new signaling record, the RFC overloads CDS with a sentinel: a single record with algorithm 0 and digest type 0 and a digest of a single zero octet means "delete my DS." This lets a zone gracefully return to unsigned state — critical if you're migrating DNS providers and the new one doesn't support DNSSEC yet.

Why does this matter in 2026? Because it's the machinery that made DNSSEC actually usable. Cloudflare, Google Domains (now Squarespace), Gandi, and most modern registrars scan for CDS/CDNSKEY records and automatically publish DS records to the parent — often within minutes. If you use a modern DNS host with a modern registrar, you can enable DNSSEC with a single checkbox, and KSK rollovers happen without you noticing. That entire seamless experience is RFC 8078 in action.

There's also a quiet policy shift here: DNS operators are finally allowed to fully own their DNSSEC lifecycle, without begging the registrar to move at machine speed. Combine this with automated KSK rollover algorithms (RFC 7583) and you get a DNSSEC that resembles Let's Encrypt: signed by default, rotated silently, no human in the loop.