Zusammenfassung

  • DNS vergleicht ASCII-Buchstaben ohne Rücksicht auf Groß- und Kleinschreibung, während viele Server die Frage in der erhaltenen Form zurückkopieren. DNS-0x20 wollte aus diesem exakten Echo vorübergehende Transaktionsidentität gewinnen.
  • Jeder geeignete Buchstabe lieferte höchstens ein Bit; Normalisierung, Kompression, Cache-Behandlung und ein gegen Herabstufung geschützter Rückfall begrenzten den Nutzen. Das Verfahren authentisierte keine Daten, und der Entwurf lief aus, ohne RFC zu werden.

Derselbe Name musste zwei verschiedene Prüfungen bestehen

Ein Resolver kann die Buchstaben eines Abfragenamens zufällig groß oder klein schreiben. Für den autoritativen Server bleibt jede Variante derselbe Name und führt zum selben RRset. Beim Eintreffen der Antwort stellt der Resolver jedoch eine engere Frage: Ist die Schreibweise im Question-Abschnitt genau diejenige, die er für diese offene Transaktion gespeichert hat?

Die erste Prüfung betrifft Bedeutung, die zweite Zuordnung. Ein Angreifer außerhalb des Übertragungswegs mag den gesuchten Namen kennen. Die erst beim Absenden erzeugte Groß-Klein-Folge kennt er nicht zwangsläufig.

DNS-0x20 machte Großbuchstaben also nicht zu einem Bestandteil der Namensautorität. Es verwendete eine für die Identität unwichtige Darstellung als kurzlebigen Zustand.

Die ursprüngliche Spezifikation trennte Identität und Darstellung

RFC 1035 legte 1987 fest, dass offizielle DNS-Vergleiche die Schreibweise nicht unterscheiden. Zwei Namen, die nur bei ASCII-Groß- und Kleinbuchstaben abweichen, sind identisch. Zugleich sollte die ursprüngliche Schreibweise nach Möglichkeit erhalten und ihr Verlust minimiert werden.

Diese Aufteilung schützte die Interoperabilität. Die Erreichbarkeit durfte nicht davon abhängen, ob jemand eine Kapitalisierung erinnerte. Wo Speicherung und Transport es zuließen, konnte die eingegebene Form dennoch bestehen bleiben. Gefaltet wurde die Identität, nicht zwingend jede Ausgabe.

RFC 4343 begrenzte diese Regel ausdrücklich auf ASCII A-Z und a-z. Sie ist weder eine allgemeine sprachliche Umwandlung noch IDNA-Verarbeitung. Außerdem kann Ausgabe-Schreibweise variieren: Verschiedene Formen teilen sich möglicherweise denselben Speicherort, und Namenskompression kann eine Darstellung aus einer anderen Stelle der Nachricht übernehmen.

Der Entwurf nutzte somit keinen reservierten Sicherheitskanal. Er nutzte eine bedingte Naht zwischen vorgeschriebener Gleichheit und häufig erhaltener Form.

Der 0x20-Bit wurde zur Einmalmarke

Der Internet-Draft Use of Bit 0x20 in DNS Labels vom März 2008 schlug vor, den 0x20-Bit jedes ASCII-Buchstabens im QNAME zufällig zu setzen. Dieser Bit trennt Groß- und Kleinschreibung. Der Server faltet alle Varianten beim Nachschlagen; der Anfragende unterscheidet sie nur während der Laufzeit seiner Anfrage.

Voraussetzung war das genaue Kopieren des Question-Abschnitts. Die Autoren berichteten, die damals geprüften großen autoritativen Implementierungen hätten den Namen Bit für Bit zurückgegeben. Die damaligen DNS-Spezifikationen verlangten dies jedoch nicht, und einige Implementierungen wandelten die Frage vollständig in Kleinbuchstaben um.

Die Verteidigung ergänzte vorhandene Antwortmerkmale. RFC 5452 verlangt die passende Frage sowie übereinstimmende Kennung, Adressen, Ports, Klasse und Typ. Eine zufällige 16-Bit-Kennung bleibt ein endlicher Raum; ein unvorhersehbarer Quellport vergrößert ihn. Die Schreibweise sollte weitere gleichzeitig zu erratende Entscheidungen aus dem bereits übertragenen QNAME beisteuern.

Das war keine Authentisierung. Weder Schlüssel noch Signatur entstanden. Eine Fälschung, die alle Werte rechtzeitig erriet, blieb möglich.

Die Schutzmenge hing vom Wortbestand ab

Nur geeignete ASCII-Buchstaben besitzen zwei Schreibweisen. Ziffern und Bindestriche liefern keinen 0x20-Bit. Lange, buchstabenreiche Namen bieten deshalb mehr Kombinationen als kurze oder numerische. Der Entwurf stellte diese Ungleichheit anhand unterschiedlich großer Bitbeiträge dar.

Ein Schalter „0x20 aktiv“ misst daher keine einheitliche Stärke. Gezählt werden müssen die Buchstaben der konkreten Frage, die Unvorhersehbarkeit ihrer Auswahl und die tatsächlich unverändert zurückgekehrten Bits.

Internationalisierte Labels erweitern den Raum nicht automatisch. RFC 4343 hält ASCII-Faltung und IDNA getrennt. Sprachabhängige Groß-Klein-Regeln auf einen Drahtwert anzuwenden kann den verarbeiteten Namen ändern, statt eine gleichwertige Darstellung zu erzeugen.

Ein korrektes Zwischenstück konnte die Probe zerstören

Ein DNS-Forwarder, der Fragen kleinschreibt, kann den richtigen Namen auflösen und richtige Daten liefern. Nach klassischer DNS-Semantik arbeitet er korrekt. Für die 0x20-Prüfung hat er dennoch den gespeicherten Zustand vernichtet.

Damit wurde eine Implementierungsgewohnheit zur Ende-zu-Ende-Abhängigkeit. Der Resolver erzeugt das Muster, aber autoritative Server, Forwarder und Inspektionsgeräte bestimmen gemeinsam, ob es zurückkehrt. Produktprüfungen aus dem Jahr 2008 sind keine Zusage über heutige oder künftige Pfade.

Auch die Abweichung hat keine eindeutige Ursache. Sie kann von Fälschung, stabiler Normalisierung, einem bestimmten Pfad oder einem Fehler stammen. Der Entwurf empfahl Protokollierung, Verwerfen und den Versuch anderer autoritativer Adressen. Ein veränderter Buchstabe war kein alleiniger Angriffsnachweis.

Vor dem Cache musste die Einmalmarke verschwinden

DNS-Nachrichten verwenden Kompressionszeiger. Namen in Answer, Authority oder Additional können auf Bytes im Question-Abschnitt verweisen. Wird mit dem Zufallsmuster dekomprimiert, kann diese flüchtige Schreibweise in den Cache und von dort in spätere Antworten gelangen.

Der Resolver sollte deshalb die ursprüngliche Frage behalten, zunächst das Echo prüfen und anschließend die Question-Daten wiederherstellen, bevor er die übrigen Abschnitte dekomprimiert. Der Zustand gehörte zur offenen Transaktion, nicht zum dauerhaften RRset.

Das ist die entscheidende Systemgrenze. Wer tolerierte Darstellung als Nonce verwendet, muss den Löschzeitpunkt definieren. Ohne Entfernung verändert die Abwehr einer einzelnen Anfrage den geteilten Zustand anderer Anfragen.

Rückfall war eine Sicherheitsentscheidung

Strikte Ablehnung schützt das Muster, kann aber eine kleinschreibende Autorität unerreichbar machen. Sofortiges Abschalten der Prüfung erhält Erreichbarkeit, kann jedoch einen vom Angreifer ausgelösten Rückfall in einen schwächeren Modus erlauben.

Der Entwurf schlug vor, andere autoritative Server zu versuchen und die ganze Folge mit neuen Kennungen, anderen Zufallselementen und möglichst anderer Reihenfolge zu wiederholen. Kehren die übrigen Werte mehrfach korrekt zurück, während nur die Schreibweise stabil verändert wird, wächst die Evidenz für Inkompatibilität.

Das kostet Zeit und Verkehr. Normalisierende Server könnten ein Mehrfaches der Abfragen erhalten; der Zufallszahlengenerator zeigt mehr Ausgaben. Die eigentliche Kontrolle lag deshalb in Wiederholungsbudget und Ausnahmegedächtnis, nicht allein im Bitmuster.

DNSSEC entfernt denselben Unterschied absichtlich

RFC 4034 definiert für DNSSEC eine kanonische RR-Form. Komprimierte Namen werden entfaltet, relevante ASCII-Großbuchstaben in Kleinbuchstaben verwandelt. Signierer und Prüfer benötigen dieselbe Oktettfolge.

0x20 wollte eine zufällige Darstellung für eine Hin- und Rückreise erhalten. DNSSEC beseitigt Darstellungsunterschiede, um kanonische Daten zu authentisieren. Ein richtiges Echo erhöht nur die Kosten des Ratens; eine gültige Signatur kann ein RRset an eine Autorisierungskette binden.

Die Aussagekraft eines ausgelaufenen Entwurfs

Der DNS-0x20-Entwurf lief im September 2008 aus. Er wurde keine RFC und belegt weder heutige Standardeinstellungen noch universelle Verbreitung. Seine Implementierungsbeobachtungen bleiben auf den damaligen Test begrenzt.

Historisch zeigt er, dass eine für Objektidentität verworfene Unterscheidung als Transaktionszustand weiterleben kann. Ihr Einsatz verlangt aber Messung, Abhängigkeitsanalyse, saubere Entfernung vor der Speicherung und einen Rückfall, den ein Gegner nicht einfach fernsteuern kann.

Die Großbuchstaben bestimmten nie, welcher Name gemeint war. Für eine Anfrage bestimmten sie nur mit, welche Antwort der Resolver akzeptieren wollte.

Quellen und Grenzen

Grundlagen sind RFC 1035, RFC 4343, RFC 5452, RFC 4034 und der DNS-0x20 Internet-Draft vom März 2008. Diese Quellen belegen keine aktuelle Marktverteilung, Produktvorgaben oder weltweite Kompatibilität.