Index
Internet Engineering Task Force – IETF
Aktueller
Stand der Standardisierung
Internationalisierung
der DNS in der Praxis
Allgemeines zu den Lösungsansätzen
Technische Realisierung von eNIC
Technische
Realisierung I-DNS.net
I-DNS in der Praxis
Anhang: Quellen
Das Internet hat sich heute schon auf alle Bereiche der
Welt mit ihren verschiedenen Ausprägungen bezüglich Sprache und Kultur
ausgebreitet. Dadurch besteht auch die Forderung nach Anpassung der im Internet
laufenden Dienste an die örtlichen Bedürfnisse der Anwender. Es ist dann zum
Beispiel möglich einer anderen Person eine Email in chinesisch zu schicken,
oder sich eine Webpage in japanisch anzusehen.
Warum
sollte man deshalb nicht auch Domainnamen internationalisieren, nachdem man
auch die Webpages schon auf allen Erdteilen in den verschiedensten Sprachen
abrufen kann? Unterschiedliche Sprachen werden von den untersten Ebenen des
Internet weder bevorzugt, noch diskriminiert. Jedoch gibt es auf der Anwendungsebene
historisch bedingte Dominanz durch die USA und den dort verwendeten
ASCII-Zeichensatz. Ein klassische Begrenzung des Zeichensatzes stellt das
herkömmliche Internet DNS (Domain Name System) dar. Es basiert auf einer
Teilmenge des ‚Latin-1’-Alphabets, konkret alle englischen Buchstaben (nicht
case-sensitiv), die dezimalen Ziffern und den Bindestrich [RFC1034, RFC1035].
Während
ein begrenzter Zeichensatz einen Sinn macht, wenn ein Domain Name auf der
ganzen Welt Anwendung finden soll, macht es ebenso Sinn, wenn man einen
zusätzlichen Namen mit nationalisiertem Zeichensatz vergibt. Beispiel: Die
Online-Version der Tageszeitung OÖNachrichten (Oberösterreichische Nachrichten)
ist unter http://www.ooen.at zu erreichen, jedoch
noch nicht unter http://www.oön.at , obwohl
diese dadurch leichter auffindbar wäre.
Wir
werden hier jedoch weniger die Vor- und Nachteile der Internationalisierung
behandeln, sondern vielmehr eine Lösungsmöglichkeit diskutieren. Die Lösung,
die hier vorgestellt wird behandelt die Einführung einer neuen
‚Zero-Level’-Domain, die die Wurzel eines neuen Domain-Name-Baumes bildet, und
eine Abbildung des ‚Universal Character Set’ (UCS / ISO10646) auf den
begrenzten Zeichensatz des DNS.
Internet Engineering Task Force – IETF
Die
Internet Engineering Task Force (IETF) ist ein große offene internationale
Gemeinschaft von Netzwerkdesignern, -betreibern, -verkäufern und Forschern, und
beschäftigen sich mit der Weiterentwicklung und des reibungslosen Betriebs des
Internet. Sie ist offen für jeden Interessenten.
Die
verschiedenen aktuellen technischen Arbeiten werden in verschiedenen
Arbeitsgruppen erledigt, die je nach Thema in verschiedene Sachgebiete
unterteilt sind (Z.B.: Routing Area, Transport Area, Security Area, etc.). Das
Meiste dieser Arbeit entsteht über die Kommunikation via Mailing-Lists.
Aus den
Diskussionen via Mailing-Lists entstehen sogenannte ‚Internet-Drafts’. Diese
stellen schon eine Zusammenfassung der aus den Mailing-Lists erarbeiteten
Überlegungen dar. Jedoch wird darin explizit darauf hingewiesen, dass es sich
hier nicht um fertige Endfassungen handelt, die man zitieren könnte. Wenn die
Überlegungen in diesen Drafts einen allgemein als ‚implemetierungsreif’
geltenden Stand erreichen, können daraus RFCs entstehen, aus denen sich dann
allgemein gültige Standards entwickeln können.
Innerhalb
der IETF gibt es im Sachgebiet ‘Internet Area’ die Arbeitsgruppe
‚Internationalized Domain Name’ (IDN).
Das
Ziel dieser Gruppe ist es, Anforderungen für den internationalisierten Zugang
zu Domainnamen zu spezifizieren, und in weiterer Folge Anhand dieses
Anforderungsprofils Protokolle zu standardisieren.
Konkrete
Arbeiten:
·
Ein informelles RFC (Request for comments), das den
Zugang zu internationalisierten Domainnamen spezifiziert. Dieses Dokument soll
Richtlinien für die Entwicklung von Lösungen dieses Problems beinhalten. Dabei
sollen lokale Probleme (z.B. Schreibrichtung von rechts nach links) und verwandte
Themen in Betracht gezogen werden.
·
Ein oder mehrere informelle RFC’s, die die verschiedenen
Ansätze und Implementierungsmöglichkeiten der Internationalisierung
dokumentieren. Diese Dokumente sollen auch eine Bewertung dieser Ansätze aus
technischer Sicht beinhalten.
·
Eine standardisierte Vorgehensweise des Zugangs zu
internationalisierten Domainnamen und dessen Übergang vom herkömmlichen DNS.
Aktueller Stand der Standardisierung
Derzeit sind noch keine RFCs erarbeitet,
es ist also noch kein allgemein gültiger Standard in Sicht. Den aktuellen Stand
der IDN-Working Group markiert derzeit das Internet-Draft ‚Requirements of
Internationalized Domain Names’, in dem das konventionelle DNS mit dessen
Einschränkungen und die Anforderungen an ein IDNS diskutiert werden.
Nachfolgend sind einige
Anforderungen aus diesem Draft mit aktuellem Stand vom 21.Juni 2001
aufgelistet:
(Anm.: Die Gültigkeit eines
Internet-Drafts läuft nach 6 Monaten ab!)
·
Aufgrund seiner Wichtigkeit darf das herkömmliche
DNS-System in seiner Funktionsweise nicht gestört werden.
·
Systeme, die schon das Auflösen eines IDN gewährleisten
müssen auch weiter funktionieren können.
·
Das IDNS muss das grundsätzliche DNS-Konzept, das im RFC
1034 beschrieben ist beinhalten.
·
Es muß auch dessen Features wie IPv4 und IPv6
unterstützen.
·
Die selbe Namensauflösungsanforderung muß immer das selbe
Ergebnis liefern, egal welche Nameserver, und von welchem Land aus abgefragt
wird.
·
Das neue Protokoll muss so konzipiert sein, dass auch
alte DNS Cache-Server weiterverwendet werden können.
·
Veränderungen im DNS-Protokoll muss mit der
DNSEXT-Working Group abgestimmt werden.
·
Aus der Benutzersicht muss die dieser Dienst so einfach
als möglich sein. Idealerweise sollte der Benutzer gar nichts davon merken dass
jetzt auch IDN zur Verfügung steht.
·
Das Protokoll muss spezifizieren, welcher Zeichensatz bei
der Namensauflösung verwendet wird, und wie die einzelnen Zeichen in den
DNS-Records kodiert sind.
·
IDNS-Protokoll darf nicht im Standard spezifizierte
Zeichen nicht ablehen. (Dies gewährleistet auch weiterhin eine leichte
Erweiterung der Zeichensätze)
·
Im Protokoll soll kein neuer Zeichensatzstandard
spezifiziert werden. Nur vorhandene Zeichensatzstandards sollen Anwendung
finden.
Weiters
gibt es noch Überlegungen in Form anderer Internet Drafts zum Thema
Zeichensätze (z.B.: UTF-6, UCS, ...), und konkrete Protokollüberlegungen (EDNS,
UDNS, VIDNS,...)
Es
wurden auch verschiedene grundsätzliche Ansätze diskutiert, wie z.B. die
Einführung einer zusätzlichen Level-Zero-Domain zur Auflösung von IDNs oder die
Erweiterung um einen zusätzlichen Service eines DN-Servers und der
Resolver-Algorithmen im Betriebssystem auf der Anwenderseite.
Internationalisierung der DNS in der Praxis
Allgemeines zu den
Lösungsansätzen
Bisher
gibt es noch keine verbindlichen Normen und Richtlinien - weder in Bezug auf
die technische Implementierung noch auf elementare praktische Fragen
(Schreibrichtung, Gross/Kleinschreibung, Sonderzeichen) eines multilingualen
DNS - existieren, die Nachfrage aber steigt, beginnen einige Firmen, auf eigene
Faust solche Systeme zu verwirklichen.
Da die
unten vorgestellten Lösungen auf das herkömmliche DNS aufbauen (müssen),
besteht die Problematik hauptsächlich in der Aufgabenverteilung der Umwandlung
der multilingualen Zeichen in ein DNS-Kompatibles Format. Derzeit wird die
Umwandlung auf den EDV-Systemen der Anbieter – also zentralisiert –
vorgenommen.. Wenn eine wachsende Anzahl von Benutzern multilingualer Websites
zb. die selben DNS-Server-Einstellungen vornehmen (müssen), ist vorstellbar,
dass das System schnell an seine Grenzen kommt, weshalb langfristig eine
grundsätzliche Änderung im DNS von den Server-Applikationen bis zu den
Betriebssystemen erforderlich sein wird.
Technische Realisierung von eNIC
Eine
der ersten Lösungen eines multilingualen DNS-Systems bietet die Fa. eNIC für
ihre Top-Level-Domain .cc an. Dabei fungiert .cc wie ein (oben beschriebene)
Zero-Level-Domain. Durch die Endung .cc bei jeder (auch multilingualen)
Web-Site der Firma ist automatisch ein „Hauseigener“ Server mit der Auflösung
der Adresse befasst. Dieser Wandelt den multilingualen Teil der Adresse in ein
dem derzeit gültigen DNS-Format entsprechenden um und sendet die Anfrage an
eine bestehende – normalcodierte - Adresse weiter.
Die
multilinguale Version der Webadresse kann ohne Mehrkosten zusätzlich zur
normalen Adresse eingerichtet werden.
Der
Internet-Explorer sendet URL’s standardmäßig UTF8-codiert, was Probleme bei der
Auflösung der Namen ergeben kann. Beim Internet-Explorer muss deshalb die
entsprechende Option deaktiviert werden.
Bei
nicht 8-bit-fähigen Proxy-Servern funktioniert das System überhaupt nicht, da
die multilingualen Zeichen ausgefiltert werden.
Leider
werden von eNIC keine Links zu Beispiel-Seiten zur Verfügung gestellt.
Technische Realisierung I-DNS.net
Bei I-DNS.net können alle Top-Level-Domains benutzt und die gesamte URL multilingual
angegeben werden. Über spezielle DNS-Server (z.B. iBIND) werden die URL’s dann
decodiert. Alternativ zur Umstellung der lokalen DNS-Einträge kann ein
bereitgestelltes Programm für die korrekte Adressauflösung der Clients benutzt
werden.
Hier
gelten die selben Einschränkungen in Bezug auf den Internet-Explorer und
veraltete Proxy-Server wie oben. Zusätzlich muss jedoch entweder der
DNS-Eintrag geändert, ein Programm heruntergeladen oder der Provider zur
Installation von iBIND bewogen werden.
I-DNS in der Praxis
Israelische Site (auf deutschen
Windows- bzw. Netscape-Versionen)
Taiwanesische Site (auf taiwan. Sytem)
|
[RFC1034] |
Mockapetris, P., „Domain
Names – Concepts and Facilities“, STD 13, RFC 1034, November 1987. |
|
[RFC1035] |
Mockapetris, P., „Domain
Names – Implementation and Specification“, RFC 1035, November 1987 |
|
|
i-DNS.net
International, „ccTLD Position Paper“, Internet: http://www.i-dns.net |
|
|
Seng,
J. & Yap, J., “iDNS – The Next Big Step in the Internet Saga”, Dec. 1999,
Internet: http://www.i-dns.net |
|
|
eNIC,
“Multilingual INFO/FAQ”, Internet: http://www.enic.cc |
|
|
VeriSign,
“global registry services”, Internet: http://www.verisign-grs.com |