Zusammenfassung

  • Der wirksame DS ist Inhalt der übergeordneten Zone. CDS/CDNSKEY beschreibt den gewünschten Zielzustand des Kindes. Bei vorhandenem DS authentifiziert die bestehende Kette einen Rollover; bei der Ersteinrichtung fehlt genau diese Kette.
  • RFC 9615 nutzt übereinstimmende Kopien unter den bereits gesicherten Namensräumen aller anwendbaren externen Nameserver. Die Prüfung belegt die Zustimmung der veröffentlichten DNS-Betreiber, nicht Eigentum oder bewusste Freigabe des Registranten.
  • Zulassungsrichtlinie, Hash-Auswahl, Eintrag in der übergeordneten Zone, Cache-Fristen und Validierung sind eigene Akte. Algorithmus null fordert die vollständige DS-Entfernung und gehört in einen separaten destruktiven Ablauf.

Ein gültiger Antrag ohne gültigen Anfang

Ein Unternehmen aktiviert DNSSEC bei seinem DNS-Dienst. Der Dienst erzeugt Schlüssel, veröffentlicht DNSKEY, CDS und CDNSKEY an der Zonenspitze und signiert alles korrekt. Alle autoritativen Server liefern dieselben Werte. In der übergeordneten Zone existiert noch kein DS.

Die Signatur kann den fehlenden Anfang nicht ersetzen. Auch ein Angreifer kann ein in sich stimmiges Schlüsselpaar samt Signatur erzeugen. Erst der DS in der übergeordneten Zone zeigt einem Validator, welche DNSKEY der Kindzone an eine bereits akzeptierte Vertrauenskette gebunden ist.

Der DNS-Betreiber beweist Kontrolle über den privaten Schlüssel und die ausgelieferten Antworten. Der Domaininhaber sollte den Betreiber beauftragen. Der Registrar kennt eine Kontobeziehung. Vergabestelle oder Parent-Agent können den DS tatsächlich einfügen. Diese Tatsachen ergänzen einander, ohne austauschbar zu sein.

Die Automatisierung beseitigt einen historischen Engpass. Manuelles Kopieren von Hashwerten bei jedem KSK- oder CSK-Wechsel erzeugt Fehler und Verzögerung. CDS/CDNSKEY ist wertvoll, wenn es die Übertragung vereinfacht und zugleich sichtbar lässt, aus welchem Mandat die Änderung der übergeordneten Zone folgt.

Das Kind äußert einen Zielzustand

Der DS liegt in der Elternzone und bindet über Schlüsselkennung, Algorithmus, Hash-Typ und Hashwert an eine DNSKEY der Kindzone. CDS hat die DS-Felder unter einem anderen RR-Typ. CDNSKEY liefert den öffentlichen Schlüssel, aus dem die Elternseite den DS berechnen kann.

RFC 7344 beschreibt einen Ersetzungswunsch. Der Empfänger vergleicht ihn mit dem bestehenden DS und übersetzt die Differenz in eigene Operationen der Elternseite. Das Kind schreibt weder direkt in die Elternzone noch überträgt es deren Autorität.

Fehlen beide RRsets, bleibt der DS unverändert. Nach erfolgreicher Synchronisierung darf das Kind die Signale entfernen. Ein leerer Abruf oder eine Störung darf deshalb niemals als Löschwunsch gelten.

Die Elternseite wählt CDS oder CDNSKEY als bevorzugten Mechanismus und kann Hash-Typen durch eine lokale Richtlinie begrenzen. Ein aus CDNSKEY erzeugter DS-Satz kann sich bei den Hashwerten vom CDS unterscheiden und trotzdem denselben Schlüssel repräsentieren.

Die Rollen bleiben lesbar: Der Betreiber der Kindzone wählt und publiziert, der Parent-Agent authentifiziert und lässt zu, die Elternseite veröffentlicht, der Resolver validiert. Automatisierung verbindet diese Entscheidungen; sie delegiert sie nicht stillschweigend weiter.

Vorhandenes Vertrauen trägt den Rollover

Ein bestehender DS, der zu einer aktuellen DNSKEY passt, kann ein neues CDS/CDNSKEY authentifizieren. Das Signal an der Zonenspitze muss mit einem Schlüssel signiert sein, der sowohl im aktuellen DNSKEY-RRset als auch durch den DS vertreten ist. Die Änderung darf die laufende Delegation nicht brechen.

Der alte Entry Point autorisiert damit einen begrenzten Übergang. Der Parental Agent prüft dennoch Aktualität, vergleicht Zustände und verhindert, dass eine frühere Beobachtung die neue überschreibt. RRSIG-Inception und SOA-Serial helfen; der zuletzt akzeptierte Zustand muss trotzdem erhalten bleiben.

Nach der Aktualisierung der Elternzone laufen mehrere TTLs. Resolver können alte DS, DNSKEY und RRSIG in unterschiedlichen Kombinationen halten. Der neue Schlüssel wird vorab überall veröffentlicht, der alte bleibt bis über den möglichen Lebenszyklus seines DS hinaus erhalten.

Der aktuelle BIND-Leitfaden zeigt das Zusammenspiel: BIND publiziert CDS/CDNSKEY, befragt konfigurierte parental-agents und pausiert den Rollover, bis alle den erwarteten DS zeigen. Unterstützt die Elternseite den Mechanismus nicht, bleibt die manuelle Übermittlung. Eine automatisierte Kindzone macht die Elternseite nicht automatisch handlungsfähig.

Die Ersteinrichtung leiht sich eine Betreiberkette

RFC 8078 nennt für den ersten DS authentifizierte UI/API-Kommunikation, zusätzliche Registrierungsprüfungen, Beobachtung über Zeit und Orte, Challenge oder Verarbeitung bei Delegationserstellung. Diese Ansätze können angemessen sein, bieten aber keine DNSSEC-Kette aus dem noch unsicheren Kind.

RFC 9615 nutzt bei mindestens einem externen Nameserver einen anderen Pfad. Vor jeden im NS-Satz der Elternzone genannten Nameserver-Hostnamen wird _signal gesetzt. Darunter identifiziert ein _dsboot-Name die Kindzone und trägt eine Kopie ihres CDS/CDNSKEY.

Die Signalisierungszone hat bereits eine validierbare DNSSEC-Kette. Die Elternseite authentifiziert die Kopie im Namensraum des DNS-Betreibers und vergleicht sie mit den direkten Antworten der Kindzone. Vertrauen wird von einem bestehenden Betreiberpfad übertragen, nicht aus der Selbstsignatur des Kindes erzeugt.

Der Parent-Agent bestätigt zunächst, dass kein DS besteht, und liest den NS-Satz der Elternzone. Er fragt jedes autoritative System der Kindzone direkt und ohne Cache. Danach validiert er jedes anwendbare externe Signal und verlangt Gleichheit nach RR-Typ.

Ausfall, unauthentisierte Antwort, leerer Wert nur an einer Stelle oder abweichender Inhalt beendet das Verfahren. Liegen sämtliche Nameserver innerhalb der Kinddomain, fehlt der unabhängige Pfad vollständig.

Diese Strenge schützt Delegationen mit mehreren Anbietern. Kein einzelner Betreiber kann allein seine KSK in die Elternzone bringen, während andere autoritative Server eine andere Sicht zeigen. RFC 8901 verlangt auch im laufenden Betrieb mit mehreren Signierern eine gemeinsame CDS/CDNSKEY-Sicht.

Betriebskontrolle ist kein Eigentumsnachweis

Die RFC-9615-Prüfung zeigt, dass die im NS sichtbaren Betreiber als Signer auftreten wollen und dasselbe Material kennen. Sie zeigt nicht, wer den Auftrag erteilt hat oder ob der Domaininhaber von der Aktivierung wusste.

Der RFC weist ausdrücklich darauf hin, dass ein Betreiber die Signale ohne explizites Wissen des Eigentümers hinzufügen kann, und empfiehlt Transparenz. Legitime Voreinstellung, Fehlkonfiguration und kompromittiertes Anbieterkonto können daher gleich gut signierte Daten erzeugen.

Der Parent-Agent braucht eine getrennte Berechtigungskette: Wer darf Ersteinrichtung, Rollover oder Rückkehr in den unsicheren Zustand anstoßen? Wann wird der Inhaber informiert? Wie stoppt er eine unerwartete Änderung? DNSSEC beweist Herkunft innerhalb der Kette, nicht den institutionellen Auftrag außerhalb davon.

QNAME-Minimierung reduziert eine weitere Angriffsfläche. Ohne sie sieht eine übergeordnete Zone der Signalisierungsdomain den vollständigen Namen und kann versuchen, selbst signiert zu antworten statt zu delegieren. Minimierung hilft, ersetzt aber weder die korrekte Zone noch den Inhaltsvergleich.

Algorithmus null entfernt den ganzen DS

CDS 0 0 0 0 und CDNSKEY 0 3 0 0 sind die exakten Formen für die Entfernung des gesamten DS RRsets. Algorithmus null ist kein nutzbarer Signaturalgorithmus und eine fehlende Antwort ist kein Ersatz für dieses Signal.

Nach Prüfung und Zulassung entfernt die Elternseite DS. Die Kindzone wartet die TTLs der Elternseite ab, bevor sie Signaturen und Schlüssel entfernt. Sonst besitzen Resolver noch einen DS, der auf einen nicht mehr vorhandenen Schlüssel zeigt, und behandeln die Delegation als ungültig.

Cloudflares dokumentierte Zustände illustrieren eine Umsetzung: Während der Deaktivierung bleibt die Zone signiert und sendet das Nullsignal; erst nach der DS-Entfernung verschwindet das DNSSEC-Material. Zustandsnamen sind produktspezifisch, die zeitliche Trennung nicht.

Die Rückkehr in den unsicheren Zustand senkt den Schutz und kann den authentifizierten Wiederherstellungspfad zerstören. Sie benötigt deshalb eigene Zustimmung, Benachrichtigung, TTL-Planung und einen Weg zurück. Schweigen oder Abruffehler dürfen diese Macht nie ausüben.

Evidenz endet beim validierenden Resolver

Vor der Änderung werden NS und DS der Elternzone, direkte Antworten aller autoritativen Server der Kindzone, Signalisierungsnamen, Validierungsketten, Gleichheit, Aktualität, Schutz vor Wiederholung, Hash-Entscheidung, Berechtigung und vorgeschlagene DS-Differenz festgehalten.

Danach werden alle autoritativen Server der Elternzone beobachtet, TTL-Fenster abgewartet, Schlüssel und Signaturen auf allen Servern der Kindzone geprüft und unabhängige Validatoren verwendet. Ein grünes Portal beweist die Annahme eines Befehls. Ein DS der Elternzone beweist ihren autoritativen Zustand. Erst die erfolgreiche Kette zeigt operative Wirkung auf einem echten Pfad.

Auch Abbrüche sind Belege. Uneinige Betreiber, ungültige Signale, nicht unterstützte Hashwerte oder eine vollständig innerhalb der Kinddomain liegende Delegation zeigen, an welcher Grenze die Befugnis endete. Wer Ablehnung erklärt, muss sie nicht umgehen.

Quellen