DNSSEC on DNSCove

DNSSEC signs every answer your nameservers give, so a resolver can prove the answer really came from you and was not altered on the way. On DNSCove it is per zone, one click, and free on every plan — we do not paywall a security primitive.

This guide covers what turning it on actually does, how to finish the handoff at your registrar, and — the part most providers gloss over — how to turn it off without breaking your domain.

What DNSSEC does, in one paragraph

Ordinary DNS answers are unauthenticated. A resolver that asks "what is the A record for example.com?" has no way to tell our answer from an attacker's forged one, which is the basis of cache-poisoning attacks. With DNSSEC, we sign each record set with a private key, publish the matching public key in your zone, and you publish a small fingerprint of that key — a DS record — at your registrar. A validating resolver walks that chain from the root down to your zone. If any link fails, it refuses the answer rather than serving a forgery.

That last sentence is also the risk. A validating resolver that cannot verify your zone does not fall back to trusting it — it returns SERVFAIL, which looks like your domain being offline. Everything below exists to keep you out of that state.

What DNSCove does for you

You do not manage keys, choose algorithms, schedule rollovers, or re-sign after editing a record. Editing a zone re-signs it automatically.

Turning it on

Prerequisite: the zone must be ACTIVE — that is, already being served from ns1.dnscove.com and ns2.dnscove.org. DNSSEC signs what the edge serves, so there has to be something to sign.

1. Enable it in the console

Open the zone, find the DNSSEC panel, and click Turn on DNSSEC.

Or via the API:

curl -fsS -X POST "$DNSCOVE/api/zones/$ZONE_ID/dnssec" -H "$auth"

We immediately generate a key-signing key and a zone-signing key for that zone and start publishing signatures.

Nothing about your domain changes at this point. Resolvers only check signatures once a DS record exists at your registrar, and there isn't one yet. A validating resolver that finds no DS treats your zone exactly as it did yesterday. The zone now sits in PENDING_DS, which is a normal, safe state that can last as long as you need it to.

2. Publish the DS record at your registrar

The console shows the DS record in three forms, because registrars ask for it differently:

• Separate fields — key tag, algorithm, digest type, digest. Most registrars.
• One line — the full record, for registrars with a single text box.
• DNSKEY — a minority of registrars take the key itself rather than its digest.

curl -fsS "$DNSCOVE/api/zones/$ZONE_ID/dnssec" -H "$auth" | jq '.ds[0]'

{
  "key_tag": 34505,
  "algorithm": 13,
  "digest_type": 2,
  "digest": "8A1F…",
  "record": "example.com. 3600 IN DS 34505 13 2 8A1F…",
  "dnskey": "example.com. 3600 IN DNSKEY 257 3 13 MFkw…"
}

Find "DNSSEC" or "DS records" in your registrar's control panel and add it.

Your registrar may do this for you. We publish CDS and CDNSKEY records alongside the DS. Registrars that scan for those — an increasing number do — will pick up the key and publish the DS on their own within a day or so. Check the console before pasting anything: if it already says Protected, you are done.

3. Confirm

The console re-checks your registrar each time you open the zone and flips the badge to Protected once it sees a DS matching our key. Registrar changes usually appear within minutes, occasionally up to a day.

To verify independently:

# The DS at your parent zone
dig +short DS example.com @8.8.8.8

# A full validation walk — "fully validated" is what you want
delv example.com A

Turning it off — read this first

The order matters, and getting it wrong takes your domain down.

If we stop signing while your registrar still publishes a DS, every validating resolver on the internet will find a DS pointing at a key your zone no longer carries, conclude the answers are forged, and SERVFAIL your domain. Recovery is not something we can deploy our way out of — it waits on your registrar's DS TTL and on resolver caches worldwide.

The correct order:

1. Delete the DS record at your registrar.
2. Wait for it to clear caches — usually a few hours, sometimes a full day. dig +short DS example.com @8.8.8.8 should return nothing.
3. Then turn DNSSEC off in the console.

DNSCove enforces this rather than merely documenting it. We query your parent zone's authoritative nameservers directly when you ask to disable, and refuse the request while a matching DS is still there:

409 DSStillPublished
your registrar still publishes a DS record for this domain. Remove it there
first, wait for it to expire from caches, then disable DNSSEC here.

If we cannot reach your parent's nameservers to check, we also refuse. An unreachable registrar is not evidence the DS is gone, and we will not guess in the direction that breaks your domain.

Things people ask

Does DNSSEC slow anything down? Not measurably for you. Signed answers are larger — roughly two to three times the bytes — which is why we use algorithm 13 rather than RSA. Our nameservers do no cryptography at query time; signatures are computed in advance.

Do I need to re-sign after editing a record? No. Editing a zone re-signs it as part of publishing.

What happens if DNSCove goes down? Your existing signatures stay valid for 14 days from when they were last renewed, and renewal happens at the 7-day mark — so a total control-plane outage would need to run for a week before you had anything to worry about, and we are alerted long before that.

Can I bring my own keys? Not today. Every signed zone uses keys we generate and hold encrypted.

Does this work with the Route53-compatible API? Record management, yes — unchanged. DNSSEC itself is managed through the DNSCove console and the /api/zones/{id}/dnssec endpoints above, not through Route53-shaped calls.

Is NSEC3 zone-walking a concern? We publish NSEC3, not NSEC, specifically so your subdomain names are not enumerable from the denial chain. NSEC3 hashes can in principle be attacked offline with a dictionary; that is a known and accepted property of pre-signed NSEC3 everywhere, and it is strictly better than the plain NSEC chain many providers publish. We also refuse AXFR outright.

Which zones should I enable it on? Anything where an attacker impersonating you causes real harm: domains that carry mail, handle logins, host payment flows, or serve software downloads. It is also increasingly a procurement checkbox. For a parked or purely internal domain the benefit is smaller — though the cost is zero either way.

Related

• Quickstart — create a zone and go live
• Let's Encrypt DNS-01 — automated certificates
• Record types