Zusammenfassung

  • RFC 3090 ersetzte algorithmusabhängige Zustände und „experimentell sicher“ durch drei Attribute: global gesichert, lokal gesichert und ungesichert.
  • Der Resolver leitete daraus weiterhin ein binäres Urteil ab, abhängig von eigenen Ankern, Algorithmen, Delegationsbelegen und dem gewählten Prüfpfad.

Die Signatur der Zone konfigurierte nicht alle Beobachter

Frühes DNSSEC wurde in einzelnen Abschnitten ausgerollt. Eine Zone konnte Daten signieren, obwohl ihr Parent noch keine Vertrauenskette von der DNS-Wurzel herstellte. Für einen Versuch ließ sich der Schlüssel direkt in ausgewählten Resolvern hinterlegen. Andere Resolver kannten diesen Ausgangspunkt nicht. Ein pauschales „sicher“ vermischte damit die Leistung des Zonenbetreibers und die Möglichkeit des Prüfers.

RFC 3090 unterschied vier Rollen. Der Administrator bestimmte den Zustand der Zone. Ein Dynamic-Update-Server musste ihn bei Änderungen erhalten. Der delegierende Parent stellte den Übergang zum Kind dar. Der Resolver entschied, ob sein tatsächlich verfügbarer Weg eine Validierung trug. Kind-Signatur, Parent-Aussage und lokale Vertrauenseinstellung waren voneinander abhängig, aber nicht austauschbar.

Das Dokument beendete deshalb einen eigenen Zonenstatus pro Algorithmus. Auch „experimentell sicher“ verschwand. Für die mit dem Versuchsschlüssel konfigurierten Resolver war die Zone eine lokal gesicherte Insel; für allgemeine Resolver war sie ungesichert. Das Experiment definierte eine Beobachtergruppe, keinen vierten Sicherheitszustand.

Eine Insel war nur von der richtigen Küste erreichbar

Zusammenhängende signierte Zonen konnten unter einem ungesicherten Parent eine Sicherheitsinsel bilden. Wurde der Schlüssel an ihrer Spitze als Vertrauensanker eingerichtet, konnte der Resolver innerhalb der Insel abwärts prüfen, obwohl von der globalen Wurzel keine vertrauenswürdige Kette dorthin führte.

Zwei korrekt arbeitende Resolver konnten somit dieselben autoritativen Daten verschieden einordnen. Mit Anker und akzeptablem Weg war die Zone lokal gesichert; ohne vertrauenswürdigen Startpunkt war sie ungesichert. Nicht die Zonendatei unterschied sich, sondern der Zustand des Prüfers.

Bei mehreren Ankern musste der richtige gewählt werden. Die nächstgelegene Sicherheitswurzel war nach RFC 3090 die konfigurierte Wurzel mit der längsten geordneten Übereinstimmung der rechten Namensbestandteile. Ein Beginn an einer ferneren Wurzel konnte unterwegs einen NULL-Schlüssel finden und Unsicherheit folgern, obwohl eine nähere Insel konfiguriert war. Überlappende Inseln machten die Auswahl des Starts zu einer Sicherheitsentscheidung.

Eine sichtbare Signatur allein belegt daher keinen allgemeinen Status. Zur Untersuchung gehören die aktiven Anker, das Auswahlverfahren, unterstützte Algorithmen, der abgerufene Pfad, Zeitpunkt und lokale Richtlinie. Validierung ist das Ergebnis dieser konkreten Zusammensetzung, kein dauerhaftes Abzeichen der Zone.

Der Parent konnte Sicherheit durch Abwesenheit ausdrücken

Die Architektur von RFC 2535 besaß an der Delegationsgrenze eine kontraintuitive Regel. Bei einem gesicherten Parent konnte das Fehlen eines Child-KEY eine gesicherte Kindzone bedeuten. Ein signierter NULL-Schlüssel kennzeichnete dagegen ein ungesichertes Kind. Die positive Aussage erschien als Schweigen, die negative hinterließ ein signiertes Objekt.

RFC 3090 nannte das betrieblich unangenehm und wenig intuitiv. Es ersetzte das Verfahren nicht, sondern klärte seine Interpretation. Abwesenheit war also kein allgemeiner Beweis. Zuerst mussten der gesicherte Parent, der authentifizierte Kontext und die Geltung der damaligen Regeln feststehen.

RFC 3658 führte später DS ein. RFC 4033, 4034 und 4035 bauten die moderne Architektur aus DNSKEY, RRSIG, NSEC und DS anstelle von KEY, SIG und NXT. Sie erklären den Übergang, dürfen aber die tatsächlich beobachteten Objekte des Jahres 2001 nicht rückwirkend umbenennen.

Global war eine Klasse, kein Unverwundbarkeitssiegel

Eine global gesicherte Zone brauchte verpflichtende Algorithmen, eine Parent-Signaturkette innerhalb des Baums, geeignete Zone-Signing-KEYs an der Spitze, NXT-Abdeckung und Signaturen für die vorgesehenen RRsets. Eine lokal gesicherte Zone durfte andere Algorithmen oder einen vorkonfigurierten Weg außerhalb des Baums verwenden, musste aber signierte Zoneneigenschaften behalten. Alles andere war ungesichert.

„Global“ und „lokal“ bezeichneten ausdrücklich Attribute, keine Konformitätszertifikate. Ein restriktiver Resolver erkannte womöglich nur die erste Klasse an. Ein zusätzlich befähigter oder konfigurierter Resolver akzeptierte Teile der zweiten. Bei der Anfrage lieferten beide letztlich nur gesichert oder ungesichert.

Auch die stärkste Klasse schloss Fehlverhalten nicht aus. Ein defekter Resolver konnte schlechte Daten annehmen; ein kompromittierter Parent den Betrieb unterbrechen. RFC 3090 lieferte keine absolute grüne Anzeige. Es ordnete Beweise und Verantwortung zwischen Kind, Parent, Resolver und Protokollregel.

Quellen

  1. https://www.rfc-editor.org/info/rfc3090
  2. https://www.rfc-editor.org/rfc/rfc3090.html
  3. https://www.rfc-editor.org/rfc/rfc3090.txt
  4. https://datatracker.ietf.org/doc/rfc3090/
  5. https://www.rfc-editor.org/errata/rfc3090
  6. https://www.rfc-editor.org/rfc/rfc2535.html
  7. https://www.rfc-editor.org/rfc/rfc3007.html
  8. https://www.rfc-editor.org/rfc/rfc3008.html
  9. https://www.rfc-editor.org/rfc/rfc3658.html
  10. https://www.rfc-editor.org/rfc/rfc4033.html
  11. https://www.rfc-editor.org/rfc/rfc4034.html
  12. https://www.rfc-editor.org/rfc/rfc4035.html
  13. https://www.rfc-editor.org/rfc/rfc5011.html