Zusammenfassung

  • Nach RFC 3008 war eine Datensignatur erst dann materieller DNSSEC-Beleg, wenn ihre Felder zulässig waren und ein passender Zonenschlüssel sie erzeugt hatte; die korrekte Rechnung allein genügte nicht.
  • Host- und Benutzerschlüssel konnten weiterhin SIG(0)-Transaktionen authentisieren, während der Zonenschlüssel den veröffentlichten Zustand beglaubigte und damit Antragstelleridentität von öffentlicher Zonenautorität trennte.

Ein Resolver konnte eine Signatur erfolgreich prüfen und musste sie trotzdem verwerfen. Schlüssel und Rechenergebnis passten, doch der Unterzeichner war nicht befugt, für die Zone zu sprechen. RFC 3008 machte diese zweite Prüfung im November 2000 zum Kern eines überarbeiteten DNSSEC-Signaturmodells.

Das Dokument unterschied materielle von immateriellen Signaturen. Ein Data SIG deckte gewöhnlich ein RRset ab und konnte Teil der DNSSEC-Validierung sein. Andere Signaturen konnten eine anwendungsspezifische Aufgabe haben, an kein RRset gebunden sein oder als SIG(0) eine DNS-Nachricht schützen. Sie waren nicht zwingend falsch. Sie gehörten lediglich nicht zu der öffentlichen Beweiskette, mit der ein Resolver Zonendaten bestätigte.

Damit wurde das Modell aus RFC 2535 enger. Zuvor konnten unter bestimmten Bedingungen Zonen-, Host- und Benutzerschlüssel Daten signieren. Besonders bei dynamischen Updates schien das nützlich: Wenn ein Host seine eigenen Einträge unterschrieb, könnte der empfindliche private Zonenschlüssel offline bleiben.

Die vollständige Verarbeitungskette hielt dieses Versprechen nicht ein. Sichere dynamische Änderungen erforderten auch neue Signaturen für SOA- und NXT-Mengen. Der Weg aus RFC 3007 brauchte deshalb ohnehin eine online verfügbare Zonen-Signaturfähigkeit. Sobald der Zonenschlüssel vorhanden war und angenommene Daten signieren konnte, schuf die öffentliche Gültigkeit von Hostsignaturen keinen zusätzlichen Offline-Schutz mehr. Sie überließ aber jedem Resolver eine schwierigere Autoritätsentscheidung.

RFC 3008 setzte daher eine schmalere Grundregel: Daten einer sicheren Zone mussten von einem Zonenschlüssel signiert sein. Ein Resolver sollte Nicht-Zonenschlüssel für materielle Datensignaturen ignorieren, sofern keine ausdrücklich lokale Richtlinie die Grundregel überstimmte. Weniger mögliche Signierer bedeuteten weniger Flexibilität, begrenzten aber die Prüfkette durch die Labeltiefe des Namens und machten Autorität aus der Zonenstruktur lesbar.

Der Name „Zonenschlüssel“ ersetzte keine Feldprüfung. Bei einem Data SIG musste type covered zum RRset passen. Der Algorithmus musste bekannt sein und ein definiertes SIG-Datenformat besitzen. Die Zahl der labels durfte die Labels im Eigentümernamen nicht überschreiten. Original TTL musste mindestens dem aktuellen SIG-TTL entsprechen, weil Zwischenserver den TTL nicht erhöhen dürfen. Der Prüfzeitpunkt musste zwischen inception und expiration liegen.

Danach mussten signer name, key tag und Algorithmus einen möglichen KEY bestimmen. Fehlte er, war die Signatur immateriell. Traf die Auswahl auf mehrere KEYs, blieben alle Kandidaten, bis die kryptografische Prüfung den tatsächlichen Signierer ergab. Der Resolver durfte einer nachträglich erfolgreichen Rechnung nicht rückwirkend eine Rolle erfinden.

Auch der KEY selbst enthielt Schranken. Seine type flags mussten Authentisierung erlauben. Für einen materiellen Data SIG musste name type den Wert zone tragen. Das protocol-Feld musste DNSSEC oder ALL nennen. Der KEY-Algorithmus musste mit der SIG übereinstimmen. Derselbe öffentliche Schlüssel konnte mathematisch funktionieren und trotzdem für DNSSEC ungeeignet sein, wenn Datensatz und Rolle einen anderen Zweck auswiesen.

Die Schritte liefern verschiedene Quittungen. Kryptografische Prüfung verbindet Schlüssel, Signatur und Eingabe. Formprüfung macht das Objekt verarbeitbar. Schlüsselrolle weist Autorität für die Datenklasse zu. Die Vertrauenskette verbindet die Zone mit einem bekannten Anker. Das Zeitfenster begrenzt die Aussage. Selbst gemeinsam beweisen sie nicht, dass der Dienst hinter einer Adresse erreichbar oder jede Bedeutung des Inhalts wahr ist; sie sichern die veröffentlichte DNS-Aussage.

Für Transaktionssicherheit blieb eine getrennte Spur. Ein SIG mit type covered null schützt die DNS-Nachricht und heißt SIG(0), ausführlicher beschrieben in RFC 2931. Eine Transaktion wird von Benutzer oder Host initiiert, weshalb user oder host/entity als erwartete Schlüsseltypen galten. Auch ein Nameserver signierte in diesem Zusammenhang als Host und nicht als Zone. Zonenschlüssel sollten SIG(0) normalerweise nicht erzeugen.

Hostschlüssel verloren dadurch nicht ihre Funktion. Sie konnten belegen, welcher principal ein Update gesendet hatte. Anschließend prüfte der Primary die lokale Richtlinie aus RFC 3007: erlaubte Namen, RR-Typen und Aktionen, mit Verweigerung als Ausgangspunkt. Nach Annahme signierte der Zonenschlüssel den öffentlichen Zustand. Vorschlag, Zulassung und öffentliche Beglaubigung blieben getrennte Befugnisse.

Diese Trennung hielt die private Zugriffspolitik des Primary aus dem öffentlichen Format heraus. Resolver mussten nicht nachvollziehen, welcher Client einen Eintrag früher schreiben durfte. Für die veröffentlichten Daten galt eine gemeinsame Zonenregel. Der Betreiber konnte Update-Rechte ändern, ohne DNS-Nachrichten oder alle Resolver um eine neue institutionelle Grammatik zu erweitern.

Das alte signatory-Feld von KEY wurde bewusst nicht zum Ersatz. RFC 3008 vergab dafür keine Werte und verlangte seine Nutzung nicht. Einige Bits schienen Autorität transportieren zu können, hätten zukünftige Richtlinien aber in eine feste Liste gezwungen und Update-Zulassung mit Datenvalidierung vermischt. Lokale Richtlinie am Schreibpunkt und Zonenschlüssel am öffentlichen Prüfpunkt waren zwei klarere Oberflächen.

Historisch blieb das eine Zwischenstufe. RFC 3090 erläuterte den Sicherheitsstatus von Zonen im alten Rahmen. RFC 3658 führte den DS-Datensatz ein und änderte die Delegationsverknüpfung. RFC 4033, RFC 4034 und RFC 4035 lösten später die KEY/SIG-Generation von RFC 2535 und 3008 ab.

RFC 3008 ist deshalb keine heutige Konfigurationsanleitung. Seine KEY-Felder dürfen nicht ohne historische Erklärung auf DNSKEY und RRSIG übertragen werden. Der Zustandsbericht RFC 3130 zeigt, dass DNSSEC 2001 als Werkzeugkasten mit unterschiedlich weit entwickelten Teilen verstanden wurde. Das belegt eine Übergangsphase, nicht flächendeckenden Einsatz oder einen gemessenen Sicherheitsgewinn durch dieses Dokument allein.

Beständig blieb die Reihenfolge: Ein Beweis bringt sein Mandat nicht selbst mit. Laufender Resolver-Code muss Signiererrolle, Objektklasse, Protokollzweck, Zeit und Vertrauensweg zusammenführen. Sonst wird die Präzision der Mathematik zur ungewollten Ermächtigung eines Schlüsselbesitzers.

Durch Lu Hengs Running-Code-Primacy-Linse entsteht Autorität erst, wenn der Resolver die vollständige Klassifikation ausführt, nicht wenn ein signiertes Objekt vorhanden ist. Die Zonenschlüsselregel bildet die gemeinsame Mindestschicht. Lokale Ausnahmen bleiben bei dem Resolver, der sie wählt, und schreiben nicht still die globale Regel um. Stabilität verlangt die einzelnen Quittungen statt eines einzigen Status „Signatur gültig“.

RFC 3008 machte Signaturen damit weniger magisch und stärker rechenschaftspflichtig. Eine Signatur belegt Schlüsselkontrolle, KEY erklärt einen Zweck, die Zonenposition eine Rolle, die Kette eine Herkunft und die Uhr eine Gültigkeit. Erst ihr Zusammentreffen macht die korrekte Signatur zur autorisierten DNSSEC-Aussage über dieses RRset.

Sources