Zusammenfassung

  • RFC 3397 wies der geordneten DNS-Domain-Suchliste die DHCP-Option 119 zu. Ein Client musste zuerst Fragmente gemäß RFC 3396 verbinden und danach RFC-1035-Kompressionszeiger im vollständigen Aggregat auswerten.
  • Die Suchliste wirkte vor DNSSEC. Ein bösartiges, aber akzeptiertes Suffix konnte einen anderen FQDN erzeugen, für den der fremde Betreiber korrekt signierte Daten lieferte: eine echte Antwort auf eine unbeabsichtigte Frage.

myhost ist noch keine vollständige DNS-Frage. Zwischen der kurzen Eingabe und dem Paket auf dem Netz entscheidet eine Richtlinie, welche Domain ergänzt und welcher Kandidat zuerst versucht wird. RFC 3397 standardisierte, wie ein DHCP-Server diese Suchliste an den Client übergeben konnte.

Das Standards-Track-Dokument erschien im November 2002 und definierte die Domain-Search-Option mit dem Code 119. Ihr Bereich war eng: Sie konfigurierte Suffixe für DNS-Namensauflösung. Sie legte nicht die Reihenfolge unterschiedlicher Namensdienste fest; dafür stand die andere Option aus RFC 2937. Option 119 blieb innerhalb von DNS.

Der Wert nutzte DNS-Labelcodierung und die Kompression aus RFC 1035. Searchstring reihte Domainnamen aneinander. Ein vollständig wiederholter Name oder ein bereits vorkommendes Suffix konnte durch einen Zwei-Oktett-Zeiger ersetzt werden. In dem knappen DHCP-Optionsraum sparte dies etwa die erneute Übertragung von apple.com..

Der Zeiger hatte einen lokalen Bezug. Sein Offset begann beim ersten Datenoktett der Option; Code und Länge zählten nicht mit. Er war weder Verweis auf eine externe DNS-Abfrage noch Adresse in einem anderen Paket. Er zeigte auf eine frühere Stelle im einen logischen Optionswert.

Dieser Wert konnte physisch geteilt sein. RFC 3397 setzte die Verkettungsregel von RFC 3396 voraus: Mehrere Instanzen der Option 119 wurden zunächst zu einem Datenblock verbunden. Erst danach durften die Kompressionszeiger verfolgt werden. Deren Ziel konnte jenseits einer Fragmentgrenze liegen, denn ihr Koordinatensystem war das Aggregat.

Das Beispiel codierte eng.apple.com. und marketing.apple.com. über drei Optionsinstanzen. Am Ende des zweiten Namens verwies C004 auf Offset vier des zusammengefügten Blocks, wo apple.com. begann. Wer ein Fragment sofort als eigenständige Liste interpretierte, konnte diesen Namen nicht korrekt lesen. DHCP-Rekonstruktion musste DNS-Dekompression vorausgehen.

Eine Abschlussregel begrenzte die Interpretation. Jeder Suchname endete entweder mit dem Null-Label der Wurzel oder mit einem gültigen Zwei-Oktett-Zeiger. Traf der Parser am Aggregatende auf einen unvollständigen Namen, musste er diesen verwerfen. Fast vollständige Bytes waren kein Recht, den Rest zu erraten.

Nach der Decodierung folgte die Resolverpolitik. RFC 3397 griff Sicherheitsratschläge aus RFC 1535 und RFC 1536 auf. Suchlisten sollten ausdrücklich konfiguriert und nicht aus dem Hostnamen abgeleitet werden. Eine Eingabe mit Punkt sollte zuerst als vollständiger Name versucht und erst nach Fehlschlag mit lokalen Domains ergänzt werden. Ohne Punkt konnten Suffixe sofort angehängt werden.

Genau dort lag die Umleitung. Ein Nutzer erwartete vielleicht myhost.bigco.com. Ein unredlicher DHCP-Server installierte roguedomain.com, worauf der Rechner myhost.roguedomain.com fragte. Die DNS-Daten mussten dafür nicht gefälscht werden. Schon die Auswahl der Frage hatte die administrative Grenze verschoben.

RFC 3397 erklärte ausdrücklich, warum DNSSEC dies nicht verhinderte. Der Betreiber der fremden Domain konnte seine eigenen Resource Records rechtmäßig signieren. DNSSEC bestätigte dann, dass die Antwort für den abgefragten Namen authentisch war. Es bestätigte nicht, dass Benutzer oder Administrator genau diese Domain gemeint hatten.

Das war kein Versagen der Kryptografie, sondern eine Grenze ihrer Aussage. Lokale Konfiguration regelte den Vorrang. DHCP schlug Suffixe vor. Der Client authentisierte, akzeptierte und decodierte. Der Resolver baute Kandidaten. DNS antwortete. DNSSEC prüfte die Antwort. Die Anwendung entschied anschließend über die Verbindung. Kein späterer Nachweis autorisierte rückwirkend einen früheren Schritt.

Der RFC bewertete diese Methode als erfolgversprechender als die bloße Angabe eines illegitimen DNS-Servers. Ein Angreifer konnte gewöhnliche autoritative Infrastruktur und gültige Daten seiner eigenen Domain einsetzen. Die sichtbaren Antwortschritte blieben korrekt, weil die Manipulation vor ihnen stattfand.

Die Gegenmaßnahmen setzten entsprechend früher an: das Suchverhalten aus RFC 1536 umsetzen, manuell konfigurierte DNS-Parameter nicht durch DHCP überschreiben lassen und gegebenenfalls DHCP-Authentisierung verlangen, bevor Option 119 angenommen wird. Doch auch eine authentisierte DHCP-Nachricht bewies die Identität des Absenders, nicht die Absicht einer konkreten Eingabe.

Für eine belastbare Untersuchung braucht jede Grenze einen Beleg. Aufzuzeichnen sind die kurze Eingabe, manuelle und gelernte Listen, Reihenfolge, Herkunft, Server und Authentisierungsentscheidung. Dazu kommen rohe Option-119-Instanzen, RFC-3396-Aggregat, Zeigerziele, verworfene Namen und Kandidatenfolge. Erst dann lassen sich DNS-Frage, Validierung, Adresse und Anwendungssitzung verknüpfen.

Eine Option im Mitschnitt beweist keine Annahme. Eine korrekt decodierte Liste beweist keine Benutzung. Die DNS-Frage offenbart nicht zwingend die ursprüngliche Eingabe. Eine gültige Signatur nennt nicht die Herkunft des Suffixes. Werden diese Unterschiede entfernt, tarnt „erfolgreiche Namensauflösung“ den entscheidenden Wechsel.

Das IANA-Verzeichnis der BOOTP/DHCP-Parameter dokumentiert Code 119 und damit koordinierte Zuweisung, nicht Verbreitung oder Korrektheit. Die aktuelle RFC-Editor-Suche findet keine passenden Errata zu RFC 3397; sie zertifiziert weder Parser noch Konfigurationsvorrang oder Resolverlaufzeit.

Lu Hengs Prinzip der minimalen Anfangsspezifikation erklärt die knappe Form: standardisiert wurden DNS-Geltungsbereich, Codierung, Zeigerraum und gültiges Ende — genau die gemeinsam nötige Grenze, nicht jede interne Datenstruktur. Running-Code Primacy fordert den fehlenden Betriebsnachweis: einen Zeiger über eine Fragmentgrenze testen und die Kette bis zum tatsächlichen DNS-Paket und Verbindungsziel beobachten.

RFC 3397 lehrt daher keine pauschale Skepsis gegenüber Signaturen. Es lehrt, ihre Aussage präzise zu begrenzen. Die Signatur schützt Daten für einen bereits gewählten Namen. Wer wissen will, ob es der richtige Name war, muss die Herkunft der Frage belegen.

Quellen