DNSSEC-Setup-Leitfaden für DNScale — Schritt-für-Schritt-Anleitung

Dieser Leitfaden führt Sie durch die Aktivierung von DNSSEC in einer DNScale-Zone, das Veröffentlichen des DS-Datensatzes bei Ihrem Registrar, die Verifikation der Vertrauenskette und den Umgang mit den häufigsten Fehlermodi. Wenn Sie den konzeptionellen Hintergrund zuerst möchten, lesen Sie Was ist DNSSEC? und Wie DNSSEC funktioniert.

Vorbereitung

Stellen Sie drei Dinge sicher:

1. Ihre Zone ist an DNScale delegiert. Die NS-Datensätze bei Ihrem Registrar zeigen auf DNScale-Nameserver, und dig NS yourdomain @1.1.1.1 gibt das DNScale-Set zurück. Wenn Sie noch nicht migriert haben, machen Sie das zuerst — siehe DNS-Delegation für DNScale-Regionen.
2. Ihr TLD unterstützt DNSSEC. Alle gTLDs (.com, .net, .org usw.) und die meisten ccTLDs (.de, .fr, .nl, .eu, .uk) unterstützen DNSSEC seit Jahren. Eine Handvoll älterer oder kleinerer TLDs nicht — prüfen Sie im Zweifel den IANA-TLD-Bericht.
3. Ihr Registrar unterstützt die DS-Veröffentlichung. Die meisten großen Registrare tun das. Falls nicht, müssen Sie entweder die Domain zu einem DNSSEC-fähigen Registrar transferieren oder akzeptieren, dass DNSSEC für diese Domain nicht verfügbar ist.

Schritt 1 — DNSSEC in DNScale aktivieren

Über das Dashboard

1. Öffnen Sie Ihre Zone im DNScale-Dashboard.
2. Klicken Sie auf den Tab Sicherheit (oder DNSSEC, je nach Dashboard-Version).
3. Klicken Sie auf DNSSEC aktivieren. DNScale generiert einen neuen CSK mit ECDSA P-256 und beginnt die Zone zu signieren. Das dauert wenige Sekunden.
4. Das Dashboard zeigt den DS-Datensatz an, den Sie bei Ihrem Registrar veröffentlichen müssen:

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

Beachten Sie die vier Felder: Key-Tag (12345), Algorithmus (13 = ECDSA P-256), Digest-Typ (2 = SHA-256), Digest (die Hex-Zeichenkette). Verschiedene Registrar-UIs fragen diese in unterschiedlichen Kombinationen ab — die meisten alle vier; einige nach dem vollständigen DS-Datensatz; ein paar berechnen den Digest selbst und fragen nur nach dem öffentlichen DNSKEY.

Über die 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"

Die Antwort enthält die DS-Datensatzfelder, die Sie beim Registrar brauchen:

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

Mit Terraform

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

Nach terraform apply legt die Ressource die DS-Datensatzfelder als Outputs offen, die Sie an einen Registrar-Provider weiterreichen können (sofern Ihr Registrar Terraform-verwaltet ist) oder zur manuellen Eingabe erfassen.

Mit DNSControl

D("example.com", DNSCALE,
  AUTODNSSEC_ON,
  // ... Ihre Datensätze
);

Die AUTODNSSEC_ON-Direktive von DNSControl löst beim DNScale-Provider die Signierung aus. Der DS-Datensatz wird in der Ausgabe von dnscontrol get-zones verfügbar.

Schritt 2 — DS-Datensatz beim Registrar veröffentlichen

Das ist der einzige manuelle Schritt, den der DNS-Anbieter (noch) nicht für Sie erledigen kann — siehe CDS/CDNSKEY-Automatisierung weiter unten. Die genaue UI variiert je Registrar; hier die häufigsten.

Generelles Muster

Die meisten Registrar-Dashboards haben einen DNSSEC- oder Erweiterte DNS-Bereich pro Domain. Typisch:

1. Klicken Sie auf DS-Datensatz hinzufügen.
2. Geben Sie die vier Felder ein: Key-Tag, Algorithmus, Digest-Typ, Digest.
3. Speichern.

Manche Registrare verlangen die vollständige DS-Datensatz-Zeichenfolge (z. B. 12345 13 2 7c89aa1f...) — fügen Sie die ganze Zeile ein. Andere lassen Sie den DNSKEY öffentlichen Schlüssel einfügen und berechnen den DS selbst — beides funktioniert; verwenden Sie, was der Registrar bevorzugt.

Cloudflare Registrar

Domain → DNS → DNSSEC → Aktivieren → DS-Datensatz hinzufügen. Vier Felder einfügen. Cloudflare veröffentlicht den DS innerhalb von Minuten am TLD.

Gandi

Domains → Ihre Domain → DNSSEC → Schlüssel hinzufügen. Felder einfügen; Gandi veröffentlicht typischerweise innerhalb von 30 Minuten.

Namecheap

Domain List → Manage → Advanced DNS → DNSSEC → Add Key. Felder einfügen und speichern.

OVH

Domain → DNSSEC → Hinzufügen → DNSSEC aktivieren. Felder einfügen. OVH verbreitet sich für die meisten TLDs innerhalb von 30 Minuten.

IONOS / 1&1

Domain → SSL & DNSSEC → DNSSEC → Aktivieren → Eintrag hinzufügen. Felder einfügen. IONOS veröffentlicht typischerweise innerhalb einer Stunde.

GoDaddy

Domain → DNS → DNSSEC. Schlüssel hinzufügen. Felder einfügen. Veröffentlichungsdauer variiert; rechnen Sie mit 24–48 Stunden.

Domain bei einem Registrar nur über die Registrierung

Manche Länder-Registrierungen (z. B. DK Hostmaster, .ee Internet Foundation) akzeptieren DS-Datensätze direkt über Web-Interface oder EPP. Der Registrar würde sie normalerweise weiterleiten — falls nicht, kontaktieren Sie den Support der Registrierung.

Schritt 3 — Die Kette Ende-zu-Ende verifizieren

Sobald Sie den DS veröffentlicht haben, verifizieren Sie, dass die Kette an jedem Glied funktioniert. Zuverlässigster einzelner Befehl:

dig +dnssec example.com @1.1.1.1

Achten Sie auf zwei Dinge in der Antwort:

1. Das AD-Flag im Header — ;; flags: qr rd ra ad; — bestätigt, dass der Resolver die Kette erfolgreich validiert hat.
2. RRSIG-Datensätze im Antwortabschnitt, gepaart mit jedem Datensatz.

Wenn das AD-Flag fehlt, RRSIG-Datensätze aber vorhanden sind, validiert der Resolver nicht (probieren Sie 8.8.8.8 oder 9.9.9.9). Wenn RRSIG-Datensätze fehlen, ist das Signieren nicht in Kraft — Schritt 1 erneut prüfen.

DS in der übergeordneten Zone verifizieren

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

Für .com fragen Sie die gTLD-Server direkt. Für andere TLDs finden Sie die NS der übergeordneten Zone über dig NS .com @a.root-servers.net. oder verwenden dig +trace. Erwartete Antwort: Ihr DS-Datensatz, exakt wie eingereicht.

Wenn der DS nicht innerhalb von 48 Stunden bei der übergeordneten Zone erscheint, kontaktieren Sie Ihren Registrar — die Veröffentlichung ist vermutlich fehlgeschlagen.

Visualizer verwenden

Für ein vollständiges Bild zeichnet der DNSViz-Visualizer die ganze Kette von der Wurzel bis zu Ihrer Zone und markiert Brüche. Der Verisign DNSSEC Debugger tut dasselbe in anderer Darstellung.

Schritt 4 — Aus mehreren Resolvern testen

Verschiedene Resolver cachen unterschiedlich und rollen Updates verschieden schnell aus. Nach der initialen Verifikation testen Sie aus mindestens drei:

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

Wenn alle drei das AD-Flag zeigen, erreicht Ihr DNSSEC-Deployment die öffentliche Resolver-Flotte.

Häufige Fehlermodi und sichere Wiederherstellung

DS am Registrar passt nicht zum DNSKEY

Symptom: dig +dnssec yourdomain gibt SERVFAIL zurück. DNSViz zeigt eine rote Verbindung zwischen dem DS der übergeordneten Zone und Ihrem DNSKEY.

Ursache: Falscher Digest, falscher Algorithmus oder falsches Key-Tag beim Registrar eingegeben.

Behebung: Korrekten DS aus dem DNScale-Dashboard erneut abrufen. Beim Registrar aktualisieren. Auf TLD-Verbreitung warten. Wenn die Registrar-UI die Bearbeitung nicht akzeptiert, zuerst den falschen DS entfernen und neu hinzufügen.

Mehrere veraltete DS-Datensätze beim Registrar

Symptom: Validierung funktioniert sporadisch — manche Resolver setzen das AD-Flag, andere SERVFAIL.

Ursache: Eine frühere DNSSEC-Aktivierung hat alte DS-Datensätze hinterlassen, die zu keinem aktuellen DNSKEY mehr passen.

Behebung: Beim Registrar jeden DS entfernen, der nicht in der aktuellen DNScale-DS-Liste auftaucht. Behalten Sie nur den DS für den derzeit aktiven KSK.

TLD akzeptiert den DS nicht

Symptom: Registrar-UI lehnt den DS ab oder zeigt ihn dauerhaft als „ausstehend" an.

Ursache: Der TLD unterstützt DNSSEC noch nicht (sehr selten 2026), oder es gibt eine registrarseitige Verzögerung.

Behebung: Prüfen Sie den IANA-TLD-Bericht auf den DNSSEC-Status. Falls nicht unterstützt, können Sie DNSSEC für diese Domain nicht aktivieren; erwägen Sie einen Transfer zu einem DNSSEC-fähigen TLD. Falls unterstützt, aber blockiert, kontaktieren Sie den Registrar-Support.

Signierung deaktiviert, bevor der DS entfernt wurde

Symptom: Domain gibt SERVFAIL von validierenden Resolvern zurück; nicht-validierende Resolver lösen weiter normal auf.

Ursache: Reihenfolge falsch — der DS-Datensatz an der übergeordneten Zone zeigt jetzt auf einen Schlüssel, der in Ihrer Zone nicht mehr existiert.

Behebung: Entweder DNSSEC in DNScale erneut aktivieren (was die Signierung mit denselben Key-Tags wiederherstellt, falls möglich) oder den DS am Registrar entfernen. Korrekte Reihenfolge zur dauerhaften Deaktivierung: DS entfernen → 48h warten → Signierung deaktivieren.

Vorzeitig gecachte Negativantworten halten an

Symptom: Nach Behebung einer DNSSEC-Fehlkonfiguration sehen einige Nutzer noch eine Weile SERVFAIL.

Ursache: Validierende Resolver cachen Validierungsfehler (typischerweise bis zu 5 Minuten). Öffentliche Resolver, die RFC-8767-Stale-Data ausspielen, können veraltete Fehler länger halten.

Behebung: Warten. Die gecachten Fehler laufen ab; auf Ihrer Seite ändert nichts das Timing. Eine Verifikation aus einem frischen rekursiven Resolver (dig +dnssec yourdomain @1.0.0.1 statt @1.1.1.1) bestätigt, ob der zugrunde liegende Zustand jetzt gut ist.

Optional: DS automatisieren über CDS/CDNSKEY

RFC 7344 und RFC 8078 definieren CDS- und CDNSKEY-Datensätze — childseitige Datensätze, die der übergeordneten Zone mitteilen, welche DS-Datensätze sie veröffentlichen soll. Ein Registrar, der CDS/CDNSKEY-Scanning unterstützt, kann DS-Änderungen automatisch übernehmen, ohne manuelle Eingabe.

Unterstützung ist uneinheitlich:

• ✅ Cloudflare Registrar — vollständige CDS-Automatisierung
• ✅ Gandi — unterstützt CDS für einige TLDs
• ⚠️ Die meisten anderen — weiterhin manuelle DS-Verwaltung
• ❌ Einige Legacy-Registrare — gar keine DNSSEC-Unterstützung

DNScale veröffentlicht CDS- und CDNSKEY-Datensätze automatisch, wenn DNSSEC aktiviert ist. Wenn Ihr Registrar CDS-Scanning unterstützt, ist keine manuelle DS-Eingabe nötig — DS-Rotationen während des Schlüssel-Rollovers laufen ohne Ihr Zutun.

Was als Nächstes passiert — Automatischer Betrieb

Sobald DNSSEC in einer DNScale-Zone aktiviert ist:

• Signaturen erneuern sich kontinuierlich. RRSIG-Datensätze werden vor Ablauf neu signiert; Resolver sehen frische Signaturen bei jeder Anfrage.
• Schlüsselrotation erfolgt planmäßig. ZSK rolliert häufiger (wenn vom KSK getrennt); KSK rolliert selten (alle paar Jahre). Mit CSK (dem Standard) betrifft die Rotation den Registrar — DNScale benachrichtigt Sie, wenn eine Registraraktion nötig ist.
• Algorithmus-Aktualisierungen sind koordinierte Rolls. Wenn die Branche umschwenkt (z. B. zu Ed25519), führt DNScale einen Algorithmus-Rollover ohne Zonendaten-Ausfall durch.
• DS-Datensatz-Updates während der Rotation: Mit CDS-Automatisierung wird der DS der übergeordneten Zone ohne Ihr Zutun aktualisiert; ohne benachrichtigt DNScale Sie über einen neuen, zu veröffentlichenden DS.

Nach der initialen Einrichtung sollten Sie sich um DNSSEC nicht mehr kümmern müssen — bis Sie migrieren oder die Registrar-UX sich ändert.

Quellen

• RFC 4033/4034/4035 — DNSSEC-Kernspezifikation
• 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-Modelle (für Multi-Provider-Deployments)
• IANA Root Trust Anchors
• DNSViz-Visualizer
• Verisign DNSSEC Debugger

Weiterführende Lektüre

• Was ist DNSSEC? — Top-of-Funnel-Einführung
• Wie DNSSEC funktioniert — KSK/ZSK/DS/DNSKEY-Mechanik
• DNSSEC-Schlüsselverwaltung — operative Rollover-Verfahren
• Multi-Provider-DNS-Deployment — sicheres Hinzufügen eines zweiten DNS-Anbieters mit DNSSEC
• DNS-Delegation für DNScale-Regionen — Zone an DNScale delegieren, bevor Sie DNSSEC aktivieren
• DNS-Cache-Poisoning — der Angriff, den DNSSEC schlägt
• NIS2 und DNS-Compliance — DNSSEC als regulatorische Kontrolle