Das Domain Name System (DNS) behandelt ASCII-Zeichen ohne eine Unterscheidung zwischen Groß- und Kleinschreibung (vgl. RFC 4343).

Bei dem auf Anwendungsebene vorgeschalteten IDNA-Standard existiert jedoch keine verallgemeinerte Äquivalenz zwischen Groß- und Kleinschreibung von Nicht-ASCII-Zeichen. Ferner werden als U-Label nur Unicodezeichen in Normalisierungsform C akzeptiert und z. B. gar keine Großbuchstaben. Es ist aber im Standard vorgesehen, dass nach einer Benutzereingabe ein optionaler Schritt mit einer „Normalisierung“ stattfindet, die die lokalspezifischen Einstellungen des Benutzers (z.B. Regions- und Sprachoptionen) berücksichtigt und dabei z. B. eine Abbildung von Groß- auf Kleinbuchstaben vornimmt.

Im RFC 5895 ist ein solcher Schritt der Normalisierung beschrieben; der Unicode Technical Standard #46 (http://unicode.org/report/tr46/) stellt aus Sicht des Unicode Consortiums eine Alternative dar.

Zwecks Rückwärtskompatibilität mit gängigen Internetprotokollen müssen IDNA-fähige Anwendungen im Hintergrund dafür sorgen, dass IDNs vor ihrem Einsatz im DNS in eine ASCII-Zeichenkette umgewandelt werden.

Dazu wird die native Form oder das U-Label (U = Unicode) eines IDNs mit Hilfe des sogenannten Punycode-Algorithmus in eine ASCII-Zeichenkette umgewandelt: den ACE (=ASCII Compatible Encoding)-String bzw. A-Label (A = ASCII). Zur Kennzeichnung wird dieser Zeichenfolge das ACE-Präfix "xn--" vorangestellt. Der Punycode-Algorithmus kodiert, welche Nicht-ASCII-Zeichen vorkommen und an welcher Stelle im U-Label sie stehen. Die ASCII-Zeichenkette (A-Label) für eine IDN besteht demnach aus dem ACE-Präfix, gefolgt von allen klassischen ASCII-Bestandteilen der Domain sowie dem Code zur Darstellung aller Nicht-ASCII-Zeichen.

DENIC bietet ein Konvertierungstool an, mit dem sich zu jedem IDN der dazugehörige ACE-String ermitteln lässt. 

IDN steht für „Internationalized Domain Name“ und bezeichnet Domains, die neben den üblichen ASCII-Zeichen auch Schriftzeichen aus Nicht-ASCII-Zeichensätzen enthalten. Hierzu gehören etwa Domains mit den deutschen Umlauten ä, ö und ü und anderen Buchstaben mit diakritischen Zeichen wie Akzenten (é, à …), Cedillen (ç), Tilden (ñ), Hatscheks (č)  etc.

Bis zum Jahr 2003 konnten Domains nur aus bestimmten ASCII-Zeichen (a-z, 0-9, Bindestrich) bestehen, da die gängigen Internetprotokolle lediglich diesen Zeichensatz unterstützen. Insbesondere aus Ländern, die nicht das lateinische Alphabet nutzen, bestand damals eine intensive Bestrebung, den möglichen Zeichensatz um andere, schriftsystemspezifische Schriftzeichen zu erweitern. 2003 hat die Internet Engineering Task Force (IETF) mit RFC 3490 ("Internationalizing Domain Names in Applications“) und ff. den sogenannten IDNA-Standard veröffentlicht, der u.A. die Verwendung bestimmter Umlaute und diakritischer Zeichen ermöglicht. Dieser Standard wurde im August 2010 aktualisiert (RFC 5890 bis 5894).

Der Standard geht davon aus, dass jedes in einer Domain enthaltene Nicht-ASCII-Zeichen nach der im Standard beschriebenen Vorschrift in eine ASCII-Zeichenkette kodiert wird.

Hintergründe und nähere Angaben zur technischen Realisierung finden Sie in unserer FAQ "Wie funktionieren IDNs aus technischer Sicht?".

Wie alle anderen Domains lassen sich auch "ß"-Domains über die regulären DENIC-Auskunftsdienste abfragen.

Dazu stehen die Domainabfrage (web-whois) auf den DENIC-Webseiten sowie der kommandozeilen-basierte Public-whois zur Verfügung.

Das Registrierungsverfahren für „ß“-Domains unterscheidet sich nicht von dem anderer Domains.

Interessenten an einer „ß“-Domain wenden sich an einen Provider, der für sie das Verfahren abwickelt. Dabei ist der Provider frei wählbar.

Die korrekte Auflösung einer Domain, die ein "ß" enthält, beispielsweise durch einen Webbrowser hängt davon ab, ob der verwendete Webbrowser den seit August 2010 geltenden IDN-Standard unterstützt.

Solange nicht sämtliche Hersteller ihre Browser entsprechend angepasst haben und/oder Nutzer weiterhin ältere Browserversionen verwenden, die nach wie vor das "ß" automatisch in "ss" umwandeln, kann es zu Fehlfunktionen kommen; denn ältere Browserversionen lösen etwa bei Eingabe von "straße.de" die Domain "strasse.de" auf.

Das A-Label (also die in ASCII-Zeichen kodierte Form einer Domain) bleibt dem Benutzer in der Regel verborgen, da es nur zur technischen Realisierung dient. Überall dort, wo Benutzer Domains mit Nicht-ASCII-Zeichen eingeben, müssen alle relevanten Anwendungen wie Webbrowser, E-Mail-Programme etc. daher intern eine Übersetzung durchführen.

Die seit 2003 laut Internetstandard erlaubten Zeichen werden inzwischen durch die meisten Anwendungen unterstützt. Anders verhält es sich mit dem „ß“, das erst mit der Überarbeitung des IDN-Standards 2010 als eigenständiges Zeichen zugelassen und davor in das als äquivalent definierte „ss“ umgewandelt (normalisiert) wurde. Da viele Browser und E-Mail-Programme das „ß“ in einer  Übergangszeit noch nicht unterstützen, sondern weiterhin in „ss“ umwandeln werden, kann es hier noch zu unerwünschten Effekten kommen: Ein Benutzer, der die Domain „straße.de“ in seinen Browser eingibt, wird während dieses Zeitraums je nach verwendeter Software korrekterweise auf die unter „straße.de“ hinterlegten Inhalte gelangen (bei standardkonformen Browsern) oder fälschlicherweise auf die unter „strasse.de“ hinterlegten Inhalte (bei noch nicht standardkonformen Browsern).

Auch Nutzer, die ihren Browser und E-Mail-Client IDN-fähig gemacht haben, dürfen nicht selbstverständlich davon ausgehen, dass andere Internetnutzer ihre IDN-basierte Website aufrufen oder ihnen eine E-Mail an eine IDN-Adresse zusenden können. In einem solchen Fall käme als Notlösung infrage, den entsprechenden ACE-String des IDN zu verwenden, also etwa statt info@straße.de die Codierung info@xn--strae-oqa.de einzugeben. 

Vertragsgegenstand zwischen DENIC und dem Domaininhaber ist das U-Label einer IDN. In allen offiziellen Dokumenten und Formularen muss die Angabe von Domain daher mit der nativen (nicht Punycode-kodierte) Zeichenkette, umgewandelt in Kleinbuchstaben, erfolgen.

Beispiel: straße.de (und nicht xn--strae-oqa.de)

Wie Domains, die ausschließlich aus ASCII-Zeichen bestehen, können auch Internationalisierte Domains (IDNs) dazu eingesetzt werden, um Nutzer auf eine Webseite zu locken, deren Domain zwar dem ersten Anschein nach einem bekannten Original entspricht, dieses jedoch nur imitiert und allein zu Imitationszwecken registriert wurde. Ziel solcher Betrugsversuche – auch “Phishing“ genannt -  ist es, vertrauliche Informationen wie Passwörter etc. auszuspähen.

Das Risiko, Ziel eines solchen Betrugsversuchs zu werden, ist für IDNs nicht größer als für Domains, die ausschließlich aus ASCII-Zeichen bestehen. Häufiges Vorgehen ist beispielsweise der Ersatz von "o" durch "0", "1" durch kleines "l" oder kleines "l" durch großes "i".

Die Existenz von identischen Glyphen (Zeichendarstellungen) in unterschiedlichen Schriften (lateinisch, kyrillisch, griechisch usw.) war den Entwicklern des IDN-Standards durchaus bewusst und ist in RFC 4690 explizit erwähnt. Um die eindeutige Identifikation von Zeichen zu erleichtern und den unerkannten Austausch zu erschweren, hat DENIC lediglich die Nutzung lateinischer Buchstaben realisiert. Es gibt daher unter den für .de-Domains gültigen Zeichen keine Paare, die vollkommen identisch aussehen, sondern allenfalls ähnlich.

Es gibt eine Reihe von Möglichkeiten, um sich vor Phishing-Attacken zu schützen. Ohne Anspruch auf Vollständigkeit haben wir die wichtigsten hier zusammengefasst:

• Geben Sie vertrauliche Informationen nur über verschlüsselte Verbindungen einem identifizierten, vertrauenswürdigen Partner preis.
• Seien Sie misstrauisch, wenn Sie per E-Mail, in Blogs etc. unter "dringenden" Umständen auf Seiten gebeten werden, mit denen Sie geschäftlichen Kontakt haben (E-Banking etc).
• Folgen Sie etablierten Bookmarks statt Links in E-Mails. Benutzen Sie idealerweise keine HTML-codierten Mails.
• Nehmen Sie Warnmeldungen bzgl. unsicherer, unbekannter oder veränderter Zertifikate ernst.

IDNs für .de stellen eine sinnvolle Bereicherung dar und tragen durch die Aufnahme sprachspezifischer Schriftzeichen der Funktion von .de als länderspezifischer Top Level Domain Rechnung. Der Vorteil überwiegt deutlich die potenziellen Sicherheitsrisiken, die auch unabhängig von IDNs bestehen blieben.

IDNs können über die Domainabfrage auf DENICs öffentlichen Webseiten abgefragt werden. Eine Abfrage auf das A-Label ist auf diesem Weg aber nicht möglich.

Für weitere Optionen der Abfrage nutzen Sie bitte den command-line basierten Public-whois oder die RRI Kommandos CHECK und INFO.

Der DENIC whois-Service auf Port 43 erfolgt in vollständiger Übereinstimmung mit den Vorgaben in RFC 3912. Um auch alle Informationen unserer internationalisierten Datenbank (z. B. Kontaktdaten oder von IDNs) korrekt darstellen zu können, werden alle Zeichen, die nicht zum ASCII-Satz gehören, standardmäßig in UTF-8-Codierung ausgegeben. Der Hauptgrund für die Wahl von UTF-8 liegt in seiner Rückwärtskompatibilität zu ASCII. Zudem ist es die empfohlene Codierung für IETF-Protokolle laut RFC 2277. Unicode, UTF-8 und seine weiteren Transformationsformate werden von moderner Software und Betriebssystemen auf breiter Front unterstützt.

Es ist richtig, dass das whois-Protokoll im Grundsatz keinerlei Unterstützung für Internationalisierung bietet. DENIC hat einige proprietäre Ergänzungen dieses Protokolls implementiert. Diese erlauben den existierenden whois-Clients, denjenigen Zeichensatz anzugeben, der bei den Anfragen und Antworten genutzt werden soll (mögliche Codierungen neben US-ASCII sind der vor allem in West-Europa sehr populäre ISO-8859-1 - auch bekannt als Latin-1 - sowie UTF-8). Die Nutzung dieser Erweiterungen ist aber nicht verpflichtend.

Zusätzlich zu den ASCII-Zeichen (den 26 lateinischen Buchstaben, den zehn Ziffern und dem Bindestrich) können mit IDNs unter .de weitere Zeichen verwendet werden. Dazu gehören u. a. die Umlaute ä, ö und ü sowie das Eszett und Buchstaben mit Akzenten und anderen diakritischen Zeichen. Eine Liste mit den aktuell unter .de gültigen IDNs haben wir in einer Tabelle für Sie zusammen gestellt.

Hintergründe der Auswahl dieser 93 Zeichen sind u. a. :

• DENIC unterstützt alle Zeichen aus den Unicode-Blöcken "Latin-1 Supplement" und "Latin Extended-A", die im RFC 5892 (The Unicode Code Points and Internationalized Domain Names for Applications) als "PROTOCOL VALID" markiert sind.
• DENIC ist eine diskriminierungsfreie und offene Registrierungsstelle. Es gibt in Deutschland keine sinnvolle Abgrenzung bezüglich der Auswahl der verschiedenen Schriftzeichen, da Buchstaben sowohl nord- als auch süd- und osteuropäischer Sprachen Eingang in die deutsche Schriftsprache gefunden haben. Daher ist die Wahl zweier Zeichenblöcke, die die meisten lateinischen Basisbuchstaben des europäischen Sprachraums mit ergänzenden Schriftzeichen abdecken, vernünftig und angemessen.
• Die am häufigsten vorkommenden Zeichen dieser Zeichensätze können mit den in Deutschland erhältlichen, handelsüblichen Tastaturen ohne besonderen Aufwand eingegeben werden.

Eine Domain muss aus mindestens einem und kann aus maximal 63 Zeichen bestehen. Bei IDNs ergibt sich die Frage, ob sich diese Länge auf den IDN (straße.de) oder die ASCII-Zeichenkette (xn--strae-oqa.de) bezieht.

Die maximale Zeichenlänge ist aus technischen Gründen auf 63 Zeichen der ASCII-Zeichenkette beschränkt. Die minimale Zeichenlänge bezieht sich demgegenüber auf den IDN.

Nein, denn diese Einträge werden direkt in den Nameserver übernommen, es findet keine Konvertierung statt. Es sind als Hostnamen für Nameserver und NSentry-Einträge weiterhin nur Bezeichnungen zulässig, die aus den bisherigen erlaubten ASCII-Zeichen bestehen. Es kann also z. B. die Punycode-Kodierung dns.xn--strae-oqa.de als Hostname in Nameserver-Einträgen verwendet werden, nicht aber der dazugehörige IDN dns.straße.de.

Diese Regelung hat den Vorteil, dass damit auch beliebige japanische, chinesische und kyrillische Hostnamen als Nameserver möglich sind und es keine Beschränkungen auf einen Zeichensatz gibt. Zwar können solche Hostnamen nicht unterhalb von .de registriert werden, andere Registrierungsstellen sind aber frei in der Wahl der Buchstaben und Zeichen, die sie zulassen, und richten sich dabei natürlich nach den Bedürfnissen der dortigen Internetnutzer.

Grundsätzlich arbeiten Computer nur mit Zahlen. Buchstaben und andere Zeichen werden daher Zahlen zugeordnet, um sie zu speichern und zu verarbeiten. Vor der Entwicklung von Unicode existierten hunderte unterschiedlicher Kodierungssysteme, die alle nicht vollständig waren. Nicht einmal für eine einzelne Sprache (wie z. B. Deutsch) gab es ein System, das wirklich alle Buchstaben, Interpunktionszeichen und alle technisch gebräuchlichen Zeichen umfasste. Zudem konnten diese verschiedenen Kodierungssysteme nicht gleichzeitig nebeneinander benutzt werden, da gleiche Zahlen unterschiedlichen Zeichen zugeordnet waren.

Dies änderte sich durch Unicode, das jedem Zeichen eindeutig eine Zahl zuordnet, unabhängig von der verwendeten Hard- und Software. Texte können mit Unicode weltweit ohne Informationsverluste und Probleme ausgetauscht werden.

Definiert und weiterentwickelt wird Unicode vom Unicode-Konsortium, einer gemeinnützigen Organisation mit dem Ziel, die Darstellung von Textdaten im Computerbereich zu normieren und zu standardisieren. Mitglieder dieses Konsortiums sind viele Firmen und Institutionen aus dem IT-Bereich.

Punycode ist eine Vorschrift, die in eindeutiger Weise eine Zuordnung von Unicode-Zeichen zu ASCII-Zeichenketten beschreibt. Eine technische Definition dieser Vorschrift gibt das RFC 3492.

Sehr vereinfacht dargestellt passiert bei dieser Umsetzung folgendes:

Alle Nicht-ASCII-Zeichen werden weggelassen. Welche Zeichen dies waren und an welcher Position im IDN sie standen, wird dann vom Punycode-Algorithmus ermittelt und an den übriggebliebenen String angehängt.