Werden gültige neue TLDs 2026 noch als „ungültig“ abgelehnt?

[NiceNIC]

ICANN hat diese Woche neue Leitlinien zur Universal Acceptance veröffentlicht.

Früher lehnten manche Systeme längere, aber völlig gültige Endungen wie .versicherung oder .photography ab, weil ihre Prüfung nur kurze TLDs wie .com oder .org erwartete.

Passiert euch das 2026 noch bei Shops, Hosting-Panels, SaaS-Diensten oder anderen Websites?

ICANN-Quelle:

ITI Web ICANN

The Internet Corporation for Assigned Names and Numbers (ICANN) has published the Guidelines for Advancing Universal Acceptance (UA) Adoption, developed by the Universal Acceptance Expert Working Group.

www.icann.org

 

[Dom-Verify]

ICANN hat diese Woche neue Leitlinien zur Universal Acceptance veröffentlicht.

Früher lehnten manche Systeme längere, aber völlig gültige Endungen wie .versicherung oder .photography ab, weil ihre Prüfung nur kurze TLDs wie .com oder .org erwartete.

Passiert euch das 2026 noch bei Shops, Hosting-Panels, SaaS-Diensten oder anderen Websites?

ICANN-Quelle:

ITI Web ICANN

The Internet Corporation for Assigned Names and Numbers (ICANN) has published the Guidelines for Advancing Universal Acceptance (UA) Adoption, developed by the Universal Acceptance Expert Working Group.

www.icann.org

Ja, vereinzelt immer noch. Weniger bei großen Registraren, öfter bei älteren Shops, CRM, Formularen und manchen SaaS-Logins.

Klassiker: die TLD-Liste steckt fest im Code (nur 2–3 Zeichen oder eine alte IANA-Kopie). Dann werden .versicherung, .photography, neue Endungen von 2026 oder IDN-ccTLDs abgelehnt, obwohl die Zone existiert.

2026 ist das kein DNS-Problem, sondern ein Software-Problem: Public Suffix List oder IANA Root Zone nicht aktuell, Regex statt Lookup, E-Mail-Prüfung die nur .com und .de kennt.

Eine TLD-Prüfung muss gegen eine gepflegte Liste laufen, nicht gegen die Annahme „kurz = gültig“. Sonst markiert man harmlose neue Endungen als ungültig und übersieht den eigentlichen Missbrauch.

 

[NiceNIC]

Ja, vereinzelt immer noch. Weniger bei großen Registraren, öfter bei älteren Shops, CRM, Formularen und manchen SaaS-Logins.

Klassiker: die TLD-Liste steckt fest im Code (nur 2–3 Zeichen oder eine alte IANA-Kopie). Dann werden .versicherung, .photography, neue Endungen von 2026 oder IDN-ccTLDs abgelehnt, obwohl die Zone existiert.

2026 ist das kein DNS-Problem, sondern ein Software-Problem: Public Suffix List oder IANA Root Zone nicht aktuell, Regex statt Lookup, E-Mail-Prüfung die nur .com und .de kennt.

Eine TLD-Prüfung muss gegen eine gepflegte Liste laufen, nicht gegen die Annahme „kurz = gültig“. Sonst markiert man harmlose neue Endungen als ungültig und übersieht den eigentlichen Missbrauch.

Ja, genau sowas meinte ich. Die Domain läuft, aber irgendein Formular mag die Mailadresse plötzlich nicht.
Ist das bei IDNs deiner Erfahrung nach noch schlimmer?

 

[Dom-Verify]

Ja, genau sowas meinte ich. Die Domain läuft, aber irgendein Formular mag die Mailadresse plötzlich nicht.
Ist das bei IDNs deiner Erfahrung nach noch schlimmer?

Ja, bei IDNs ist es oft schlimmer.

Die Domain löst im Browser, aber das Formular prüft die Adresse als Text. Unicode und Punycode (xn--) werden nicht als dasselbe behandelt. Manche Felder akzeptieren nur ASCII, andere lehnen den Umlaut oder das nicht-lateinische Zeichen ab, obwohl die Mailbox existiert.

Zusätzlich: Homoglyphen. Ein Formular, das „gültig“ sagt, sagt noch nicht, dass es die richtige Domain ist.

Praktisch: die Adresse in Punycode und in Unicode testen. Wenn nur eine Variante durchgeht, liegt es am Validator, nicht am DNS.