DNS Design bei mehreren Standorten

[NorbertFe 1.799]

Ja und "dann" erinnert man sich jedesmal dran, wenn man "Probleme" hat. ;)

[NilsK 2.785]

Moin,

 

die gleichen Hostnamen für das Computerkonto selbst geht nicht. Aber das muss auch nicht sein, um das was der OP will zu realisieren.

 

technisch mag das gehen. Vielleicht sogar "einfacher", als ich annahm. Trotzdem bin ich ja ein Freund der Sinnfrage.

 

Damit das funktioniert und irgendeinen Vorteil hat (Anwender nutzen den Hostnamen und kommen auf ihren standortlokalen Server), müssten die Clients zusätzlich ja das Standortsuffix als primäres DNS-Suchsuffix bekommen. Geht doch, wirst du sagen. Klar, geht auch, kriegt man bestimmt hin. Und schon haben wir wieder eine Besonderheit in der Umgebung, um nicht zu sagen, eine exotische Konfiguration. Die vielleicht diesen einen Anwendungsfall vereinfacht, dafür viele andere komplizierter macht.

 

Und nun komme ich noch mal und frage: Warum nicht einfach gleich die Server mit standortspezifischen Hostnamen versehen? Wo könnte ein ernsthafter Vorteil liegen, wenn die Server "gleiche" Hostnamen haben, wo sie ja in Wirklichkeit doch unterschiedliche FQDNs haben? Außer "weil es geht" kommt mir da zumindest bislang nichts in den Sinn. Einen Business Case hat der TO bislang ja auch nicht benannt.

 

Und ganz am Ende werfe ich dann einfach mal das Windows-Feature ein, das für solche Fälle gedacht ist: DFS-N.

 

Gruß, Nils

bearbeitet 16. April 2015 von NilsK

[frr 11]

Moin,

 

 

technisch mag das gehen. Vielleicht sogar "einfacher", als ich annahm. Trotzdem bin ich ja ein Freund der Sinnfrage.

 

Damit das funktioniert und irgendeinen Vorteil hat (Anwender nutzen den Hostnamen und kommen auf ihren standortlokalen Server), müssten die Clients zusätzlich ja das Standortsuffix als primäres DNS-Suchsuffix bekommen. Geht doch, wirst du sagen. Klar, geht auch, kriegt man bestimmt hin. Und schon haben wir wieder eine Besonderheit in der Umgebung, um nicht zu sagen, eine exotische Konfiguration. Die vielleicht diesen einen Anwendungsfall vereinfacht, dafür viele andere komplizierter macht.

 

Und nun komme ich noch mal und frage: Warum nicht einfach gleich die Server mit standortspezifischen Hostnamen versehen? Wo könnte ein ernsthafter Vorteil liegen, wenn die Server "gleiche" Hostnamen haben, wo sie ja in Wirklichkeit doch unterschiedliche FQDNs haben? Außer "weil es geht" kommt mir da zumindest bislang nichts in den Sinn. Einen Business Case hat der TO bislang ja auch nicht benannt.

 

Und ganz am Ende werfe ich dann einfach mal das Windows-Feature ein, das für solche Fälle gedacht ist: DFS-N.

 

Gruß, Nils

 

Zu Thema Standortsuffix: Die Clients können auch ein abweichendes primäres DNS Suffix verwenden. Dann generieren die Clients sogar Ihre SPNs für dieses Suffix (Client FQDN "client1.foo.bar" ist Mitglied in der AD Domäne "ad.bar") . Ein andere Möglichkeit wäre natürlich das definieren von Suchsuffixen über eine GPO die man mit dem jeweiligen AD Standort verknüpft. 

 

Zum Thema Sinnfindung: Du hast z.B. ein Skript, was von dem Hostnamen "Fileserver" aus einem Share bestimmte Daten zieht. Damit Du das Skript nicht für jeden Standort anpassen musst, könnte so ein generischer Name schon Sinn machen. Ein Beispiel wären da auch ein Repository Server für automatische Setups etc.. Da fallen mir einige Anwendungsbeispiele ein.

 

DFS-N ist zwar gut gedacht, leider gibt es noch andere Betriebssysteme, die das nicht können. Da muss man sich dann auf dem kleinsten Nenner treffen, um eine Lösung zu finden.

 

Bye,

 

Frank

[NilsK 2.785]

Moin,

 

mag ja sein, dass es einen Anwendungsfall gibt. Der TO hat keinen genannt. Dein Skriptbeispiel überzeugt mich jetzt beim besten Willen nicht - da stehen Aufwand und Nutzen doch in einem eher eigenwilligen Verhältnis. :D

 

Worauf ich hinauswill: Die diskutierte Konfiguration ist weit fernab üblicher Konfigurationen und Empfehlungen. DNS ist mit großem Abstand die wichtigste Fehlerquelle für das AD. Man sollte also, wenn man eine komplexe Konfiguration betreibt, schon sehr sattelfest sein. Dass du das bist, bezweifle ich keinen Moment. Wer aber bislang gar kein AD betreibt, hat u.U. nicht ganz so viel Know-how und Erfahrung. Und da rate ich von solchen Konstellationen eben ausdrücklich ab. Ich habe genügend Kunden beraten, nachdem sie interessante Ideen umsetzen wollten und dann auf enorme Probleme gestoßen sind ...

 

Daher empfehle ich in solchen Fällen dringend, den eigentlichen Anwendungsfall zu definieren und nach möglichst wenig komplexen Lösungsansätzen zu suchen. In diesem Thread diskutieren wir nicht die Lösung eines Problems (das ist ja gar nicht bekannt), sondern die Probleme einer Lösung (um mal wieder meine Lieblingsformulierung anzubringen).

 

Gruß, Nils

bearbeitet 17. April 2015 von NilsK