Zusammenfassung

  • RFC 2065 band Herkunfts- und Integritätsnachweise an DNS-Ressourcensätze. Der Resolver konnte sie prüfen, ohne jeden speichernden oder weiterleitenden Server zur Vertrauensinstanz zu machen.
  • Minimal kompatible Server konnten KEY, SIG und NXT speichern und ausliefern; automatische Signaturbeigabe, CNAME-Verhalten, Delegationen und AD/CD gehörten zu einer weitergehenden Fähigkeit.
  • Der Entwurf schützte öffentliche Daten. Er verschlüsselte weder Anfrage noch Antwort, unterschied keine Fragenden und authentifizierte nicht den Rechner hinter einer korrekt aufgelösten Adresse.

Ein DNS-Cache besitzt eine wirksame Position: Er sieht die Anfrage und liefert die Antwort. RFC 2065 wollte aus dieser Position noch keine inhaltliche Autorität ableiten. Entscheidend sollte sein, ob der Ressourcensatz unter einem vertrauenswürdig hergeleiteten Schlüssel gültig signiert war.

Der Zonen-Schlüssel gehörte nach dem Dokument zur Zone, nicht zu den Servern, die Kopien speicherten. Wurde ein Server kompromittiert, konnte der Angreifer Antworten unterdrücken, alte Daten anbieten oder Verfügbarkeit zerstören. Ohne privaten Schlüssel konnte er jedoch nicht ohne Weiteres eine neue, zeitlich gültige Behauptung der Zone erzeugen. Zustellung und Autorisierung wurden getrennte Kontrollflächen.

Drei Dienste verhinderten einen unscharfen Sicherheitsbegriff

Der erste Dienst war die Verteilung öffentlicher Schlüssel. KEY verknüpfte Schlüssel mit DNS-Namen. Ein Resolver brauchte trotzdem mindestens einen verlässlich konfigurierten Startschlüssel. Von dort konnte er signierte Schlüssel sicherer Zonen weiterverfolgen. Vertrauen erhielt damit einen prüfbaren Anfang und Pfad.

Der zweite Dienst war Herkunftsauthentisierung und Integrität von Daten. Ein SIG nannte abgedeckten Typ, Signierer und Algorithmus und führte ursprüngliche TTL, Beginn, Ablauf und die Signatur. Das Ergebnis bezog sich auf einen bestimmten RRset in einem bestimmten Zeitraum. Andere Daten im selben Paket wurden nicht automatisch mitbeglaubigt.

Für nicht vorhandene Namen oder Typen definierte NXT einen eigenen Nachweis. Spätere DNSSEC-Generationen änderten diese Konstruktion. Historisch wichtig ist die Trennung: keine Antwort war nicht gleichbedeutend mit einer signierten Aussage über Nichtexistenz.

Als dritten Dienst bot RFC 2065 optionale Transaktions- und Anfrageauthentisierung. Dabei galt ausdrücklich: Eine Transaktionssignatur authentisierte nicht die RRs in der Nachricht. Für diese blieben Zonensignaturen und die Kette zum konfigurierten Schlüssel maßgeblich.

Alte Server blieben brauchbar, aber nicht allwissend

Für die Datenherkunft fügte RFC 2065 neue Ressourcentypen in das bestehende DNS-Nachrichtenformat ein. Ein Server, der unbekannte Typen bewahren und zurückgeben konnte, bildete eine Migrationsbrücke. Er musste nicht selbst kryptografisch entscheiden.

Das verschob Arbeit. Ein sicherheitsbewusster Server versuchte, die passende Signatur direkt mitzuliefern. Ein gewöhnlicher Server lieferte möglicherweise nur den angefragten Typ. Dann musste der Resolver alle SIG am Namen holen und die passende Abdeckung auswählen. Zusätzliche Abfragen waren der Preis für schrittweise Einführung.

Nicht jeder Fall passte durch diese Brücke. Das traditionelle Folgen eines CNAME konnte verhindern, dass Sicherheits-RRs am ursprünglichen Namen verfügbar wurden. RFC 2065 bezeichnete dies als Ausnahme und unterschied deshalb minimale von voller Server-Konformität. Minimal bedeutete Speicherung, Abruf und Zonentransfer von SIG, KEY und NXT. Voll umfasste unter anderem Erzeugung, automatische Beigabe, besondere Alias- und Delegationsbehandlung sowie die beiden Header-Bits.

AD zeigte an, dass der antwortende Server Daten geprüft hatte. CD erlaubte einem selbst prüfenden Resolver, noch nicht upstream validierte Daten anzufordern. Alte Systeme setzten beide Bits auf null. Das hielt sie protokollkompatibel; null war aber kein positiver Authentizitätsbeleg.

TTL und Signatur liefen auf verschiedenen Uhren

Eine Cache-TTL sinkt. Eine Signatur würde bei jeder Änderung der signierten Daten ungültig. RFC 2065 nahm daher die ursprüngliche TTL in SIG auf und definierte zusätzlich Signaturbeginn und -ablauf. Ein Resolver durfte die Nutzungsdauer verkürzen, aber nicht über die signierte Ausgangs-TTL hinaus verlängern. Nach Ablauf verlor die Signatur ihre Beweiskraft, auch wenn der Cache den Datensatz noch enthielt.

Validierung setzte außerdem eine hinreichend sichere Zeit voraus. Eine zurückgestellte Uhr konnte alte Schlüssel und Signaturen wieder glaubwürdig erscheinen lassen. Zeitquelle, Schlüsselverwahrung, Cache-Regeln und lokale Annahmepolitik gehörten deshalb zur Sicherheitskette.

Öffentlichkeit war keine Lücke, sondern eine Grenze

RFC 2065 erklärte DNS-Daten als öffentlich und Antworten grundsätzlich als gleich für alle Fragenden. Es führte keine Zugriffsliste und keine Differenzierung der Nutzer ein. Ebenso verschlüsselte es Anfrage und Antwort nicht. Vertraulichkeit sollte, falls nötig, durch einen getrennten Kanalmechanismus wie IPsec entstehen.

Die Grenze setzte sich nach DNS fort. Eine authentisch gelieferte IP-Adresse bewies nicht, dass der aktuelle Rechner an dieser Adresse berechtigt war. Sie verhinderte weder Paketmitschnitt noch eine außerhalb des DNS gefälschte Antwort. Das Protokoll machte eine Behauptung zuverlässiger; es machte nicht das gesamte Kommunikationssystem vertrauenswürdig.

Ablösung war dokumentierte Lernarbeit

Das IETF-Datatracker-Archiv zeigt Entwurfsfassungen von 1994 bis 1996 und die RFC-Veröffentlichung im Januar 1997. Daraus folgt keine bekannte Verbreitungsquote. RFC 2535 ersetzte RFC 2065 im März 1999 und erklärte, frühe Implementierungserfahrung und Anforderungen potenzieller Nutzer aufzunehmen. 2005 lösten RFC 4033, 4034 und 4035 diese Generation ab.

Moderne DNSSEC-Begriffe dürfen daher nicht unverändert ins Jahr 1997 zurückprojiziert werden. Erkennbar bleibt jedoch die Verantwortungsordnung: Signierer erzeugen Nachweise, Server transportieren sie, Resolver prüfen Anker, Zeit und Signaturen, Anwendungen sichern den restlichen Pfad.

Lu Hengs spätere Idee einer minimalen Anfangsspezifikation liefert eine interpretative Perspektive, keinen Beleg für die Absicht der RFC-Autoren. RFC 2065 beschränkte gemeinsame Regeln auf prüfbare Sicherheitsobjekte und ließ ungleichmäßige Implementierung zu. Ein Vermittler konnte nützlich sein, ohne dadurch das ausschließliche Recht zur Wahrheitsentscheidung zu erhalten.

Quellen