Zusammenfassung

  • RFC 8901 ist ein Informational-Dokument mit IETF-Konsens, keine Standards-Track-Pflicht und kein Nachweis, dass ein bestimmter Anbieter Multi-Signer-DNSSEC unterstützt.
  • In beiden Modellen muss das DNSKEY-RRset jedes Anbieters die aktiven ZSK aller Beteiligten enthalten. Sonst kann ein Resolver Schlüssel von A cachen, beim Failover eine Signatur von B erhalten und sie ablehnen.
  • Der Zoneninhaber koordiniert Schlüsselaustausch, KSK/Parent-DS-Modell, gemeinsame Algorithmen und Rollover-Zeitplan vor dem Ausfall. Bis diese Belege bestehen, ist der zweite Anbieter nur ein möglicher Pfad.

Der Server war erreichbar, die Vertrauenskette nicht

Zwei unabhängige Anbieter signieren und bedienen dieselbe Zone. Ein validierender Resolver folgt der sicheren Delegation, holt bei Provider A das DNSKEY-RRset, authentifiziert es über das Parent-DS und speichert es. Während dieser Cache noch gilt, fällt A aus. Der Resolver fragt B, der die gesuchte Antwort mit seinem ZSK signiert.

B ist betriebsbereit. Fehlt sein aktiver ZSK jedoch im von A erhaltenen DNSKEY-Satz, besitzt der Resolver keinen authentifizierten öffentlichen Schlüssel für die RRSIG. Er kann andere Server probieren, zusätzliche Laufzeit verbrauchen oder aufgeben, bevor der Client wartet. RFC 8901 ändert den Resolver nicht; das Dokument verlangt einen gemeinsamen Schlüsselzustand, damit gewöhnliche Validierung den Pfadwechsel übersteht.

Getrennte Netze, Verträge und NS-Einträge belegen mögliche autoritative Pfade. Sie belegen nicht, dass Bs Signatur mit As gecachtem Zustand prüfbar ist. Redundanz ist erst vollständig, wenn auch der kryptografische Pfad wechselt.

Zwei Verwahrmodelle, eine Invariante

In Modell 1 hält der Zoneninhaber einen gemeinsamen KSK und verwaltet das Parent-DS. Jeder Anbieter behält eigene ZSK. Der Inhaber sammelt die öffentlichen ZSK, baut ein kombiniertes DNSKEY-RRset, signiert es mit dem KSK und verteilt es an alle. Auch ohne Schlüsseländerung muss er die Signatur vor ihrem Ablauf erneuern.

Der Parent hat einen gemeinsamen Einstieg, alle liefern dasselbe signierte Objekt. Dafür werden KSK-Verwahrung, periodische Signatur, API-Zugriff und Verteilung zur gemeinsamen kritischen Fläche. Eine veraltete Kopie bei nur einem Anbieter teilt den Betriebszustand.

In Modell 2 hält jeder Anbieter eigene KSK und ZSK. Jeder importiert die öffentlichen ZSK der anderen und signiert das DNSKEY-RRset mit seinem KSK. Der Parent veröffentlicht DS-Einträge für alle KSK. Private Verwahrung bleibt verteilt, doch der gemeinsame öffentliche Zustand wächst: As KSK-Rollover ändert seinen Parent-Pfad; As ZSK-Rollover ändert das DNSKEY, das B ausliefern muss.

Ein Rollover ist eine verteilte Transaktion

In Modell 1 darf A einen neuen ZSK nicht sofort einsetzen. Der Inhaber holt ihn, ergänzt den kombinierten Satz, signiert und verteilt ihn. Die Aktivierung wartet auf autoritative Verbreitung und DNSKEY-TTL; die Entfernung des alten Schlüssels wartet, bis signierte Daten und Caches ihn nicht mehr benötigen. Ein KSK-Wechsel durchläuft zusätzlich Parent-DS und dessen Cache-Horizont.

In Modell 2 kann A sein DNSKEY selbst signieren, übergibt den neuen ZSK aber dem Inhaber für den Import bei B. A wartet auf Import, Verbreitung an allen autoritativen Flächen und TTL, bevor er Zonendaten damit signiert. Die Entfernung wiederholt die Koordination rückwärts.

„Schlüssel erzeugt“, „API 200“ oder eine korrekte Abfrage sind keine Kontinuitätsquittung. Die belastbare Folge lautet: Export, Annahme, Import bei jedem Anbieter, Veröffentlichung auf jeder Fläche, TTL-Ablauf, unabhängige Validierung mit Antworten beider Signierer und erst dann Aktivierung oder Stilllegung.

Algorithmen und negative Antworten

Die Anbieter benötigen einen gemeinsamen DNSSEC-Signaturalgorithmus oder denselben Satz. Werden mehrere Algorithmen in DNSKEY angekündigt, gelten die Regeln aus RFC 4035 für die Zonen-RRsets. Unvereinbare Entscheidungen ergänzen sich nicht durch Unternehmensvielfalt.

NSEC- oder NSEC3-Beweise reisen mit der negativen Antwort, weshalb unterschiedliche Verfahren technisch möglich sind. NSEC neben NSEC3 hebt jedoch den Enumerationsschutz von NSEC3 auf; dauerhafte Mischungen können negative Caches weniger effizient machen. RFC 8901 bevorzugt ein Verfahren und minimiert unvermeidbare Unterschiede.

Ein Test nur auf A oder AAAA reicht deshalb nicht. Positive Daten können validieren, während die Nichtexistenz eines Namens oder Typs einen anderen Signatur-, Beweis- und Cachepfad offenlegt.

Was das RFC nicht belegt

RFC 8901 belegt weder API-Unterstützung noch Implementierung, Ausfall, Verfügbarkeitsgewinn oder Verbreitung. DNSSEC-Validierung beweist ebenso wenig geschäftliche Bevollmächtigung, Anwendungszustand oder Traffic-Umschaltung; sie beweist eine begrenzte kryptografische Beziehung der beobachteten Daten.

Die betriebliche Schlussfolgerung bleibt eng: Ein zweiter Anbieter verringert eine Abhängigkeit erst dann, wenn der Inhaber vor dem Vorfall die gemeinsame Schlüsselansicht, Parent-DS, Algorithmen und Rollover-Zeitachse reproduzieren kann.

Quellen