Überfällig: ICANN legt sich auf Namen für interne Domains fest

Damit dürfte nach Jahrzehnten der DNS-Entwicklung endlich geklärt werden, wie man Namenskollisionen bei der Bezeichnung von internen Domains sicher umgeht.

In Pocket speichern vorlesen Druckansicht 310 Kommentare lesen

(Bild: alexskopje/Shutterstock.com)

Lesezeit: 5 Min.

Seit es das weltweite Domain Name System gibt (DNS), auf das sich Internet-Geräte stützen, um einander zu finden, fehlt eine Richtlinie zur Wahl von Domainnamen für interne Netzwerke. Die Lücke kann jahrelang oder auch ewig folgenlos bleiben, aber bisher war ungewiss, ob und wann irgendein frei gewählter Domainname wie "lokal" oder "privat" möglicherweise doch eines Tages als Top-Level-Domain deklariert wird. Am 24. Januar hat sich die Internet Assigned Numbers Authority (IANA) endlich zu einem festen Namen für interne Domains durchgerungen; die Wahl fiel auf "internal".

Die übergeordnete Internet Corporation for Assigned Names and Numbers (ICANN) muss den Vorschlag der IANA noch abnicken. Dann können Admins, die für ihre interne Domain "internal" konfigurieren, sicher sein, dass dieser Name niemals den Status einer Top-Level-Domain (TLD) bekommt. Der Name wird schlicht nie in die Root-Zone des globalen Domain Name System eingetragen. Das sollte Namenskollisionen mit teils kniffligen Fehlerbildern ausschließen. Technisch gibt es keine Möglichkeit, den Gebrauch beliebiger Namen für interne Domains auszuschließen, sodass nur übrig blieb, einen festen Namen für den internen Gebrauch zu reservieren.

Das Problem erscheint zunächst kleiner als es ist. Viele Firmen-Admins und auch manche Heim-Admins brauchen einen internen Domainnamen, unter dem sie ihre Geräte und Dienste ausschließlich intern über einen eigenen DNS-Server ansprechen; beispielsweise für Dateiserver, die private oder geschäftlich relevante Daten enthalten. Lange Zeit gab es für die Namenswahl der internen Domain keine Richtlinien, sodass sich jeder Admin nach Gutdünken etwas ausgedacht hat, beispielsweise "local". Aber wie immer, wenn eine Spezifikation einen Teilbereich offen lässt, beschwört das früher oder später Probleme herauf.

Beispielsweise wählte der Routerhersteller AVM für die interne Domain den Namen "fritz.box" - hübsch naheliegend, wenn der Router Fritzbox heißt. So kann man das Webinterface der Fritzbox über den leicht zu merkenden Hostnamen fritz.box öffnen. Doch das funktionierte nur einige Jahre lang reibungslos, bis die ICANN auf die Idee kam, "box" als Top-Level-Domain zu registrieren. Prompt krachte es bei der Namensauflösung: Manche Nutzer konnten Drucker oder Dateifreigaben zunächst nicht mehr über den Hostnamen erreichen.

Und vor Kurzem haben Unbekannte sogar die Domain "fritz.box" im Internet registriert, was beispielsweise Phishing-Angriffe per Mail ermöglicht, die prima durch den technisch völlig einwandfreien Domainnamen flankiert wären. Immerhin landen Fritzbox-Nutzer im internen Netz immer auf dem Router und nie auf der externen Website fritz.box, weil der Router diese Domain immer zu sich selbst auflöst. Das gilt jedenfalls für das gängige Szenario, in dem die Fritzbox im Heimnetzen als Resolver konfiguriert ist.

Anderes Beispiel für unglückliche Namenswahl: Vor allem im englischsprachigen Raum erlangte der Name "local" einige Beliebtheit als interner Domainname. Den sollte man aber unbedingt vermeiden, weil er für das Protokoll mDNS reserviert ist. Das verwenden inzwischen nicht nur iOS, macOS (Bonjour), Android und Linux (Avahi), sondern seit einer Weile auch Windows 11 zur lokalen, serverlosen Namensauflösung. Auch an naheliegenden Bezeichnern wie "intern", "lokal", "privat" oder "lan" kann man sich die Finger verbrennen, denn im Prinzip kann jeder Name irgendwann als Top-Level-Domain definiert werden (okay, mal abgesehen von schwächeren Kandidaten wie kuechensieb, katzenkratzbaum oder knuezzlpruetz ;-). Wenn das passiert, dann muss eine Firma ihre gesamte DNS-Infrastruktur umkrempeln, oft auch das Active Directory. Das ist sehr kostspielig.

Bei der ICANN lag das Problem seit 2020 auf dem Tisch; sie hat die Tauglichkeit von 35 Kandidaten geprüft. Der Name sollte nicht als TLD vergeben, leicht zu merken, kurz, eindeutig und selbsterklärend sein. Am Ende einer jahrelangen Diskussion blieben die Kandidaten "private" und "internal" übrig. "private" fiel schließlich durch, weil man es im Zusammenhang mit Privatsphärenschutz missverstehen kann. Auf die nicht minder profane Wahl "internal" hätte man freilich auch in weniger Monaten kommen können.

Administratoren bleibt es aber weiterhin überlassen, interne Domainnamen nach Gutdünken zu wählen. Die ICANN warnt aber ausdrücklich vor unabsehbaren und kostspieligen Folgen. Man kann nun gespannt sein, ob und wann Hersteller von Routerbetriebssystemen "internal" aufgreifen und sich von liebgewonnenen Provisorien wie "lan" (OpenWrt), "fritz.box" (AVM) oder "dlink" (D-Link) trennen. Firmen, Institutionen und auch Privatpersonen, die eigene Domains im Internet registriert haben, sind hingegen nicht auf "internal" angewiesen. Viele Admins nehmen einfach eine Subdomain ihrer öffentlich registrierten Domain, also etwa "lokal.firma.de", klammern diese aber aus dem öffentlichen DNS aus.

ICANN: Identification of a top-level domain for private use

(dz)