FQDN - interne Domain - viele Filialen - Erfahrungen mit der Namensgebung
Moin Moin,
ich habe mich die Tage in einem interessanten Gespräch mit einem anderen Admin unterhalten.
Er sagte mir gegenüber aus, dass sie auf allen zukünftigen Servern, internen Domain, DNS Config, etc. welche Sie einrichten nur noch die öffentliche Domain für das FQDN verwenden.
Sie hätten ansonsten immer wieder den Aufwand mit der Namensauflösung von Office 365 und der lokalen Domain zu betreiben.
"einfache Probleme" dieser Art sind mir auch bekannt.
Bei O365 muss oft die korrekte Mail Adresse nachgepflegt bzw. ein extra Script für viele User geschrieben werden.
Nun die Frage dazu:
Wer von euch hat hiermit bereits Erfahrung? Wie sind Selbige?
Habt Ihr in der Einrichtung neuer Domains als FQDN öffentliche Domains verwendet?
In meiner Lehrzeit wurde mir eingetrichtert, das die interne Domain immer nur *.local; *.lan; etc... heißen darf.
ich habe mich die Tage in einem interessanten Gespräch mit einem anderen Admin unterhalten.
Er sagte mir gegenüber aus, dass sie auf allen zukünftigen Servern, internen Domain, DNS Config, etc. welche Sie einrichten nur noch die öffentliche Domain für das FQDN verwenden.
Sie hätten ansonsten immer wieder den Aufwand mit der Namensauflösung von Office 365 und der lokalen Domain zu betreiben.
"einfache Probleme" dieser Art sind mir auch bekannt.
Bei O365 muss oft die korrekte Mail Adresse nachgepflegt bzw. ein extra Script für viele User geschrieben werden.
Nun die Frage dazu:
Wer von euch hat hiermit bereits Erfahrung? Wie sind Selbige?
Habt Ihr in der Einrichtung neuer Domains als FQDN öffentliche Domains verwendet?
In meiner Lehrzeit wurde mir eingetrichtert, das die interne Domain immer nur *.local; *.lan; etc... heißen darf.
Bitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben
Content-ID: 415882
Url: https://administrator.de/forum/fqdn-interne-domain-viele-filialen-erfahrungen-mit-der-namensgebung-415882.html
Ausgedruckt am: 26.12.2024 um 23:12 Uhr
3 Kommentare
Neuester Kommentar
Zitat von @ElmaCx:
In meiner Lehrzeit wurde mir eingetrichtert, das die interne Domain immer nur *.local; *.lan; etc... heißen darf.
In meiner Lehrzeit wurde mir eingetrichtert, das die interne Domain immer nur *.local; *.lan; etc... heißen darf.
Da hat man dir nur die halbe Wahrheit beigebracht: ".local" ist für mDNS reserviert und sollte auch für nichts anderes verwendet werden
Es ist in vielen Fällen sicherlich eine gute Praxis das so zu handhaben. Eine technische Notwendigkeit, nur "interne" Domains zu verwenden, gibt es nicht. Wenn man weiß was man tut, solide Grundkenntnisse über DNS und letztlich auch die passende Infrastruktur hat um die DNS-Zonen ordentlich aus dem Internet aufzulösen, erspart es einem möglicherweise auch viel Aufwand und Ärger.
Ich verweise da auf deinen anderen Thread mit der Frage nach ordentlicher Hostname-Vergabe für die zig Filialen - genau da wäre es eigentlich sinnvoll mit einer einzigen Domain zu arbeiten, bei der die Filialen jeweils als Subdomain eingerichtet und dort vor Ort auch als Suchdomain eingetragen sind. Dann kannst du bei einer Vernetzung der Standorte immer die DNS-Namen verwenden, da diese ja von überall auflösbar sind.
Du musst dann aber halt auch sicherstellen, dass die DNS-Zone für die Domain (oder den Zweig, ab dem das AD betrieben wird) auf deine eigenen Server delegiert ist und diese so redundant sind, dass die DNS-Auflösung immer sichergestellt ist.
Das ist ein Aufwand, den du normalerweise für die kleine Steuerberaterkanzlei an der Ecke mit den vier Mitarbeitern nicht betreibst - und bei denen ist es tatsächlich geübte Praxis, eben nicht deren öffentliche Domain zu verwenden, weil du dann eine bunte Auswahl an Problemen bekommst, wo die Namensauflösung nicht ordentlich hinhaut.
Einen Nachschlag habe ich dazu noch:
So oder so ähnlich würde man das in einer Windows-AD-Umgebung machen.
Du hast einmal deine Basis-Domain (sagen wir mal "firma.tld").
Da würdest du dann eine Zone "ad" anlegen und die würdest du dann unterteilen in Subdomains für jede Filiale - meinetwegen mit Filialnummer oder Standortkürzel oder wasauchimmer. Ich nehme jetzt mal ein Filialkürzel.
Die Filiale #25 ist jetzt also Teil der Domain als "f25.ad.firma.tld". Alle Systeme dieser Filiale bekommen dann unterhalb von "f25.ad.firma.tld" ihren DNS-Eintrag und sind damit eindeutig identifizierbar. Damit man in der Filiale aber nicht immer viel tippen muss, bekommt die Filiale "f25.ad.firma.tld" auch als primäre Suchdomain eingerichtet. Damit heißt der dortige Datenserver zwar weiterhin "datasrv-01.f25.ad.firma.tld", kann aber von den Mitarbeitern in der Filiale einfach mit "datasrv-01" aufgerufen werden, weil ja die Suchdomain automatisch als Suffix angehangen wird.
DAS könnte aber kollidieren, wenn sich ein Notebook dieser Filiale immer wieder in unterschiedlichen Netzen befindet und wechselnde Suchdomains hat - denn dann versucht man sich plötzlich am falschen Datenserver anzumelden wenn man in der Suchdomain "f08" gelandet ist.
Sowas ließe sich entweder durch statisch eingetragene Suchdomains vermeiden, mit einer entsprechenden Disziplin bei der Namensvergabe oder durch allgemeinere Suchdomains.
Disziplin könnte so aussehen, dass man grundsätzlich die Namen aller Geräte an zentraler Stelle verwaltet und demzufolge der einzige Datenserver, den Filiale 25 hat, trotzdem "datasrv-61" heißt, weil es berreits 60 andere Server gibt.
Das funktioniert dann vor Ort in Filiale 25 mit dem Aufruf von "datasrv-61" noch immer, aber nicht mehr außerhalb der eigenen Suchdomain.
Hier wäre es dann nötig, entweder immer den Filialteil mit anzugeben ("datasrv-61.f25") und die Liste der Suchdomains um "ad.firma.tld" zu erweitern.
Aber insgesamt wäre es ohnehin viel cleverer, man würde innerhalb der gesamten AD immer mit vollständigen Namen arbeiten und das Netzlaufwerk auf dem Notebook immer mit "datasrv-61.f25.ad.firma.tld" verbinden lassen. Das funktioniert dann immer und auch mit einem VPN
So oder so ähnlich würde man das in einer Windows-AD-Umgebung machen.
Du hast einmal deine Basis-Domain (sagen wir mal "firma.tld").
Da würdest du dann eine Zone "ad" anlegen und die würdest du dann unterteilen in Subdomains für jede Filiale - meinetwegen mit Filialnummer oder Standortkürzel oder wasauchimmer. Ich nehme jetzt mal ein Filialkürzel.
Die Filiale #25 ist jetzt also Teil der Domain als "f25.ad.firma.tld". Alle Systeme dieser Filiale bekommen dann unterhalb von "f25.ad.firma.tld" ihren DNS-Eintrag und sind damit eindeutig identifizierbar. Damit man in der Filiale aber nicht immer viel tippen muss, bekommt die Filiale "f25.ad.firma.tld" auch als primäre Suchdomain eingerichtet. Damit heißt der dortige Datenserver zwar weiterhin "datasrv-01.f25.ad.firma.tld", kann aber von den Mitarbeitern in der Filiale einfach mit "datasrv-01" aufgerufen werden, weil ja die Suchdomain automatisch als Suffix angehangen wird.
DAS könnte aber kollidieren, wenn sich ein Notebook dieser Filiale immer wieder in unterschiedlichen Netzen befindet und wechselnde Suchdomains hat - denn dann versucht man sich plötzlich am falschen Datenserver anzumelden wenn man in der Suchdomain "f08" gelandet ist.
Sowas ließe sich entweder durch statisch eingetragene Suchdomains vermeiden, mit einer entsprechenden Disziplin bei der Namensvergabe oder durch allgemeinere Suchdomains.
Disziplin könnte so aussehen, dass man grundsätzlich die Namen aller Geräte an zentraler Stelle verwaltet und demzufolge der einzige Datenserver, den Filiale 25 hat, trotzdem "datasrv-61" heißt, weil es berreits 60 andere Server gibt.
Das funktioniert dann vor Ort in Filiale 25 mit dem Aufruf von "datasrv-61" noch immer, aber nicht mehr außerhalb der eigenen Suchdomain.
Hier wäre es dann nötig, entweder immer den Filialteil mit anzugeben ("datasrv-61.f25") und die Liste der Suchdomains um "ad.firma.tld" zu erweitern.
Aber insgesamt wäre es ohnehin viel cleverer, man würde innerhalb der gesamten AD immer mit vollständigen Namen arbeiten und das Netzlaufwerk auf dem Notebook immer mit "datasrv-61.f25.ad.firma.tld" verbinden lassen. Das funktioniert dann immer und auch mit einem VPN