No. There would no factual reason to do so either, since mueller.de and müller.de are two completely different domains. It is just like bauer.de, which has nothing to do with baür.de, or poet.de and pöt.de, which are not the same either. Why then should the holder of mueller.de be given any precedence over Germany’s myriad of other Müllers? Such a procedure would go against the clear principle that DENIC has established that a domain goes to whoever applies to register it first – i.e. first come, first served, with no exceptions.

In this context, we should like to remind you of the clear rule that it is domain applicants themselves who are responsible for ensuring that they do not infringe any rights of others and that they expressly confirm this in applying to register a domain. You’ll find more details about this in DENIC’s Domain Guidelines and in its Domain Terms and Conditions.

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.

Wir haben eine Liste uns bekannter IDN-fähiger Programme für Sie zusammengestellt.

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. 

Wir haben eine Liste mit uns bekannten IDN-fähigen Programmen für Sie zusammengestellt.

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.

No. There would no factual reason to do so either, since mueller.de and müller.de are two completely different domains. It is just like bauer.de, which has nothing to do with baür.de, or poet.de and pöt.de, which are not the same either. Why then should the holder of mueller.de be given any precedence over Germany’s myriad of other Müllers? Such a procedure would go against the clear principle that DENIC has established that a domain goes to whoever applies to register it first – i.e. first come, first served, with no exceptions.

In this context, we should like to remind you of the clear rule that it is domain applicants themselves who are responsible for ensuring that they do not infringe any rights of others and that they expressly confirm this in applying to register a domain. You’ll find more details about this in DENIC’s Domain Guidelines and in its Domain Terms and Conditions.

If a domain with the letter "ß" in its name is resolved correctly, for instance by a web browser, depends on the fact if the web browser that is used supports the new IDN standard that has come into effect in August 2010.

As long as there are some vendors who have not yet updated their browsers and/or users who apply older browser versions which still automatically convert the "ß" into "ss", failures may occur. Such browsers will resolve the entry "straße.de" to the domain "strasse.de".

We have set up a list of IDN capable software for you.

All ß-domains can be used immediately after registration. They are covered by the output of the DENIC information services in realtime.

Please note our information on how some web browsers treat domains containing the letter "ß".

Yes, you may also register an ß-domain with DENICdirect.

Since November 2010 the letter "ß" is incorporated as a valid character in the Annex of the DENIC Domain Guidelines. Consequently, anybody can register ß-domains in accordance with the standard registration procedure.

Like all other domains, you can query ß-domains via DENIC's regular information services.

You can use the domain query service (web-whois) on DENIC's website or the command-line-based public-whois for this purpose.

Besides the ASCII characters (the 26 Latin letters, the ten numerals and the hyphen) you may use some other characters for IDNs under .de. These include the German umlauts ä, ö and ü as well as the letter eszett ("ß") and letters with accents and other diacritics. We have compiled a list with the new additional characters valid for IDNs under .de in a table for you.

You might wonder why these particular 93 characters have been chosen and not others. There are several reasons:

• DENIC supports all characters included in the Unicode Latin-1 Supplement and Latin Extended-A blocks which are marked as "PROTOCOL VALID" in the RFC 5892 (The Unicode Code Points and Internationalized Domain Names for Applications).
• DENIC is an open registry free from any form of discrimination. In Germany, there is no meaningful way of drawing a line between the various character sets, since the written German language now includes characters that originated in the languages of the northern, southern and eastern parts of Europe. The sensible and appropriate solution for us therefore seemed to be to adopt two blocks that cover the necessary European character set for those languages that are based on the Latin alphabet, including some additional characters.
• The most frequently used new characters of these character sets can be entered via standard German keyboards without requiring any additional equipment or outlay.

Yes. Just call the table DENIC has compiled for you. It contains a list of all the admissible characters, plus their corresponding numbers (in both decimal and hexadecimal) in the Unicode table, along with their official designations in both English and German. This table can also be used by your computer’s copy function. Simply mark a letter in the table and then paste it either to your browser or DENIC's whois search.

A .de domain must consist of at least one character, but its maximum length must not exceed 63 characters. In the case of IDNs, the question immediately arises as to whether these length constraints refer to the IDN itself (such as straße.de) or its transposition as an ASCII character string (xn--strae-oqa.de).

For technical reasons, the maximum length of 63 characters applies to the ASCII character string, whereas the minimum length of three characters applies to the IDN.

No. These entries are loaded directly into the name server and are not transposed first. The situation for host names for name servers and NS entries remains precisely what it has been so far: the only permitted designations are those that are comprised solely of the basic ASCII character set. It is thus possible to enter the punycode value (such as dns.xn--strae-oqa.de) as the host name in the name-server entries but not the corresponding IDN (such as dns.straße.de).

This arrangement has one big advantage in that hosts with Japanese, Chinese, Cyrillic, etc. names can also act as name servers too and there are no limitations to a particular character set. It is true that such host names cannot be registered under .de, but other registries are free to choose what letters and other characters they want to permit and, of course, their decisions are guided by the needs of the internet users they cater for.

Computers can only work with numbers. So letters of the alphabet and other characters have to be assigned to numbers before computers can process and store them. Before Unicode was developed there used to be hundreds of different coding systems, and not one of them was complete. Even just concentrating on one language (such as German) there was not a single system that really contained all the letters of the alphabet, punctuation marks and technical symbols in common use. The situation was rendered even more unsatisfactory in that it was not possible to use these various coding system side-by-side at the same time, since the various numbers were assigned to different characters. All this changed with the advent of Unicode, which now ensures unique assignments of characters to numbers, no matter what hardware and software is used. Texts that use Unicode can be exchanged throughout the world without problems or loss of information.

The original definition of Unicode and its further development is in the hands of the Unicode-Consortium, a non-profit body, whose purpose is to normalize and standardize the representation of text data in the computer field. The consortium's members include many companies and institutions from the IT sector.

Punycode is a rule that describes how Unicode characters are assigned uniquely to ASCII character strings. You will find a technical definition of this rule in RFC3492 (Punycode: A Bootstring Encoding of Unicode for Internationalized Domain Names in Applications).

In an extremely simplified form, the following is what happens in this transposition:

The previously normalized IDN has the prefix "xn--" placed in front of it. All non-ASCII characters are taken out. The punycode algorithm determines what these characters were and where they stood and adds this coded information to the end of the string that is left. To give an example: "zääz.de" is encoded as "xn--zz-viaa.de".