Zusammenfassung

  • Die von Ray Bellis verfasste RFC 5625 geht davon aus, dass ein einfacher DNS-Proxy niemals alle gegenwärtigen und künftigen Erweiterungen kennen kann. Unbekannte Flags, Labels, Typen und Klassen sollen deshalb passieren; vollständige Antworten, EDNS, TC, TCP und authentifizierungsrelevante Bytes sollen erhalten bleiben; wirklich fehlerhafte Nachrichten und aktive Richtlinien sollen sichtbar scheitern.
  • Das Dokument wurde 2009 als BCP 152 veröffentlicht. Es beweist weder heutige Gerätekonformität noch allgemeine Einführung, und Transparenz ist keine DNSSEC-Validierung. Sein bleibender Wert liegt in der Zuständigkeitsteilung: Spezifikationen und Endpunkte besitzen die Semantik, der Proxy nur begrenzten Zustand, Schnittstellenexposition und ausdrücklich lokale Entscheidungen.

Ein vollständiger Eindruck aus einer unvollständigen Antwort

Ein Client erwartet eine DNS-Antwort, die größer als 512 Byte ist. Der Server sendet sie und setzt bei nötiger Verkürzung korrekt TC. Der Heimrouter schneidet die Antwort an seiner eigenen Grenze ab und entfernt das Signal. Beim Client kommt ein syntaktisch brauchbarer Teil an. Er weiß nicht, dass Datensätze fehlen.

Ein offener Fehler hätte eine Wiederholung über TCP ausgelöst. Der scheinbare Erfolg verhindert die Reparatur.

RFC 5625, DNS Proxy Implementation Guidelines, erschien im August 2009 als Best Current Practice 152. Alleiniger Autor ist Ray Bellis, damals bei Nominet UK. Das Dokument akzeptiert die Realität kleiner Gateways: knappe Hardware, lange Firmwarezyklen und keine Möglichkeit, zukünftige DNS-Erweiterungen im Voraus zu implementieren.

Seine Antwort ist kein immer größerer Parser, sondern eine schmale Rolle. Der Proxy erhält eine LAN-Anfrage, leitet sie unverändert an einen bekannten rekursiven Resolver und gibt die vollständige Antwort an den ursprünglichen Client zurück. Er verwaltet Zuordnung, Upstream und Schnittstellen. Daraus folgt aber keine Zuständigkeit, unbekannte Protokollwerte neu zu deuten.

Was die 24 Geräte von 2008 belegen

Die Kurzfassung von SAC035 und der vollständige Bericht dokumentieren kontrollierte Tests von 24 Heimroutern oder Firewalls für kleine Büros im Juli und August 2008.

Alle 24 konnten DNSSEC-Anfragen direkt zu externen Resolvern routen. 22 boten zusätzlich einen Proxybetrieb. Sechs dieser Proxys hatten Probleme mit DNSSEC-bezogenen Flags oder validierten Antworten. 18 begrenzten UDP-Antworten auf 512 Byte oder eine MTU-bezogene Größe; nur vier gaben Proxyantworten bis 4096 Byte zurück, und nur ein Gerät vermittelte DNS über TCP. Sechs Geräte waren in der Standardkonfiguration vollständig kompatibel, neun weitere ließen sich so umstellen, dass der inkompatible Proxy umgangen wurde.

Diese Zahlen bleiben auf Stichprobe, Konfiguration und Jahr begrenzt. Sie sind keine Aussage über heutige Marktanteile oder moderne Produktreihen. Sie zeigen jedoch das konkrete Versagensmodell: Zwei fähige Endpunkte können durch eine veraltete Zwischeninstanz getrennt werden.

Der IETF-Zulassungsvermerk hält starken Konsens in der DNS Extensions Working Group sowie Interesse von Anbietern und Käufern fest. Das ist Prozessbeleg, keine Einsatzmessung.

Unbekannt ist nicht kaputt

Die entscheidende Grenze in RFC 5625 verläuft zwischen unbekannter Semantik und einer Nachricht, die in sich ungültig ist. Ein dem Proxy unbekanntes Header-Flag soll für seine eigene Logik ignoriert, das Paket aber weitergeleitet werden. Dasselbe gilt für Labeldarstellungen, QTYPE, QCLASS sowie TYPE und CLASS von Resource Records.

Ein alter Parser darf aus der damaligen Forderung „reserviert und null“ kein dauerhaftes Verbot ableiten, nachdem ein Bit offiziell vergeben wurde. Sonst müsste jede Erweiterung auf den Austausch sämtlicher Zwischenboxen warten.

RFC 3597 formuliert das allgemeinere Erweiterungsprinzip: RDATA eines unbekannten Resource-Record-Typs wird als unstrukturierte Binärinformation behandelt, unverändert gespeichert und übertragen. Das System behauptet kein Verständnis. Es erhält die Information für eine Instanz, die sie versteht.

Ein ungültiger Kompressionszeiger oder unmögliche Abschnittszahlen sind dagegen keine Zukunftsfunktion. Solche Nachrichten dürfen verworfen werden. RFC 5625 empfiehlt dennoch, wo sicher, SERVFAIL statt Schweigen. Der Client kann abbrechen, und der Betreiber erhält einen Hinweis auf die ablehnende Schicht.

Auch eine aktive Sicherheits- oder Netzrichtlinie kann bewusst eingreifen. Sie muss jedoch als absichtliche, begrenzte Entscheidung erkennbar sein. Ein unvollständiger Parser ist keine Richtlinie, selbst wenn beide ein Paket blockieren.

Größe und Transport gehören zur Bedeutung

TC erklärt, dass eine UDP-Antwort nicht vollständig ist und über TCP erneut angefordert werden soll. Entfernt ein Proxy TC, löscht er den Wiederherstellungsweg. Kürzt er selbst ohne TC, verwandelt er fehlende Information in vermeintlichen Erfolg.

RFC 5625 untersagt die Verkürzung allein wegen der alten 512-Byte-Grenze. Erzwingt eine lokale Beschränkung dennoch Truncation, muss TC gesetzt werden; ein Upstream-TC darf nie entfernt werden. Eine deklarierte Grenze kann behandelt werden, eine unsichtbare nicht.

Der Proxy muss DNS über TCP annehmen und weiterleiten. Kommt die Anfrage bereits über TCP, soll sie auch upstream TCP bleiben, statt zunächst auf UDP herabgestuft zu werden. RFC 7766, später von Bellis und vier weiteren Autoren verfasst, machte TCP-Unterstützung für DNS-Implementierungen verpflichtend. Das stärkt die Transportregel, beweist aber keine universelle Umsetzung.

EDNS trägt Erweiterungen in einem OPT-Record. Dessen Anwesenheit darf keine Ablehnung auslösen. RFC 6891 verlangt später, dass konforme Middleboxes keine 512-Byte-UDP-Grenze erzwingen und einfache Forwarder OPT-Inhalte in keiner Richtung ändern oder löschen. Die 4096-Byte-Empfehlung von 2009 war ein damaliges Fähigkeitsziel, keine zeitlose Obergrenze.

Transparenz mit eigener Verantwortung

Ein dünner Proxy ist kein passives Kabel. Er ordnet die Antwort einem LAN-Client zu, hält Zustand, wählt einen Resolver und kann die ausgehende Query ID ändern. Er entscheidet auch, welche Schnittstelle Anfragen annimmt und welche Adresse DHCP verteilt.

RFC 5625 verweist für die Abwehr gefälschter Antworten auf RFC 5452, unter anderem auf zufällige Anfragekennungen und Quellports. Das erschwert bestimmte Fälschungen, authentifiziert die Antwort aber nicht und ersetzt DNSSEC nicht.

TSIG macht die Integritätsgrenze sichtbar. Änderungen am authentifizierten DNS-Inhalt führen, abgesehen von der genau beschriebenen Behandlung der Kennung, zum Prüfungsfehler. Der Proxy muss erhalten oder das Authentifizierungsverfahren vollständig implementieren. Teilweises Umschreiben ist nachweisbare Beschädigung.

Auch die Erreichbarkeit liegt in seiner Zuständigkeit. Ein LAN-Proxy sollte standardmäßig nicht auf der WAN-Seite lauschen, wo er zur Reflexionsfläche werden kann. RFC 5358 beschreibt den Hintergrund offener rekursiver Server als Reflektoren. Transparenz für berechtigte Clients verlangt keine öffentliche Freigabe.

Schließlich begrenzt eine Ausweichmöglichkeit die Macht des Proxys. Sofern keine ausdrückliche Richtlinie entgegensteht, sollten Clients angegebene Upstream-Resolver direkt nutzen können. Das erzwungene Abfangen aller Alternativen verwandelt Komfort in eine obligatorische semantische Kontrollstelle.

Bellis prüft nicht das Bekannte, sondern den nächsten Wert

Das IETF-Datatracker-Profil von Ray Bellis führt zehn RFCs auf, darunter RFC 5625. Die ISC-Teamseite nennt ihn heute Director of DNS Operations. Die operative Perspektive zeigt sich in einer ungewöhnlichen Abnahmefrage: Was tut das Gerät mit etwas, das noch nicht in seiner Funktionsliste steht?

Passiert ein neues Flag? Bleiben die Bytes eines unbekannten RR-Typs gleich? Erreichen TC und OPT den Client? Bleibt eine TCP-Anfrage TCP? Lassen sich eine absichtliche Richtlinie und Firmware-Unwissen durch unterschiedliche Belege trennen?

Die spätere RFC 8906 von Mark Andrews und Ray Bellis macht unerwartete Felder, Typen, EDNS-Versionen, Optionen und Flags sowie Truncation und TCP zu ausdrücklichen Testfällen. Ein alter, stiller Ausfall wird reproduzierbar.

RFC 5625 behauptet nicht, Transparenz liefere DNSSEC-Validierung, Datenschutz oder Verfügbarkeit. Sie entzieht dem Betreiber auch nicht die Upstreamwahl oder eine deklarierte Richtlinie. Sie zieht eine engere Grenze: Unwissen ist keine Zuständigkeit. Der Proxy betreibt den Weg; die Bedeutung des nächsten Bits gehört weiterhin der Spezifikation und den Endpunkten.

Quellen