Zusammenfassung

  • In der strikten DNS-Darstellung endet ein vollständig qualifizierter Name mit dem Punkt des Root-Labels; in der üblichen Anzeige fehlt er. Aus dieser DNS-Gleichheit folgt keine automatische Gleichheit in Anwendungspolicys.
  • Der DNSOP-Entwurf empfiehlt Speicherung und Anzeige ohne Schlusspunkt und warnt vor allgemeiner String-Verarbeitung. Im Last Call wurde eine ausführbare Regel für den Vergleich beider Formen verlangt.
  • CVE-2026-8924 liefert begrenzte Running-Code-Evidenz: Eine abweichende Punktbehandlung ließ in curl eine Public-Suffix-Prüfung für Cookies passieren. Entscheidend war die Reihenfolge der Normalisierung.

Der Punkt hinter uk ist das sichtbare Trennzeichen zum leeren Root-Label. RFC 9499 unterscheidet die strikte Darstellungsform, die es enthält, von der gebräuchlichen Anzeige, in der es optional ist. Ein Resolver kann deshalb beide Zeichenfolgen demselben DNS-Knoten zuordnen. Cookie-Speicher, Zertifikatsprüfung, Cache und Kontodatenbank übernehmen diese Äquivalenz nicht automatisch.

Genau diese Naht liegt in einem laufenden Standardisierungsverfahren. DNSOP setzte draft-ietf-dnsop-integration-04 am 24. August in den Working Group Last Call; er endet am 7. September. Der Entwurf strebt den Status Informational an. Er ist weder RFC noch Beleg für WG-Konsens. Sein Gegenstand ist die verantwortliche Verwendung globaler DNS-Namen als Kennungen in Anwendungen.

Die Checkliste reicht vom Domain-Lebenszyklus über Kontrollvalidierung, Vollständigkeit und Synchronisation bis zu Protokollentwicklung, Bedienoberflächen und Record-Type-Unterstützung. Abschnitt 3.3 koppelt zwei Aussagen: Vollständig qualifizierte Namen sollen gewöhnlich ohne letzten Punkt gespeichert und angezeigt werden, außer lokale Suchdomänen werden benötigt. Zugleich dürfen Anzeige, Normalisierung, Vergleich, Kodierung und Dekodierung nicht auf generische String-Operationen reduziert werden.

Damit ist die Gefahr benannt, aber noch nicht jede Reihenfolge prüfbar festgelegt. Paul Wouters erhob keinen formalen Einwand gegen die Veröffentlichung, vermisste jedoch konkrete technische Hinweise. Er nannte Vergleiche mit und ohne Schlusspunkt, DNS-Groß-/Kleinschreibung, A-label/U-label, negative Caches, verwaiste Aliase und die Bewahrung des ursprünglichen QNAME über CNAME/DNAME hinweg. Wes Hardaker unterstützte die Veröffentlichung, sah aber eher Zukunftskontext als sofortige Hilfe. Tim Wicinski befürwortete das Weitergehen ebenfalls und ordnete Teile des dritten Abschnitts nahe bei Betriebsfragen ein.

Das sind einzelne Stellungnahmen, kein WG-Beschluss.

CVE-2026-8924 zeigt, warum die Reihenfolge in den Vertrag gehört. curl veröffentlichte den offiziellen Hinweis am 24. Juni 2026, bewertete den Fehler als niedrig, nannte die Versionen 7.46.0 bis 8.20.0 als betroffen und 8.21.0 als korrigiert. Verarbeitete curl einen URL-Host wie example.co.uk., konnte ein Server ein Cookie für co.uk. setzen. Die Public Suffix List hielt diese zu breite Domain nicht wie vorgesehen zurück; das Cookie konnte später an fremde Domains gehen.

Das DNS musste dafür keine zwei Ziele liefern. Die Policy prüfte eine Darstellung, die nicht zur erwarteten Form ihrer Suffixdaten passte. curl weist außerdem darauf hin, dass ein Schlusspunkt nicht im TLS SNI übertragen werden kann. Eine Eingabe konnte somit in DNS, Cookie-Logik und TLS unterschiedliche Textformen annehmen. CVE-2022-30115 dokumentierte zuvor eine getrennte HSTS-Abweichung an derselben Darstellungsnaht. Das beweist keinen universellen Fehler, wohl aber einen wiederkehrenden Integrationsrand.

Großschreibung und internationalisierte Namen erweitern ihn. RFC 4343 verlangt für gewöhnliche ASCII-DNS-Labels einen fallunabhängigen Vergleich, warnt aber, dass derselbe Name außerhalb des DNS als fallsensitiver Datenbankindex oder Authentisierungseingang dienen kann. RFC 5890 trennt Unicode-U-label und ASCII-kompatibles A-label; die Schlusspunktkonvention liegt ausdrücklich außerhalb seines Gegenstands. Kleinschreibung plus Zeichenentfernung ist daher kein universeller Identitätsalgorithmus.

Eine prüfbare Integration bewahrt mehrere Belege: Roheingabe, explizites Root-Label und erlaubte lokale Suche; analysierte Label-Folge und absoluter oder relativer Status; kanonische Form für die konkrete Entscheidung; Version der Public Suffix List, des IDNA-Profils oder der Zertifikatsregel; Entscheidung und beobachtete Wirkung. Wird nur die bereinigte Zeichenfolge protokolliert, verschwindet gerade die Abweichung, die erklärt werden müsste.

Die Trennung begrenzt zugleich die Aussagekraft. DNS-Gleichheit belegt keine Registrantenkontrolle. Eine Domain-Control-Prüfung zertifiziert nicht jeden Dienst. Ein Zertifikat autorisiert nicht jede Aktion. Ein akzeptiertes Cookie belegt weder den beabsichtigten Empfänger noch das Ergebnis.

Der Last Call hinterlässt deshalb keine Geschmacksfrage zum Punkt. Er hinterlässt eine Zuständigkeitsfrage: Wer definiert die kanonische Form, welche Policy verbraucht sie, und geschieht die Umwandlung vor deren Entscheidung? Normalisiert ein System erst nach Suffix-, Origin- oder Berechtigungsprüfung, ist nur das Protokoll sauber. Die Vertrauensgrenze war bereits verschoben.

Quellen