Leuffen.deBlog

Magazin

Warum manche Domainnamen mit `xn--` beginnen

IDNA kennt für internationalisierte Domainlabels eine lesbare Unicode-Form und eine ASCII-kompatible A-Label-Form. Das Präfix `xn--` gehört zur technischen Darstellung, ist aber allein weder Gültigkeits- noch Sicherheitsbeweis.

Veröffentlicht am
Veröffentlicht von
Redaktion Blog Leuffen.de
Geprüft von
Clara Winter, Inhalt und Struktur, Redaktion und Recherche, Eindeutigkeitsprüfung

xn-- ist kein geheimer Browsercode und kein Warnstempel. Das Präfix ist für die ASCII-kompatible Form eines gültigen IDNA-A-Labels vorgesehen. Die vier Zeichen allein beweisen allerdings noch nicht, dass die gesamte Zeichenfolge nach den IDNA-Regeln gültig ist.

Internationalisierte Domainnamen, kurz IDNs, erlauben Zeichen etwa mit diakritischen Zeichen oder aus nichtlateinischen Schriften. Für ihre Nutzung in der bestehenden DNS- und Hostnamen-Infrastruktur definiert IDNA – Internationalized Domain Names for Applications – eine ASCII-kompatible A-Label-Form. Die zugehörige gültige Unicode-Darstellung heißt U-Label.

Punycode ist ein Baustein dieses Verfahrens. Der in RFC 3492 beschriebene Algorithmus bildet Unicode-Zeichenfolgen umkehrbar auf eine begrenzte ASCII-Zeichenmenge ab. IDNA prüft jedoch zusätzlich, welche Zeichenfolge zulässig ist und wie sie verarbeitet wird. Ein beliebiges „Unicode hinein, Punycode hinaus“ erzeugt daher noch kein gültiges A-Label.

Diese Unterscheidung erklärt, warum ein Browser einen lesbaren Namen anzeigen kann, während Zertifikatsansicht, Logdatei oder Debugger eine Zeichenfolge mit xn-- ausgeben. U-Label und A-Label beschreiben nur dann dasselbe IDNA-Label, wenn eine standardkonforme Umwandlung dies bestätigt.

Praktisch: beide Darstellungen nachvollziehbar halten

Diagnosewerkzeuge sollten die validierte U-Label-Darstellung und die standardkonform erzeugte A-Label-Form gemeinsam anzeigen oder kontrolliert ineinander überführen. Für Vergleichs- und Sperrlogik empfiehlt sich eine etablierte, gepflegte IDNA-Bibliothek. Eine selbst gewählte Unicode-Normalisierung oder eine bloße Punycode-Konvertierung ersetzt die IDNA-Prüfung nicht.

Für Logs kann es sinnvoll sein, die Originaleingabe zusätzlich zu den validierten Formen zu erhalten. Dann bleibt nachvollziehbar, was ein System empfangen hat und welches kanonische Label daraus erzeugt wurde. Datenschutz- und Aufbewahrungsregeln gelten dabei wie bei anderen Protokolldaten.

Ähnlich aussehende Zeichen bleiben ein eigenes Sicherheitsproblem. Das Präfix xn-- ist weder Beweis für einen Angriff noch Entwarnung. Gemeinsame Anzeige und saubere Protokollierung erleichtern die Prüfung, ersetzen aber keine Registry-, Browser- oder anwendungsspezifische Abwehr gegen irreführende Namen.

RFC 3492 beschreibt den Punycode-Algorithmus. RFC 5890 definiert unter anderem A-Label, U-Label und das ACE-Präfix; RFC 5891 beschreibt das IDNA2008-Protokoll. Für den Betrieb heißt das: Menschen brauchen die lesbare Form, Diagnose und Vergleich die standardkonform erzeugte technische Form – und beide brauchen eine echte IDNA-Validierung.

Quellen

Quellenstand: 21. September 2026.