Edge & DNS Ops Guide

Submitting DS Records to Your Registrar

Signing your zone is only half of enabling DNSSEC. Until a Delegation Signer (DS) record exists in the parent zone, validating resolvers have no cryptographic anchor that ties your child zone’s keys to the global chain of trust, and they will treat your zone as unsigned. This guide walks you through obtaining the DS from your DNS provider, entering it at your registrar (dashboard, API, or EPP), and proving that the parent now publishes the DS and that resolvers return the Authenticated Data (AD) flag.

By the end you will be able to:

  • Locate the correct DS record (key tag, algorithm, digest type, digest) from Cloudflare or Route 53.
  • Submit that DS to your registrar without transcription errors that break the chain.
  • Confirm with dig and delv that the parent delegation is signed and validation succeeds end to end.
  • Recognise and recover from the failure modes that silently break resolution for everyone using a validating resolver.
DS record linkage between parent and child zones The registrar publishes a DS record in the parent zone; the DS is a digest of the child zone's KSK DNSKEY, completing the chain of trust. Registrar submits DS via EPP to TLD registry Parent zone (.com) DS record keytag + digest Child zone DNSKEY (KSK) signs zone DS = hash( KSK DNSKEY ) SHA-256 digest (type 2) of the public KSK Resolver validates: parent DS matches child DNSKEY → AD flag set Break any link and the resolver returns SERVFAIL

Prerequisites and environment

Before you publish a DS, your zone must already be signed and serving DNSKEY/RRSIG records. If you have not done that yet, start at DNSSEC Operational Management and confirm the zone validates internally. Submitting a DS for an unsigned or half-signed zone is the most common way to take a domain offline.

You will need:

  • Admin access to the DNS provider hosting the zone (Cloudflare dashboard or AWS Route 53 console/CLI).
  • Registrar access with permission to edit DNSSEC settings for the domain. This is a registrar function, not a DNS-hosting function — they are often two different companies.
  • dig (BIND dnsutils package) version 9.16 or later, and delv from the same package for chain validation.
  • Optionally the registrar’s API credentials if you automate submission instead of using the dashboard.
dig -v          # expect: DiG 9.18.x or similar
delv -v         # expect: delv 9.18.x

A DS record has exactly four fields, and the registrar form will ask for all four. Get the vocabulary straight before you touch anything:

Field Meaning Typical value
Key Tag 16-bit fingerprint identifying which DNSKEY e.g. 2371
Algorithm DNSSEC signing algorithm number 13 (ECDSAP256SHA256), 8 (RSASHA256)
Digest Type Hash used to digest the DNSKEY 2 (SHA-256) — preferred
Digest Hex hash of the KSK public key 64 hex chars for SHA-256

Always use digest type 2 (SHA-256). SHA-1 (type 1) is deprecated and some registries reject it. The algorithm number must match the algorithm of the Key Signing Key (KSK) that produced the digest — a frequent mismatch when a zone has been re-signed during a key rollover.

Step 1: Obtain the DS from your DNS provider

The DS is a digest of your KSK’s DNSKEY. Your DNS provider computes it for you; you should not be hashing keys by hand.

Cloudflare

In the Cloudflare dashboard go to your domain, then DNS → Settings → DNSSEC and click Enable DNSSEC. Cloudflare presents a panel with the DS record broken into its fields plus a ready-to-paste single-line form:

DS Record:  example.com. 3600 IN DS 2371 13 2 F1E2...A9C0
Key Tag:    2371
Algorithm:  13
Digest Type: 2
Digest:     F1E2D3C4B5A6978...A9C0
DNSKEY:     257 3 13 mdsswUyr...

Copy these exactly. Cloudflare also exposes them via API, which is the reliable path when automating:

curl -s -X GET \
  "https://api.cloudflare.com/client/v4/zones/$ZONE_ID/dnssec" \
  -H "Authorization: Bearer $CF_API_TOKEN" \
  -H "Content-Type: application/json" | jq '.result | {key_tag, algorithm, digest_type, digest, ds}'

Expected output is a JSON object whose ds field is the full record string. If status is pending, Cloudflare has generated the keys but is waiting for the DS to appear in the parent — that is the state you are about to resolve.

Route 53

Route 53 separates key management from zones. First enable signing on the hosted zone, then read the KSK:

aws route53 get-dnssec --hosted-zone-id Z123EXAMPLE \
  --query 'KeySigningKeys[].{Name:Name,DS:DSRecord,KeyTag:KeyTag,Status:Status}'

The DSRecord field is the full keytag algorithm digesttype digest string ready for the registrar. Confirm Status is ACTIVE before you submit — submitting a DS for an INACTIVE KSK breaks validation immediately.

Step 2: Enter the DS at your registrar

Find which company is your registrar with a WHOIS lookup if you are unsure, then locate the DNSSEC section (often under Domain → Security or Advanced DNS).

Via the registrar dashboard

Most registrars present one of two forms:

  1. Four-field form — paste Key Tag, Algorithm, Digest Type, and Digest into separate boxes. This is the safest; there is no ambiguity.
  2. DNSKEY form — some registrars (notably a few that use the older model) ask for the DNSKEY (257 3 13 ...) and compute the DS themselves at the registry. Paste the DNSKEY Cloudflare or Route 53 showed you; do not paste the DS into a DNSKEY field.

Submit only one DS per active KSK. Do not add stale DS records from previous keys unless you are deliberately running a double-DS rollover.

Via registrar API or EPP

Registrars that expose an API let you script this. The underlying registry protocol is EPP, and the DS maps to the secDNS:dsData element:

<secDNS:create xmlns:secDNS="urn:ietf:params:xml:ns:secDNS-1.1">
  <secDNS:dsData>
    <secDNS:keyTag>2371</secDNS:keyTag>
    <secDNS:alg>13</secDNS:alg>
    <secDNS:digestType>2</secDNS:digestType>
    <secDNS:digest>F1E2D3C4B5A6978...A9C0</secDNS:digest>
  </secDNS:dsData>
</secDNS:create>

Most users never write raw EPP; the registrar’s REST API wraps it. A typical request body looks like:

{
  "domain": "example.com",
  "ds_records": [
    { "keyTag": 2371, "algorithm": 13, "digestType": 2, "digest": "F1E2D3C4B5A6978...A9C0" }
  ]
}

The side effect: the registrar forwards the DS to the TLD registry, which publishes it in the parent zone. This is the moment the chain of trust closes.

Step 3: Confirm publication

Registry publication is not instant. TLD zones regenerate on a schedule — often every few minutes for large gTLDs like .com, but up to an hour for some ccTLDs. Query the parent directly rather than your own zone.

dig DS example.com +short @8.8.8.8

Expected once published:

2371 13 2 F1E2D3C4B5A6978...A9C0

To be certain you are reading the parent and not a cached child answer, query a TLD nameserver directly:

dig DS example.com @a.gtld-servers.net +norecurse

The ANSWER SECTION (or AUTHORITY referral with the DS) confirms the registry has the record. An empty answer means the registry has not picked it up yet — wait and retry.

Verification

Publication is necessary but not sufficient. You want proof that a validating resolver follows the chain from the root through the TLD DS into your DNSKEY and sets the AD flag.

Check the AD flag

dig +dnssec +cd=no A example.com @1.1.1.1 | grep -E 'flags|status'

Expected:

;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 41023
;; flags: qr rd ra ad; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1

The ad token in flags is the goal: the resolver validated the signatures. If you see status: SERVFAIL, validation failed — go to troubleshooting before announcing the change.

Full chain check with delv

delv performs its own validation independent of any resolver and prints each link:

delv +rtrace A example.com @1.1.1.1

Expected tail:

; fully validated
example.com.  300  IN  A  203.0.113.10
example.com.  300  IN  RRSIG  A 13 2 300 ...

The line ; fully validated means root → TLD DS → child DNSKEY → RRSIG all matched. If delv reports ; resolution failed: SERVFAIL or ; no valid RRSIG, the DS does not match the live KSK.

Troubleshooting

Wrong digest type submitted

Symptom: the parent shows a DS with digest type 1, validation fails or your registry rejected it. Confirm the type in the parent answer:

dig DS example.com +short @8.8.8.8
# 2371 13 1 ABCD...   <-- type 1, not what you want

Fix: delete the type-1 DS at the registrar and submit the type-2 (SHA-256) DS your provider generated. Never mix a type-1 and type-2 DS for the same key unless both digests are genuinely correct for that key.

Key tag mismatch

Symptom: delv reports no valid RRSIG or broken trust chain. The DS key tag does not correspond to any DNSKEY currently in the zone — usually because the zone was re-signed (new KSK) but the old DS is still at the registrar. Compare:

dig DS example.com +short @8.8.8.8           # key tag at parent
dig DNSKEY example.com +short | grep '257 '  # KSK in child zone

Compute the expected DS from the live DNSKEY and compare key tags:

dig DNSKEY example.com | dnssec-dsfromkey -2 -f - example.com

Fix: submit the DS whose key tag matches the active KSK. If you are mid-rollover, publish both DS records during the overlap window as described in Automating DNSSEC Key Rollover.

Registrar propagation delay

Symptom: you submitted the DS but dig DS against the TLD returns nothing after several minutes. Distinguish “registrar accepted but registry pending” from “registrar never forwarded it.” Check the registrar’s DNSSEC panel — if it shows the DS but the TLD does not, wait one regeneration cycle. If the panel is empty, the submission failed validation at the registrar; resubmit and watch for an error message about field length or hex format.

SERVFAIL everywhere after submission

Symptom: every validating resolver returns SERVFAIL while non-validating resolvers (dig +cd) still answer. This is the catastrophic case: the published DS does not match the zone’s keys. Confirm with:

dig +cd A example.com @1.1.1.1   # answers => zone fine, DS is the problem
delv A example.com @1.1.1.1      # SERVFAIL => chain broken

Fix fast: either correct the DS at the registrar to match the live KSK, or, if you cannot, remove the DS entirely to fall back to unsigned. See Debugging DNSSEC Validation Failures for a structured triage path.

Removing DS before disabling signing

Order matters when you decommission DNSSEC. Always remove the DS at the registrar first, wait for the parent TTL plus a margin (the DS TTL is often 3600s), and only then disable signing at your DNS provider. Reversing the order leaves a DS in the parent pointing at keys that no longer exist, producing SERVFAIL until the DS expires from caches.

dig DS example.com +short @8.8.8.8     # must return empty before disabling signing

Frequently Asked Questions

Where does the DS record actually come from? It is a cryptographic digest (SHA-256) of your zone’s Key Signing Key DNSKEY. Your DNS provider computes it; you copy its four fields to the registrar, who publishes it in the parent zone.

Why does my zone still show as unsigned after I enabled DNSSEC? Enabling signing at the DNS provider only creates DNSKEY and RRSIG records in your zone. Until the DS exists in the parent (via the registrar), validating resolvers have no anchor and treat the zone as unsigned.

Should I use digest type 1 or 2? Always type 2 (SHA-256). Type 1 (SHA-1) is deprecated and some registries refuse it. Submit a single type-2 DS per active KSK.

How long until the DS takes effect? The registrar forwards it to the TLD registry, which republishes the parent zone on its own schedule — minutes for .com, sometimes up to an hour for ccTLDs. Resolvers then pick it up as caches expire, bounded by the DS TTL.

What happens if the key tag is wrong? Validating resolvers cannot match the DS to any live DNSKEY and return SERVFAIL for everyone using them. Resubmit the DS whose key tag matches the active KSK, or remove the DS to fall back to unsigned.

How do I safely turn DNSSEC off? Remove the DS at the registrar first, wait for the DS TTL to expire from caches, then disable signing at the DNS provider. Never disable signing while a DS still points at your zone.

Back to DNSSEC Operational Management