In diesem Artikel geht es um die Verwendung Netzwerk-interner Domains, die nicht mit einer öffentlichen Domain kollidieren kann.
(Einige weiterführende Verlinkungen hier zeigen auf englischsprachige Inhalte bei internationalen Organisationen.)
Mögliche Kandidaten für Top-Level-Domains (TLD)
Es gibt ein paar RFCs der Internet Engineering Task Force (IETF) zu dem Thema, in denen mögliche TLDs für einen internen Gebrauch beschrieben werden.
Ein erster Ansatz mit einer Liste von speziellen TLDs und der Referenzen zu den RFCs mit den Beschreibungen der Verwendungszwecke findet man bei der Internet Assigned Numbers Authority (IANA) unter Special-Use Domain Names.
Es ergibt sich hierbei eine Liste mit:
- .alt -> RFC 9476 The .alt Special-Use Top-Level Domain
- .home.arpa -> RFC 8375 Special-Use Domain ‚home.arpa.‘
- .example[.com|.net|.org]
Beschreibung (übersetzt) aus RFC2606:
„.example“ wird für die Verwendung in der Dokumentation oder als Beispiel empfohlen. - .test -> RFC 6761 Special-Use Domain Names
Beschreibung (übersetzt) aus RFC2606:
„.test“ wird zum Testen von aktuellem oder neuem DNS-bezogenem Code empfohlen.
aus RFC6761 6.2:
Es steht den Benutzern frei, diese Testnamen wie jeden anderen Domänennamen zu verwenden. Da es jedoch keine zentrale Autorität gibt, die für die Verwendung von Testnamen verantwortlich ist, SOLLTEN sich die Benutzer darüber im Klaren sein, dass diese Namen in verschiedenen Netzen wahrscheinlich unterschiedliche Ergebnisse liefern.
Weitere mögliche TLDs werden im RFC 6762 zu Multicast DNS im Anhang G genannt:
- .intranet
- .internal * -> ICANN legt sich auf Namen für interne Domains fest @ heise.de
- .private
- .corp
.home-> wurde ersetzt mit .home.arpa (RFC 8375 Special-Use Domain ‚home.arpa.‘)- .lan
Subdomain einer öffentlichen Domain für interne Zwecke
Um von Anfang an zu vermeiden, dass es eine Kollision mit einer öffentlichen Domain irgend wann geben könnte, kann man auch eine Subdomain von einer öffentlichen Domain so einrichten, dass sie im öffentlichen Bereich nicht ersichtlich ist. Man sollte dabei eine eigene Domain für sich registriert und unter eigener Kontrolle haben.
Der Trick bei dieser Sache ist, dass der interne DNS erst mit der Subdomain (und ggf. darunter liegenden weiteren Subdomains) eingerichtet wird. Der interne DNS wird einen Konfigurations-Parameter benötigen (unabhängig davon ob er selbst Domain-Zonen hält, oder nicht) um allgemeine Anfragen ins Internet zu beantworten – man spricht hier von einem Forwarder; also von einem vorgelagerten DNS-Server, der die Namensauflösung für Anfragen ins Internet übernimmt (zumeist auf dem Internet-Router bereits vorhanden). Der interne DNS bentwortet nun Anfragen mit internen IPs für die interne Subdomain – sobald aber Anfragen zu der darüber liegenden Domain ankommen, werden diese an den Forwarder geleitet und dadurch mit öffentlichen IPs beantwortet.
Warum nicht .local
Die (Top-Level) Domain .local wird für Mutlicast DNS (mDNS) verwendet und gemäß RFC 6762 Multicast DNS sollen alle Anfragen mit .local an eine link-local Multicast Adresse gesendet werden.
Das hierbei genutzte Verfahren wird bei vielen Gerätschaften mit automatischer Konfiguration eingesetzt. Beispielsweise nutzt Apple dies in seinem Bonjour Protokoll um verschiedendste Geräte miteinander zu verbinden (z.B. zum Anbinden von Druckern oder anderen AirDrop Gerätschaften).
Es gibt heutzutage noch viele weitere Anwendungen und Geräte die mit mDNS arbeiten – gerade im IoT-Bereich (Internet der Dinge) oder auch im Bereich von SmartHome.
Quellen und weiterführende Links
- Internet Engineering Task Force (IETF)
- Internet Corporation for Assigned Names and Numbers (ICANN)
- Internet Assigned Numbers Authority (IANA)
- Presse
- Wikipedia: Top-Level-Domain