DNSSEC Setup Guide for DNScale — Step-by-Step Walkthrough

This guide walks through enabling DNSSEC on a DNScale zone, publishing the DS record at your registrar, verifying the chain of trust, and handling the most common failure modes. If you want the conceptual background first, read What is DNSSEC? and How DNSSEC Works.

Before You Begin

Confirm three things:

1. Your zone is delegated to DNScale. The NS records at your registrar point to DNScale nameservers, and dig NS yourdomain @1.1.1.1 returns the DNScale set. If you haven't migrated yet, complete that first — see DNS Delegation for DNScale Regions.
2. Your TLD supports DNSSEC. All gTLDs (.com, .net, .org, etc.) and most ccTLDs (.de, .fr, .nl, .eu, .uk) have supported DNSSEC for years. A handful of older or smaller TLDs do not — check the IANA TLD report if unsure.
3. Your registrar supports DS publication. Most major registrars do. If yours doesn't, you'll need to either transfer the domain to a DNSSEC-capable registrar or accept that DNSSEC isn't available for that domain.

Step 1 — Enable DNSSEC in DNScale

From the Dashboard

1. Open your zone in the DNScale dashboard.
2. Click the Security tab (or DNSSEC depending on the dashboard version).
3. Click Enable DNSSEC. DNScale generates a new CSK using ECDSA P-256 and begins signing the zone. This takes a few seconds.
4. The dashboard displays the DS record to publish at your registrar:

example.com.   86400   IN   DS   12345 13 2 7c89aa1f3e7b4d8b...

Note the four fields: Key Tag (12345), Algorithm (13 = ECDSA P-256), Digest Type (2 = SHA-256), Digest (the hex string). Different registrar UIs ask for these in different combinations — most ask for all four; some ask for the full record string; a few computed the digest themselves and ask only for the DNSKEY public key.

Using the DNScale API

curl -X POST "https://api.dnscale.eu/v1/zones/{zone_id}/dnssec/enable" \
  -H "Authorization: Bearer YOUR_API_KEY" \
  -H "Content-Type: application/json"

The response includes the DS record fields you'll need at the registrar:

{
  "enabled": true,
  "ds_records": [
    {
      "key_tag": 12345,
      "algorithm": 13,
      "digest_type": 2,
      "digest": "7c89aa1f3e7b4d8b..."
    }
  ]
}

Using Terraform

resource "dnscale_zone_dnssec" "example" {
  zone_id   = dnscale_zone.example.id
  enabled   = true
}

After terraform apply, the resource exposes the DS record fields as outputs you can pipe into a registrar provider (if your registrar is also Terraform-managed) or capture for manual entry.

Using DNSControl

D("example.com", DNSCALE,
  AUTODNSSEC_ON,
  // ... your records
);

DNSControl's AUTODNSSEC_ON directive triggers the DNScale provider to enable signing. The DS record becomes available in dnscontrol get-zones output.

Step 2 — Publish the DS Record at Your Registrar

This is the only manual step that the DNS provider can't do for you (yet — see CDS/CDNSKEY automation below). The exact UI varies by registrar; here are the most common ones.

Generic Pattern

Most registrar dashboards have a DNSSEC or Advanced DNS section per domain. You'll typically:

1. Click Add DS Record.
2. Enter the four fields: Key Tag, Algorithm, Digest Type, Digest.
3. Save.

Some registrars ask for the full DS record string (e.g., 12345 13 2 7c89aa1f...) — paste the whole line. Others let you paste the DNSKEY public key and compute the DS themselves — both work; use whichever the registrar prefers.

Cloudflare Registrar

Domain → DNS → DNSSEC → Enable → Add DS Record. Paste the four fields. Cloudflare publishes the DS to the TLD within minutes.

Gandi

Domains → your domain → DNSSEC → Add a key. Paste fields; Gandi publishes typically within 30 minutes.

Namecheap

Domain List → Manage → Advanced DNS → DNSSEC → Add Key. Paste fields and save.

OVH

Domain → DNSSEC → Add → Active DNSSEC. Paste fields. OVH propagates within 30 minutes for most TLDs.

IONOS / 1&1

Domain → SSL & DNSSEC → DNSSEC → Activate → Add a record. Paste fields. IONOS publishes typically within an hour.

GoDaddy

Domain → DNS → DNSSEC. Add Key. Paste fields. Publication time varies; allow 24–48 hours.

Domain at a registry-only registrar

Some country-code registries (e.g., DK Hostmaster, .ee Internet Foundation) accept DS records directly via web interface or EPP. The registrar would normally pass them through — if not, contact the registry support.

Step 3 — Verify the Chain End-to-End

Once you've published the DS, verify the chain works at every link. The most reliable single command:

dig +dnssec example.com @1.1.1.1

Look for two things in the response:

1. The AD flag in the header — ;; flags: qr rd ra ad; — confirms the resolver successfully validated the chain.
2. RRSIG records in the answer section, paired with each data record.

If the AD flag is missing but RRSIG records are present, the resolver isn't validating (try 8.8.8.8 or 9.9.9.9). If RRSIG records are missing, signing didn't take effect — re-check Step 1.

Verify the DS at the parent zone

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

For .com, query the gTLD servers directly. For other TLDs, find the parent's NS via dig NS .com @a.root-servers.net. or use dig +trace. The expected answer is your DS record, exactly as you submitted it.

If the DS doesn't appear at the parent within 48 hours, contact your registrar — the publication step likely failed.

Use a visualiser

For a complete picture, the DNSViz visualiser draws the entire chain from root to your zone and highlights any breakages. The Verisign DNSSEC Debugger does the same with a different presentation.

Step 4 — Test from Multiple Resolvers

Different resolvers cache differently and roll out updates at different rates. After the initial verification, query from at least three:

dig +dnssec example.com @1.1.1.1     # Cloudflare
dig +dnssec example.com @8.8.8.8     # Google
dig +dnssec example.com @9.9.9.9     # Quad9

If all three show the AD flag, your DNSSEC deployment is reaching the public resolver fleet.

Common Failure Modes and How to Recover

DS at registrar doesn't match the DNSKEY

Symptom: dig +dnssec yourdomain returns SERVFAIL. DNSViz shows a red link between the parent's DS and your DNSKEY.

Cause: Wrong digest, wrong algorithm, or wrong key tag entered at the registrar.

Fix: Re-fetch the correct DS from the DNScale dashboard. Update at the registrar. Wait for TLD propagation. If the registrar UI doesn't accept your edit, remove the bad DS first and re-add.

Multiple stale DS records at the registrar

Symptom: Validation works intermittently — some resolvers AD-flag the answer, others SERVFAIL.

Cause: A previous DNSSEC enablement left old DS records that no longer match any current DNSKEY.

Fix: At the registrar, remove every DS that doesn't appear in the current DNScale DS record list. Keep only the DS for the currently-active KSK.

TLD doesn't accept the DS

Symptom: Registrar UI rejects the DS or shows it as "pending" indefinitely.

Cause: The TLD doesn't yet support DNSSEC (very rare in 2026), or there's a registry-side delay.

Fix: Check the IANA TLD report for DNSSEC support status. If unsupported, you can't enable DNSSEC for that domain; consider transferring to a TLD that supports it. If supported but stuck, contact registrar support.

Signing was disabled before the DS was removed

Symptom: Domain returns SERVFAIL from validating resolvers; non-validating resolvers still resolve fine.

Cause: The order of operations was wrong — the DS record at the parent now points to a key that no longer exists in your zone.

Fix: Either re-enable DNSSEC in DNScale (which restores signing with the same key tags if possible), or remove the DS at the registrar. The right ordering for permanent disable is: remove DS → wait 48h → disable signing.

Pre-cached negative answers persist

Symptom: After fixing a DNSSEC misconfiguration, some users still see SERVFAIL for some time.

Cause: Validating resolvers cache validation failures (typically up to 5 minutes). Public resolvers running RFC 8767 stale-data serving may keep stale failures longer.

Fix: Wait. The cached failures expire; nothing on your side changes the timing. Verifying from a fresh recursive resolver (dig +dnssec yourdomain @1.0.0.1 instead of @1.1.1.1) confirms whether the underlying state is now good.

Optional: Automate the DS via CDS/CDNSKEY

RFC 7344 and RFC 8078 define CDS and CDNSKEY records — child-side records that tell the parent which DS records to publish. A registrar that supports CDS/CDNSKEY scanning can pick up DS changes automatically without manual entry.

Support is uneven:

• ✅ Cloudflare Registrar — full CDS automation
• ✅ Gandi — supports CDS for some TLDs
• ⚠️ Most others — manual DS management still
• ❌ A few legacy registrars — no DNSSEC support at all

DNScale publishes CDS and CDNSKEY records automatically when DNSSEC is enabled. If your registrar supports CDS scanning, no manual DS entry is needed — DS rotations during key rollover happen without your involvement.

What Happens Next — Automatic Operations

Once DNSSEC is enabled on a DNScale zone:

• Signatures refresh continuously. RRSIG records are re-signed before expiration; resolvers see fresh signatures on every query.
• Key rotation happens on schedule. ZSK rotates more often (when separate from KSK); KSK rotates rarely (every several years). With CSK (the default), rotations involve the registrar — DNScale notifies you when registrar action is needed.
• Algorithm upgrades are coordinated rolls. If the industry shifts (e.g., to Ed25519), DNScale runs an algorithm rollover without zone-data downtime.
• DS-record updates during rotation: with CDS automation, the parent's DS updates without your involvement; without it, DNScale notifies you that a new DS needs publishing.

You shouldn't need to think about DNSSEC again after the initial setup — until you decide to migrate or the registrar UX changes.

References

• RFC 4033/4034/4035 — DNSSEC core specification
• RFC 7344 — Automating DNSSEC delegation trust maintenance (CDS/CDNSKEY)
• RFC 8078 — Managing DS records from the parent via CDS/CDNSKEY
• RFC 8901 — Multi-signer DNSSEC models (for multi-provider deployments)
• IANA Root Trust Anchors
• DNSViz visualiser
• Verisign DNSSEC debugger

Related Reading

• What is DNSSEC? — top-of-funnel introduction
• How DNSSEC Works — KSK/ZSK/DS/DNSKEY mechanics
• DNSSEC Key Management — operational rollover procedures
• Multi-Provider DNS Deployment — adding a second DNS provider safely with DNSSEC
• DNS Delegation for DNScale Regions — how to point your zone at DNScale before enabling DNSSEC
• DNS Cache Poisoning — the attack DNSSEC defeats
• NIS2 and DNS Compliance — DNSSEC as a regulatory control