DNSSEC

DNS Security Extensions (DNSSEC) add cryptographic signatures to DNS responses so resolvers can verify answers are authentic and unmodified. ScaiDNS delegates signing to PowerDNS and adds key lifecycle management on top.

Enabling DNSSEC is a one-call operation. The hard part — publishing DS records at your registrar — is coordinated in-band via an explicit confirmation step.

What DNSSEC does#

• Authenticates answers. A DNSSEC-validating resolver knows the answer it received was signed by the authoritative zone, not spoofed in transit.
• Proves non-existence. Signed NSEC/NSEC3 records prove a name doesn't exist, without an attacker being able to fake a "doesn't exist" answer.
• Establishes a chain of trust. From the root zone down through each TLD to your zone, each level signs the next.

What it doesn't do:

• Encrypt DNS traffic. That's DoH/DoT.
• Authenticate the client.
• Prevent DDoS, resolver poisoning beyond the data path, or similar network-layer attacks.

Keys#

Every DNSSEC-signed zone has two types of keys:

• KSK (Key Signing Key). Signs the zone's DNSKEY RRset. The KSK's public key hash appears in the parent zone's DS record. Rotating the KSK means coordinating with the registrar. Typically has a longer lifetime.
• ZSK (Zone Signing Key). Signs the rest of the zone's RRsets (A, MX, TXT, etc.). Rotating the ZSK is entirely internal — no registrar coordination. Typically has a shorter lifetime.

ScaiDNS tracks both keys with lifetime defaults of 365 days for KSK, 30 days for ZSK, and a 7-day rollover overlap during rotation.

Algorithms#

Supported signing algorithms (DNSSEC algorithm numbers in parentheses):

Use 13 unless you have a specific reason to pick something else.

Lifecycle#

ZSK rotation is transparent — no registrar coordination required. KSK rotation publishes a new DS record that must be confirmed at the registrar before the rollover completes.

Enable#

1
2
3
4

curl -X POST https://scaidns.scailabs.ai/api/v1/domains/$DOMAIN_ID/dnssec/enable \
  -H "X-API-Key: $SCAIDNS_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{"algorithm": 13}'

ScaiDNS:

1. Creates KSK and ZSK in PowerDNS.
2. Signs the zone with both.
3. Returns the DS record(s) you need to publish at the registrar.

Response:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13

{
  "enabled": true,
  "ksk": {"key_tag": 12345, "algorithm": 13, ...},
  "zsk": {"key_tag": 67890, "algorithm": 13, ...},
  "ds_records": [
    {
      "key_tag": 12345,
      "algorithm": 13,
      "digest_type": 2,
      "digest": "A1B2C3..."
    }
  ]
}

Publish DS at the registrar#

Your registrar's admin panel has a DS records section. Paste in the key_tag, algorithm, digest_type, and digest values. Save.

Wait for the registrar to publish them to the parent TLD zone — this can take minutes to hours depending on the registrar. Verify with dig:

1

dig +short DS example.com

Once the DS records appear in the response, confirm publication to ScaiDNS:

1
2
3
4
5
6
7
8

curl -X POST https://scaidns.scailabs.ai/api/v1/domains/$DOMAIN_ID/dnssec/confirm-ds-published \
  -H "X-API-Key: $SCAIDNS_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "ds_records": [
      {"key_tag": 12345, "algorithm": 13, "digest_type": 2, "digest": "A1B2C3..."}
    ]
  }'

This completes the chain of trust. Validating resolvers will now verify answers for your zone.

Rotate ZSK#

Safe to do any time. Transparent to resolvers and doesn't require registrar changes.

1
2

curl -X POST https://scaidns.scailabs.ai/api/v1/domains/$DOMAIN_ID/dnssec/rotate-zsk \
  -H "X-API-Key: $SCAIDNS_API_KEY"

ScaiDNS generates a new ZSK, signs the zone with both old and new during the rollover period, then retires the old one.

Rotate KSK#

Requires registrar coordination because the KSK's hash is in the DS record.

1
2

curl -X POST https://scaidns.scailabs.ai/api/v1/domains/$DOMAIN_ID/dnssec/rotate-ksk \
  -H "X-API-Key: $SCAIDNS_API_KEY"

The response includes the new DS record. Publish it at the registrar (alongside the old one during rollover), then confirm via /confirm-ds-published. After the overlap period, the old KSK is removed and you can remove its DS record at the registrar.

Disable#

1
2

curl -X POST https://scaidns.scailabs.ai/api/v1/domains/$DOMAIN_ID/dnssec/disable \
  -H "X-API-Key: $SCAIDNS_API_KEY"

Important: Before disabling, remove the DS records at the registrar. Otherwise validating resolvers will start returning SERVFAIL when they see DS records with no matching DNSKEY in the zone.

Status#

Get the current state:

1
2

curl https://scaidns.scailabs.ai/api/v1/domains/$DOMAIN_ID/dnssec \
  -H "X-API-Key: $SCAIDNS_API_KEY"

Returns KSK and ZSK info (key tags, algorithms, creation dates), the DS records to publish, and the zone's overall DNSSEC status.

Validation#

Use a recursive resolver that validates DNSSEC. Check with dig:

1

dig +dnssec +short www.example.com @1.1.1.1

The full response (without +short) will have the ad flag in the header when validation succeeded. Online tools like dnssec-analyzer.verisignlabs.com show the full chain and flag any issues.

Best practices#

• Use algorithm 13 (ECDSA P-256) unless a specific TLD or registrar requires otherwise.
• Rotate KSK yearly, ZSK monthly or quarterly. The built-in defaults are reasonable.
• Never disable DNSSEC without removing DS first. The order matters: registrar first, then ScaiDNS.
• Keep the registrar's DS records in sync after KSK rotation. Automate this if possible; it's the #1 source of DNSSEC outages.
• Don't sign zones you don't fully control. Broken DNSSEC causes total resolution failure, not soft-fail.

What's next#

• Enabling DNSSEC — step-by-step walkthrough.
• DNSSEC reference — endpoint details.