---
title: DNSSEC
path: concepts/dnssec
status: published
---

# 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):

| Algorithm | Number | Notes |
|-----------|--------|-------|
| RSA/SHA-256 | 8 | Widely supported, larger signatures |
| RSA/SHA-512 | 10 | Even larger signatures, seldom preferred |
| ECDSA P-256 with SHA-256 | 13 | **Recommended default.** Small signatures, fast, universal support |
| ECDSA P-384 with SHA-384 | 14 | Larger than 13 but less widespread |
| Ed25519 | 15 | Modern, fast, compact. Support is good but not universal |

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

## Lifecycle

```mermaid
stateDiagram-v2
    [*] --> disabled
    disabled --> active : enable
    active --> active : rotate-zsk
    active --> key_change_pending : rotate-ksk
    key_change_pending --> active : DS confirmed at registrar
    active --> disabled : disable
```

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

```bash
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:

```json
{
  "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`:

```bash
dig +short DS example.com
```

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

```bash
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.

```bash
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.

```bash
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

```bash
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:

```bash
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`:

```bash
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](https://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](../tutorials/enable-dnssec.md) — step-by-step walkthrough.
- [DNSSEC reference](../reference/dnssec.md) — endpoint details.