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

115

In unserem Büro haben wir ein lokales Netzwerk mit einem rein internen DNS-Setup, auf dem alle Clients mit dem Namen "" bezeichnet sind whatever.lan. Ich habe auch eine VMware-Umgebung und im reinen Netzwerk für virtuelle Maschinen bezeichne ich die virtuellen Maschinen whatever.vm.

Derzeit ist dieses Netzwerk für die virtuellen Maschinen nicht erreichbar von unserem lokalen Netzwerk, aber wir die Einrichtung eines Produktionsverbunds auf diese virtuellen Maschinen zu migrieren , was wird aus dem LAN erreichbar sein. Als Folge versuchen wir auf einer Konvention für die Domain - Suffix / TLD wir die Gäste auf dieses neue Netzwerk kommen wir einrichten, aber wir können nicht mit einem guten, da gelten zu regeln .vm, .localund .lanAlle haben bestehende Konnotationen in unserer Umgebung.

Was ist die beste Vorgehensweise in dieser Situation? Gibt es eine Liste von TLDs oder Domainnamen, die für ein rein internes Netzwerk sicher verwendet werden können?

— Otto
quelle

2

Verwenden Sie nicht .local. Vor allem, wenn Sie Apple-Kunden haben.

— RainyRat

2

.test ist aus diesem Grund reserviert

— CWSpear

1

@CWSpear Das ist nicht der eigentliche Grund .test ist reserviert, obwohl es es eine sichere Domäne für die Verwendung macht Testnetze, die nicht mit dem Internet verbunden werden.

— Voretaq7

10

@Otto Best Practices würden vorschreiben, dass Sie einen "echten" Domainnamen (unter einer ICANN-anerkannten TLD) erwerben und eine Subdomain für Ihre lokalen Inhalte erstellen (z. B. registrieren mydomain.com, internal.mydomain.coman einen internen NS delegieren und Split-Horizon-DNS ordnungsgemäß konfigurieren ( "Aufrufe" in BIND), damit Sie keine internen Namen / Adressen an das Internet senden. Es ist nicht so hübsch wie eine TLD / Pseudo-TLD, aber es ist weniger anfällig für Brüche, da es unter Ihrer Kontrolle steht.

— voretaq7

9

Verwenden Sie jedoch keinen echten Domainnamen, den Sie bereits für öffentlich zugängliche Produktionsdienste verwendet haben. Es gibt verschiedene Interaktionen, die zwischen www.example.comund *.internal.example.comnicht zwischen www.example.comund zulässig sind *.example.net, insbesondere die standortübergreifende Cookie-Einstellung. Das Ausführen von internen und externen Diensten auf derselben Domäne erhöht das Risiko, dass ein Kompromiss eines öffentlichen Dienstes die internen Dienste beeinträchtigt, und umgekehrt, dass ein unsicherer interner Dienst den internen Missbrauch eines externen Dienstes provozieren kann.

— Bobince

94

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 zufällig dieselbe Dummy-TLD verwendet. Aus diesem Grund werden global eindeutige Domainnamen bevorzugt.

Der Standard RFC 2606 reserviert Namen für Beispiele, Dokumentationen, Tests, aber nichts für den allgemeinen Gebrauch und aus guten Gründen: Heute ist es so einfach und billig, einen echten und eindeutigen Domainnamen zu erhalten, dass es keinen guten Grund gibt, einen zu verwenden Dummkopf.

Kaufen iamthebest.orgund benennen Sie Ihre Geräte damit.

— bortzmeyer
quelle

53

Um absolut sicher zu sein, würde ich alles in eine Unterdomäne des Domainnamens meines Unternehmens stellen, wie local.company.org, vm.company.org und so weiter.

— Drybjed

4

+1 dies. Vermutlich hat Ihr Unternehmen bereits eine Domain. Erstellen Sie einfach eine Subdomain daraus. Es muss außerhalb Ihres LAN nicht sichtbar / auflösbar sein.

— Dan Carley

3

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 äußerst schwach: Organisationen fusionieren, richten virtuelle private Netzwerke mit Partnerorganisationen ein und machen einfach Fehler, sodass "private" Namen lecken.

— bortzmeyer

8

Mein einziges Problem dabei ist, dass Sie eine Domain nicht wirklich "kaufen" können: Sie können nur eine mieten. Einige Bozos vergessen, eine Rechnung zu bezahlen (und dies ist in einigen Fällen mit hohem Bekanntheitsgrad der Fall), und ein wesentlicher Teil Ihrer Konfiguration geht an einen zufälligen Squatter. Sie nutzen also die Domain Ihres Unternehmens? Execs entscheiden sich für ein Rebranding oder ein Buy-out, und Sie haben einen alten Namen. Früher funktionierte .local gut genug, aber jetzt wurde es von einer bestimmten Firma in einer Weise vorweggenommen, die es ablehnt, nett zu spielen. Ich würde wirklich gerne etwas wie .lan oder .internal sehen, das offiziell für diesen Zweck reserviert ist, aber bis dahin ist dies die beste Option.

— Joel Coel

6

Stimmen Sie @Joel Coel zu, Sie sind ein Mieter und nichts weiter. Es sollten nur zwei reservierte TLD-Namen für den internen Gebrauch vorhanden sein, die in der Öffentlichkeit als ungültig und für öffentliche Netzwerke nicht erreichbar angesehen werden sollten. Ein Name wäre für den internen Heimgebrauch bestimmt, der zweite für den internen Geschäftsgebrauch. Beide würden als "private TLDs" in demselben Sinne betrachtet, wie wir "private Subnetze" haben, die nicht routbar sind (192.168.xx und ilk). Auf diese Weise können Heimanwender nicht nur gezwungen werden, in .local und mDNS zu wechseln. Das Gleiche gilt für kleine Unternehmen, die ein internes LAN hinter einem NAT ohne Domäne betreiben.

— Avery Payne

49

Verwenden Sie eine Subdomain der registrierten Domain Ihres Unternehmens für interne Computer, deren Namen nicht im Internet verfügbar sein sollen. (Dann hosten Sie natürlich nur diese Namen auf Ihren internen DNS-Servern.) Hier einige Beispiele für die fiktive Example Corporation.

Mit dem Internet verbundene Server:
www.example.com
mail.example.com
dns1.example.com

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

Ich habe "corp" verwendet, um zu kennzeichnen, dass diese Unterdomäne Maschinen im internen Unternehmensnetzwerk beschreibt, aber Sie können hier alles verwenden, was Sie möchten, z. B. "internal": client1.internal.example.com.

Denken Sie auch daran, dass DNS-Zonen und -Unterdomänen nicht mit Ihrem Netzwerknummernschema übereinstimmen müssen. Mein Unternehmen verfügt beispielsweise über 37 Standorte mit jeweils eigenem Subnetz, aber alle Standorte verwenden denselben (internen) Domainnamen. Umgekehrt könnten Sie nur ein oder wenige Subnetze haben, aber viele interne Peerdomänen oder Subdomänenebenen, um Ihre Computer besser organisieren zu können.

— Jay Michaud
quelle

32

Die Verwendung einer internen Unterdomäne bietet einen weiteren Vorteil: Durch die geschickte Verwendung von Suchsuffixen und nur Hostnamen anstelle von FQDN können Sie Konfigurationsdateien erstellen, die sowohl in der Entwicklung als auch in der Qualitätssicherung und Produktion funktionieren.

Beispielsweise verwenden Sie in Ihrer Konfigurationsdatei immer "database = dbserv1".

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

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

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

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

— geewiz
quelle

2

Das ist genial

— Chris Magnuson

19

Bis jemand seine Workstation mit dem Suffix für die Produktionssuche falsch konfiguriert, um ein Problem zu testen, und später versehentlich eine Reihe von Produktionsdatensätzen aktualisiert.

— Joel Coel

1

Das ist ziemlich grob, SRV-Datensätze sind sehr einfach zu analysieren und können in jeder Zone platziert werden, sodass derselbe 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 verwenden, der natürlich auf den Hostnamen verweist. Ich würde mich nie auf Suchsuffixe verlassen. Sie können auch mit TXT-Datensätzen sehr kreativ werden und sie mit aes-256-verschlüsselten (dann base64-verschlüsselten) Werten füllen, wenn es sich um Geheimnisse handelt. Sie können TXT-Datensätze für alle möglichen Aufgaben verwenden.

— Figtrap

siehe, aber was ich will, ist example.com, example.dev und example.stg. Die letzten beiden befinden sich nur in einem privaten Netzwerk. Kann ich einen lokalen DNS-Server für den Null-Konfigurationszugriff einrichten? Ich verwende hier immer noch eine ähnliche Konfiguration für alle Sites und verschiebe nur die Änderungen auf tld. Einfach für .dev mit einer Hosts-Datei, aber keine Konfiguration ...

— DigitalDesignDj

14

Seitdem die vorherigen Antworten auf diese Frage geschrieben wurden, gibt es einige RFCs, die die Richtlinien etwas ändern. RFC 6761 behandelt Domänennamen mit besonderer Verwendung, ohne spezifische Richtlinien für private Netzwerke bereitzustellen. RFC 6762 empfiehlt weiterhin, keine nicht registrierten TLDs zu verwenden, erkennt jedoch auch an, dass es Fälle gibt, in denen dies ohnehin geschehen wird. Da die häufig verwendeten lokalen Konflikte mit Multicast-DNS (dem Hauptthema des RFC) auftreten, werden in Anhang G. Private DNS-Namespaces die folgenden TLDs empfohlen:

Intranet
intern
Privatgelände
corp
Zuhause
lan

IANA scheint beide RFCs zu erkennen , enthält jedoch (derzeit) nicht die in Anhang G aufgeführten Namen.

Mit anderen Worten: Sie sollten es nicht tun. Wenn Sie sich dennoch dazu entschließen, verwenden Sie einen der oben genannten Namen.

— blihp
quelle

In Anhang G steht vor der von Ihnen zitierten Liste: "Wir empfehlen, überhaupt keine nicht registrierten Top-Level-Domains zu verwenden." Dies ist eher der entscheidende Punkt. Es wird nicht empfohlen, die angegebenen Namen zu verwenden. Es handelt sich lediglich um beobachtete Namen, die besser funktionieren, als sie .localfür MulticastDNS reserviert sind.

— Dies

2

Ich würde nicht zustimmen. Der entscheidende Punkt ist die Absurdität des Hinweises: "Tu es nicht ... aber wenn du es tust ..." Die Erwartung, dass private / kleine / nicht öffentlich zugängliche Netzwerke eine TLD registrieren sollten, ist nicht realistisch. Die Leute werden bisher nicht registrierte TLDs besser verwenden, um allen zu helfen und zu sagen: "OK, hier ist eine Liste der nicht registrierten TLDs, die Sie intern verwenden können", anstatt vorzugeben, dass alle dem harten Rat folgen.

— blihp

Wir werden dann in Uneinigkeit bleiben. Die Tatsache, dass einige Leute .MAIL TLDs wie interne verwendeten (zum Beispiel in vielen Dokumentationen), ist genau der Grund, warum diese TLDs nicht delegiert werden konnten und jetzt auf unbestimmte Zeit tot sind. Daher ist es für die globale Internet-Community ein schlechter Dienst, den Menschen weiterhin zu empfehlen, TLDs auf diese Weise zu verwenden. Der Rat besagt, dass, da einige TLDs bereits so missbraucht werden, Menschen, die missbraucht werden müssen, diese wiederverwenden sollten, anstatt neue zu missbrauchen. RFC2606 ist klar für die TLDs intern zu verwenden, die funktionieren:.EXAMPLE .TEST .INVALID

— Patrick Mevzek

12

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

Auf der anderen Seite ist der RFC 1918 klar:

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

— Benoit
quelle

10

Wir neigen dazu, keinen Unterschied zwischen der virtuellen Benennung von Hosts und der physischen zu berücksichtigen. Tatsächlich haben wir die Host-Konfiguration (Software) von der physischen Ebene abstrahiert.

Also kaufen wir Hardware-Gegenstände und erstellen Host-Gegenstände darüber (und verwenden eine einfache Beziehung, um dies in unserer Dokumentation zu zeigen).

Der Zweck ist, dass wenn ein Host vorhanden ist, DNS nicht der entscheidende Faktor sein sollte - da wir Maschinen haben, die von einem Bereich zum nächsten wechseln - zum Beispiel muss eine leistungsschwache Web-App keine teuren CPU-Zyklen verbrauchen - virtualisieren , und es behält sein Namensschema bei, alles funktioniert weiter.

— Mike Fiedler
quelle

-4

Ich bin mir nicht sicher, ob dies hilfreich ist, aber für interne DNS in meinem AWS-Konto verwende ich .awsals tld und es scheint einwandfrei zu funktionieren.

Ich weiß, dass es einige TLDs gibt, die Sie einfach nicht verwenden sollten, aber abgesehen von diesen, denke ich, ist es nicht zu streng.

Ich habe bei einigen größeren Unternehmen gearbeitet, bei denen die Authentifizierungsquelle als TLD verwendet wurde. Das heißt, wenn es sich um einen MS / Windows-Server handelte und Active Directory als Authentifizierungsquelle verwendet wurde, war dies der Fall .ad, und einige andere waren es .ldap(Warum wurden sie verwendet?) Verwenden Sie nicht nur dieselbe Quelle oder Server, die vom selben Verzeichnisdienst repliziert werden? Ich weiß nicht, es war so, als ich dort ankam.

Viel Glück

— Justin
quelle

2

Amazon hat sich jetzt .awsals TLD registriert, so dass möglicherweise Probleme auftreten können: nic.aws

— Mark McKinstry

1

Zur Information, die .aws ist vor kurzem registriert "25 März 2016" => newgtlds.icann.org/en/program-status/delegated-strings

— Bruno Adelé

Ich halte die Verwendung einer falschen TLD zwar nicht für eine so große Sache, zumindest nicht, wenn das gesamte System geschlossen ist und ein Proxy für die Kommunikation mit dem Internet verwendet wird, aber ".aws" ist eine wirklich schlechte Wahl, es sei denn, Sie bist NICHT in AWS! Es gibt viel zu viele denkbare Szenarien, in denen Sie nicht mehr mit AWS kommunizieren können.

— Figtrap