Frage Top Level Domain / Domain Suffix für privates Netzwerk?


In unserem Büro haben wir ein lokales Netzwerk mit einem rein internen DNS-Setup, auf dem alle Clients als Clients bezeichnet sind whatever.lan. Ich habe auch eine VMware-Umgebung, und auf dem Nur-Maschine-Netzwerk benenne ich die virtuellen Maschinen whatever.vm.

Derzeit ist dieses Netzwerk für die virtuellen Maschinen nicht über unser lokales Netzwerk erreichbar, aber wir richten ein Produktionsnetzwerk ein, um diese virtuellen Maschinen zu migrieren werden vom LAN erreichbar sein. Daher versuchen wir, eine Vereinbarung für die Domain-Suffix / TLD zu treffen, die wir auf die Gäste in diesem neuen Netzwerk anwenden, das wir gerade einrichten, aber wir können uns keine gute Lösung vorstellen .vm, .local und .lan Alle haben bestehende Konnotationen in unserer Umwelt.

Was ist die beste Vorgehensweise in dieser Situation? Gibt es irgendwo eine Liste mit TLDs oder Domainnamen, die für ein rein internes Netzwerk sicher sind?


103
2018-06-01 21:47


Ursprung


Verwenden Sie nicht .local. Vor allem, wenn Sie Apple-Kunden haben. - RainyRat
.test ist aus diesem Grund reserviert: secure.wikimedia.org/wikipedia/de/wiki/.test - CWSpear
@CWSpear Das ist nicht das tatsächliche Grund  .test ist reserviert, macht es jedoch zu einer sicheren Domäne, für die es verwendet werden kann Prüfung Netzwerke, die nicht mit dem Internet verbunden sein werden. - voretaq7
@Otto Best Practices schreiben vor, dass Sie einen "echten" Domainnamen (unter einer von ICANN anerkannten TLD) erwerben und eine Subdomain für Ihre lokalen Sachen erstellen (z. B. registrieren mydomain.comDelegieren internal.mydomain.com zu einem internen NS, und richtig konfigurieren Split-Horizon-DNS ("Ansichten" in BIND), so dass Sie keine internen Namen / Adressen ins Internet verlieren. Es ist nicht so schön wie eine TLD / Pseudo-TLD, aber es ist weniger anfällig für Bruch, da es unter Ihrer Kontrolle ist. - voretaq7
jedochVerwenden Sie keinen echten Domainnamen, den Sie bereits für öffentliche Produktionsdienste verwendet haben. Es gibt verschiedene Interaktionen, zwischen denen erlaubt ist www.example.com und *.internal.example.com das ist nicht erlaubt zwischen www.example.com und *.example.net, vor allem Cross-Site-Cookie-Einstellung. Das Betreiben von internen und externen Diensten in derselben Domäne erhöht das Risiko, dass eine Kompromittierung eines öffentlichen Dienstes den internen Diensten zutritt verschafft, und umgekehrt, dass ein unsicherer interner Dienst den internen Missbrauch eines externen Dienstes auslösen könnte. - bobince


Antworten:


Verwenden Sie keine erfundene TLD. Wenn ICANN es delegieren würde, wären Sie in großen Schwierigkeiten. Dasselbe gilt, wenn Sie mit einer anderen Organisation fusionieren, die dieselbe Dummy-TLD verwendet. Aus diesem Grund werden global eindeutige Domainnamen bevorzugt.

Der Standard, RFC 2606 reserviert Namen für Beispiele, Dokumentation, Tests, aber nichts für den allgemeinen Gebrauch, und aus guten Gründen: heute ist es so einfach und billig, einen echten und einzigartigen Domain-Namen zu bekommen, dass es keinen Grund gibt, einen Dummy zu verwenden.

Also, kaufe iamthebest.org und verwenden Sie es, um Ihre Geräte zu benennen.


85
2018-06-02 07:39



Um absolut sicher zu sein, würde ich alles auf eine Subdomain des Domainnamens meines Unternehmens setzen, wie local.company.org, vm.company.org und so weiter. - drybjed
+1 dies. Vermutlich hat Ihre Firma bereits eine Domain. Erstellen Sie dazu eine Subdomain. Es muss nicht außerhalb Ihres LANs sichtbar / auflösbar sein. - Dan Carley
Nun, selbst mit sehr guten Anwälten werden Sie Probleme haben, ".lan" oder ".local" zu beanspruchen, indem Sie eine Marke aufrufen. Und das Argument "es ist nur intern" ist extrem schwach: Organisationen verschmelzen, gründen virtuelle private Netzwerke mit Partnerorganisationen und machen einfach Fehler, dass "private" Namen auslaufen. - bortzmeyer
Mein einziges Problem dabei ist, dass Sie eine Domain nicht wirklich "kaufen" können: Sie können nur eine Domain kaufen. Irgendein Bozo vergisst, eine Rechnung zu bezahlen (und das ist in einigen hochkarätigen Fällen passiert) und ein Kernteil deiner Konfiguration geht an irgendeinen zufälligen Hausbesetzer. Sie verwenden also die Domain Ihres Unternehmens? Execs entscheiden sich für ein Rebranding oder einen Buy-out, und Sie haben einen alten Namen. .local hat früher gut genug gearbeitet, aber jetzt wird es von einer bestimmten Firma auf eine Art und Weise verdrängt, die sich weigert, nett zu spielen. Ich würde wirklich gerne etwas wie .lan oder .internal für diesen Zweck reserviert sehen, aber bis dahin ist das die beste Option. - Joel Coel
Vereinbaren Sie mit @Joel Coel, Sie sind ein Mieter, und nichts mehr. Es sollte zwei reservierte TLD-Namen geben nur für interne Benutzung das sollte in der Öffentlichkeit als ungültig betrachtet werden und nicht durch öffentliche Netzwerke erreichbar sein. Ein Name wäre für den internen Gebrauch zu Hause, der zweite Name wäre für den internen Geschäftsgebrauch. Beide würden als "private TLDs" in dem gleichen Sinn betrachtet, in dem wir "private Subnetze" haben, die nicht routbar sind (192.168.x.x und ilk). Dies ermöglicht Heimbenutzern, etwas zu tun, außer in .local und mDNS gezwungen zu werden. Dito für kleine Unternehmen, die ein internes LAN hinter einem NAT ohne Domäne betreiben. - Avery Payne


Verwenden Sie eine Unterdomäne der registrierten Domäne Ihres Unternehmens für interne Computer, deren Namen Sie nicht im Internet verfügbar haben möchten. (Dann sollten Sie diese Namen natürlich nur auf Ihren internen DNS-Servern hosten.) Hier sind einige Beispiele für die fiktive Example Corporation.

Internetorientierte Server:
www.beispiel.de
mail.beispiel.com
dns1.beispiel.com

Interne Maschinen:
dc1.corp.beispiel.com
dns1.corp.beispiel.com
client1.corp.beispiel.com

Ich habe "corp" verwendet, um zu signalisieren, dass diese Subdomain Maschinen im internen Unternehmensnetzwerk beschreibt, aber Sie könnten hier alles verwenden, was Sie wollen, wie "intern": client1.internal.example.com.

Beachten Sie auch, dass DNS-Zonen und Subdomains nicht mit Ihrem Netzwerknummerierungsschema übereinstimmen müssen. Meine Firma hat zum Beispiel 37 Standorte mit jeweils einem eigenen Subnetz, aber alle Standorte verwenden den gleichen (internen) Domain-Namen. Umgekehrt könnten Sie nur ein oder wenige Subnetze haben, aber viele Peer-interne Domänen oder Subdomain-Ebenen, die Ihnen helfen, Ihre Maschinen zu organisieren.


46
2018-06-02 13:03





Es gibt noch einen weiteren Vorteil der Verwendung einer internen Subdomain: Sie können geschickt Suchsuffixe und nur Hostnamen anstelle von FQDN verwenden, um Konfigurationsdateien zu erstellen, die sowohl in der Entwicklung als auch in der Qualitätssicherung und Produktion funktionieren.

Zum Beispiel verwenden Sie immer "database = dbserv1" in Ihrer Konfigurationsdatei.

Auf dem Entwicklungsserver legen Sie das Suchsuffix auf "dev.example.com" fest => verwendeter Datenbankserver: dbserv1.dev.example.com

Auf dem QA-Server legen Sie das Suchsuffix auf "qa.example.com" fest => verwendeter Datenbankserver: dbserv1.qa.example.com

Und auf dem Produktionsserver legen Sie das Suchsuffix auf "example.com" fest => verwendeter Datenbankserver: dbserv1.example.com

Auf diese Weise können Sie in jeder Umgebung die gleichen Einstellungen verwenden.


29
2018-06-04 12:00



Das ist brillant. - Chris Magnuson
Bis jemand seine Arbeitsstation mit dem Suffix Produktionssuche falsch konfiguriert, um ein Problem zu testen, und später unbeabsichtigt eine Reihe von Produktionsdatensätzen aktualisiert. - Joel Coel
Das ist ziemlich grob, SRV-Datensätze sind sehr einfach zu analysieren und können innerhalb jeder Zone platziert werden, so dass der gleiche Datenbankserver mehrere Zonen bedient. In diesem Fall würde ein bisschen Code den Wert in Ihren Konfigurationsdateien ausfüllen. Und Sie können den Namen der Datenbank als SRV-Schlüssel und den Wert des Kurses verwenden, der auf den Hostnamen zeigt. Ich würde mich nie auf Suchsuffixe verlassen. Sie können auch sehr kreativ mit TXT-Datensätzen umgehen und sie mit aes-256-verschlüsselten (dann base64-kodierten) Werten füllen, wenn sie geheim sind. Sie können TXT-Datensätze für alle möglichen Dinge verwenden. - figtrap
sehen, aber was ich will, ist example.com, example.dev und example.stg. Die letzten 2 sind nur in einem privaten Netzwerk, kann ich einen lokalen DNS-Server für null Konfigurationszugriff einrichten? Verwenden Sie immer noch eine ähnliche Konfiguration für alle Sites, verschieben Sie die Änderungen einfach auf tld. Einfach für .dev mit einer hosts-Datei, aber null config ... - DigitalDesignDj


Wie bereits erwähnt, sollten Sie keine nicht registrierte TLD für Ihr privates Netzwerk verwenden. Besonders jetzt, da ICANN fast jedem erlaubt, neue TLDs zu registrieren. Sie sollten dann einen echten Domain-Namen verwenden

Auf der anderen Seite, der RFC 1918 ist klar:

Indirekte Verweise auf solche Adressen   sollte innerhalb der enthalten sein   Unternehmen. Prominente Beispiele für solche   Referenzen sind DNS-Ressourcendatensätze   und andere Informationen beziehen sich auf   interne private Adressen.   Daher sollte Ihr Nameserver auch Ansichten verwenden, um zu verhindern, dass private Einträge im Internet übertragen werden.


10
2018-06-02 12:41





Wir neigen dazu, keinen Unterschied in der virtuellen Benennung von Hosts von der physischen zu berücksichtigen - in der Tat, wir haben uns vorgenommen, die Host-Konfiguration (Software) von der physikalischen Ebene zu abstrahieren.

Also kaufen wir Hardware-Elemente und erstellen Host-Objekte darüber (und verwenden eine einfache Beziehung, um das in unserer Dokumentation zu zeigen).

Der Zweck ist, dass, wenn ein Host existiert, DNS nicht der bestimmende Faktor sein sollte - da wir Maschinen von einem Raum zum nächsten verschoben haben - zum Beispiel muss eine leistungsschwache Webapp keine teuren CPU-Zyklen verbrauchen - virtualisieren und es behält sein Benennungsschema bei, alles funktioniert weiter.


8
2018-06-01 21:52





Ich bin mir nicht sicher, ob dir das helfen wird, aber ich benutze internes DNS in meinem AWS-Konto .aws wie das tld, und es scheint völlig in Ordnung zu sein.

Ich weiß, dass es einige TLDs gibt, die man einfach nicht verwenden sollte, aber außer denen, glaube ich nicht, dass es zu streng ist.

Ich arbeitete bei ein paar größeren Unternehmen, wo sie die Authentifizierungsquelle als TLD verwenden würden, was bedeutet, wenn es ein MS / Windows-Server wäre, der Active Directory als Authentifizierungsquelle verwendet .adund einige andere wären es auch .ldap (Warum verwendeten sie nicht nur die gleiche Quelle? Oder Server, die aus demselben Verzeichnisdienst replizieren? Ich weiß nicht, es war so, als ich dort ankam)

Viel Glück


-4
2018-02-29 14:28



Amazon hat sich registriert .aws als TLD, damit Sie eventuell Probleme sehen: nic.aws - Mark McKinstry
Zur Information ist die .aws vor kurzem "25 März 2016" => registriert newgtlds.icann.org/en/program-status/delegated-strings - Bruno Adelé
Während ich denke nicht, dass die Verwendung einer gefälschten TLD ist so groß von einem Deal, zumindest nicht, wenn das ganze System geschlossen ist und einen Proxy verwendet, um mit dem Internet insgesamt zu kommunizieren, ".aws" ist eine sehr schlechte Wahl, es sei denn Sie sind NICHT in AWS! Es gibt viel zu viele vorstellbare Szenarien, in denen Sie nicht mehr mit AWS kommunizieren können. - figtrap