Zusammenfassung

  • next-hop-aliases übermittelt Alias- und kanonische Namen, die ein Proxy bei der DNS-Auflösung des nächsten Hops empfangen hat.
  • Eine Implementierung darf eine unvollständige Kette liefern; auch leere oder fehlende Angaben sind möglich und enthalten keinen DNSSEC-Nachweis.
  • Erst die Verbindung von Proxy-Herkunft, DNS-Material, Validierung, Endpunktauthentisierung, lokaler Richtlinie und Wirkung trägt eine Entscheidung.

Ein Resolver-API lieferte nur den letzten Namen. Der Proxy serialisierte ihn korrekt, der Client zeigte ihn korrekt an – und trotzdem fehlte der größte Teil der Kette. Genau diese Art von korrekter Unvollständigkeit begrenzt die Aussagekraft von RFC 9532.

Der RFC 9532 definiert next-hop-aliases für das HTTP-Feld Proxy-Status. Ein Vermittler kann damit CNAME-Aliase und kanonische Namen offenlegen, die er beim Auflösen des nächsten Hops erhielt. Das hilft Clients, die DNS-Arbeit an einen Forward Proxy abgegeben haben. Es kann auch CNAME-Cloaking sichtbar machen, bei dem Tracker oder schädliche Ziele hinter einem vertraut wirkenden Namen liegen.

Der Parameter beschreibt jedoch eine Beobachtung. Er beglaubigt nicht die Ressource.

Vollständigkeit hängt vom Resolver-Werkzeug ab

RFC 9532 weist auf eine alltägliche Grenze hin: getaddrinfo kann über AI_CANONNAME den letzten kanonischen Namen liefern, ohne die vorangehenden Aliase zugänglich zu machen. Die Spezifikation erlaubt deshalb ausdrücklich unvollständige Informationen.

Ein syntaktisch einwandfreier Wert kann nur den Schlusspunkt einer längeren Auflösung enthalten.

Fehlend, leer, gefüllt und ungültig müssen getrennt bleiben. Fehlend kann nicht unterstützt, nicht anwendbar, entfernt oder schlicht nicht gesendet bedeuten. Leer heißt nur, dass der meldende Proxy in dieser Auflösung keine CNAMEs angetroffen habe. Gefüllt ist die vom Proxy berichtete Teilmenge. Ungültig darf nicht zu einer bequem korrigierten Liste werden.

Cache, Split DNS, Resolver-Richtlinie und Zeitpunkt können andere Sichtweisen erzeugen. Rekursive oder autoritative Resolver können CNAMEs auslassen. Ein böswilliger Proxy kann sie verschweigen. Schweigen ist daher kein Nachweis einer direkten Namensbeziehung.

Zwei Grammatiken schützen die Namensgrenzen

Der äußere Wert ist ein Structured-Fields-String nach RFC 8941. Im Inneren stehen durch Kommas getrennte DNS-Namen. Aliase sollen in Empfangsreihenfolge erscheinen, vom ersten CNAME bis zum Namen, der Adressen ergab.

Ein Komma im Namen muss percent-encoded werden. Ein Punkt innerhalb eines Labels wird zunächst mit Backslash escaped; der Backslash wird anschließend codiert. Ein wörtlicher Backslash braucht eine weitere Unterscheidung. Wer HTTP-Parsing, Percent-Decoding und DNS-Label-Rekonstruktion in falscher Reihenfolge ausführt, kann einen anderen Namen erhalten.

Ein Audit bewahrt daher Originalbytes, Zwischenergebnisse, Parser-Version und die rekonstruierten Labels. Die fertige Anzeige allein beweist nicht, dass beide Enden dieselbe Zeichenfolge verstanden.

Keine DNSSEC-Aussage im Feld

RFC 9532 stellt klar, dass der Parameter keine DNSSEC-Information enthält und DNSSEC-Nutzung nicht impliziert. Er ist ein Hinweis und soll nicht die Identität der Ressource bestimmen. Seine Vertrauenswürdigkeit reicht nur so weit wie das Vertrauen in Proxy und Resolver.

RFC 4033 und RFC 4035 definieren einen anderen Nachweis: Ursprung und Integrität von DNS-Daten, Vertrauenskette und authentisierte Nichtexistenz. Signaturen und Validierungsergebnis reisen nicht in next-hop-aliases mit.

Auch separat validiertes DNS entscheidet nicht automatisch über TLS-Schlüssel, HTTP-Authority, Kontoinhaber, Cookie-Berechtigung oder Datenfreigabe. Jede Schicht braucht ihren eigenen Besitzer und ihre eigene Evidenz.

Proxy-Status benennt den Zeugen

RFC 9209 lässt Vermittler erläutern, wie sie eine Anfrage behandelt haben. Deshalb muss die Aufzeichnung zuerst den Zeugen benennen: Proxy-Identität, Vertrauensbeziehung, Version und Position in der Kette.

Danach folgen Resolver, Cache, Validierungsmodus und Konfigurationsepoche; DNS-Frage, Antwort, CNAMEs, finaler Name, Adressen und TTLs; separat erfasstes DNSSEC-Material; Kodierung und Offenlegung; Verbindung, Authentisierung, lokale Entscheidung und Ergebnis.

Heng Lus Trennung der Realitätsschichten verhindert die Abkürzung. Ein Name ist keine Antwort. Die Antwort ist nicht die Aussage des Proxys. Die Aussage ist keine Validierung. Validierung ist keine Autorisierung. Running Code muss jeden Übergang sichtbar machen.

Ein schmales gemeinsames Format genügt

Der Standard koordiniert die Offenlegung, nicht die endgültige Sicherheitsrichtlinie. Ein Client kann eine Alias-Änderung als Anlass für zusätzliche Prüfung, vorsichtigere Cookie-Behandlung oder Incident-Analyse nutzen. Er behält die lokale Entscheidung und kann sie revidieren.

Die IANA-Registrierung beweist weder Implementierung noch korrekte Nutzung. Die Quellen liefern keine Adoptionszahlen, keine Aussagen über konkrete Browser und keine gemessene Häufigkeit von Cloaking. Die Beispiele sind Protokollerklärungen.

RFC 9532 wird gerade dadurch belastbar, dass es keine fremde Autorität beansprucht: Der Proxy darf sagen, was er sah. Wer die Ressource ist und welche Handlung zulässig ist, bleibt eine getrennte Beweisfrage.

Quellen