DNS Design bei mehreren Standorten

[Leuchtkondom 17]

Hallo,

hätte mal ein paar Fragen zum DNS Design bei mehreren Standorten.

Wie macht man das besten? Welche DNS Server trägt man als primär immer jeweils ein?

 

Also am konkreten Beispiel: Derzeit existieren ca. 50 Standorte, wovon ca. 10 Standorte Server haben. Derzeit alles nur per VPN zur Administration usw. verbunden. Jedoch ist geplant, aus den vielen unabhängigen Domänen eine Domäne zu machen.

Dazu gibt es einen Hauptstandort mit 2 DNS Servern. An den Standorten wo Server vorhanden sind, würden die Server dann zusätzlicher DC mit DNS installiert werden....

Wie würde die DNS Konfiguration bei z.b. 3 Standorten aussehen? Vielen Dank für eure Hilfe,

 

Mfg

[Leuchtkondom 17]

Okay, habe hier grade was gefunden.

 

faq-o-matic.net Was muss ich beim DNS fr Active Directory beachten? (Reloaded)

 

Um solche Situationen zu vermeiden, sollte in Netzwerken mit mehreren Standorten eine DNS-Sterntopologie aufgebaut werden: Die DNS-Server der Außenstellen zeigen mit ihrem primären DNS-Eintrag auf einen Server des Hauptstandorts. Dadurch aktualisieren sie dort ihre eigenen Einträge, die dann durch die DNS-Replikation (idealerweise integriert in die AD-Replikation) an alle anderen DNS-Server verteilt werden. Der sekundäre bzw. weitere DNS-Server-Einträge können dann auf Server des eigenen Standorts bzw. auf die lokale Maschine zeigen, damit Unterbrechungen der WAN-Verbindung nicht zu lokalen Betriebsunterbrechungen führen. Eine solche Konfiguration vermeidet auch Probleme bei nächträglichen Änderungen der IP-Subnets.

 

Also Hauptstandort DNS auf sich selber, Außenstellen den primären DNS der Server auf die Hauptstelle, sekündär auf einen vor Ort. So okay?

[dmetzger 10]

Also Hauptstandort DNS auf sich selber, Außenstellen den primären DNS der Server auf die Hauptstelle, sekündär auf einen vor Ort. So okay?

 

Wiederspruch. Die beiden DNS am Hauptstandort zeigen kreuzweise primär auf den jeweils anderen Server am Hauptstandort und sekundär auf sich selbst. (Falls es weitere DNS-Server am Hauptstandort gibt, zeigen diese primär und sekundär in jeweils identischer Konfiguration ebenfalls auf die beiden "Chef-DNS-Server".)

 

Die DNS-Server in den Aussenstellen zeigen jeweils primär auf den einen DNS-Server am Hauptstandort und sekundär auf den zweiten DNS-Server am Hauptstandort, wobei diese Konfiguration für alle DNS-Server an den Aussenstandorten die gleiche ist.

 

Hauptargument hier ist die maximale Vereinfachung von Konfigurationen.

 

Das ist die 1:1 Best Practice gelehrt in Redmond. :)

 

Es gibt allerdings zur Konfiguration der Aussenstandorte auch die Fraktion, die gemäss dem zitierten Auszug aus dem oben geposteten Link vorgeht. Deren Argumentation ist grundsätzlich ebenfalls valid.

[blub 115]

Hallo Leuchtkondom,

du solltest dir mal den "Branch Office Guide" von MS ansehen. Der ist genau für das Design solcher Szenarien geschrieben.

Download details: Branch Office Infrastructure Solution for Windows Server 2008

 

gibts auch für 2003

 

cu

blub

[Leuchtkondom 17]

Wiederspruch. Die beiden DNS am Hauptstandort zeigen kreuzweise primär auf den jeweils anderen Server am Hauptstandort und sekundär auf sich selbst. (Falls es weitere DNS-Server am Hauptstandort gibt, zeigen diese primär und sekundär in jeweils identischer Konfiguration ebenfalls auf die beiden "Chef-DNS-Server".)

 

soweit klar, das hätte ich sonso so gemacht, okay :)

 

 

Die DNS-Server in den Aussenstellen zeigen jeweils primär auf den einen DNS-Server am Hauptstandort und sekundär auf den zweiten DNS-Server am Hauptstandort, wobei diese Konfiguration für alle DNS-Server an den Aussenstandorten die gleiche ist.

 

mm okay. Aber in dem Fall würde doch bei Ausfall der WAN / VPN Verbindung der Server gar nichts mehr auflösen können? Müsst ich dann als 3. DNS Server zumindest nicht ihn selber eintragen? Die Clients an den Außenstellen bekommen aber dann schon den DNS Server des jeweiligen Standortes?!

 

 

@böub: Vielen Dank, ich schaus mir mal an :)

[dmetzger 10]

mm okay. Aber in dem Fall würde doch bei Ausfall der WAN / VPN Verbindung der Server gar nichts mehr auflösen können?

 

Das ist das Hauptargument der anderen Fraktion. :) Wie erwähnt, es handelt sich um eine ebenfalls valide Konfiguration. (Wir unsererseits gehen von zuverlässigen WAN-Anbindungen aus. ;))

 

Hier findest Du ein paar "offizielle" Gedanken (auch mit den Nachteilen der von mir genannten Konfiguration):

Best practices for DNS client settings in Windows 2000 Server and in Windows Server 2003

 

Die Clients an den Außenstellen bekommen aber dann schon den DNS Server des jeweiligen Standortes?

 

Ja natürlich, das regelst Du mit dem DHCP. Clients sollen möglichst nahe gelegene DNS-Server abfragen.

[Leuchtkondom 17]

Zitat von Leuchtkondom

mm okay. Aber in dem Fall würde doch bei Ausfall der WAN / VPN Verbindung der Server gar nichts mehr auflösen können?

 

Das ist das Hauptargument der anderen Fraktion. Wie erwähnt, es handelt sich um eine ebenfalls valide Konfiguration. (Wir unsererseits gehen von zuverlässigen WAN-Anbindungen aus. )

 

 

Okay, da das nicht unbedingt bei uns gegeben ist, werd ich wohl die Konfiguration des prim. DNS auf den HS legen, und als 2. einen vom Standort. Vielen Dank für deine Antworten.

 

Noch etwas. Ist es sinnvoll eine Stern-VPN-Topologie aufzubauen (also Standorte nur an HS), oder sollten Standorte, welche eigene Server haben auch untereinander vernetzt sein? Also im Beispiel von 3 Standorten

 

Standort A - VPN - Standort B

Standort A - VPN - Standort C

Standort B - VPN - Standort C

 

Was ist sinnvoller? Abgesehen von Dateidiensten oder Zugriff von Außenstelle auf Außenstelle untereinander, mir geht es rein um Active Directory Standort- und Dienste erstmal :)

[dmetzger 10]

mir geht es rein um Active Directory Standort- und Dienste erstmal :)

 

Lass AD Replikation die eigene Topologie bestimmen, das funktioniert meistens viel besser als manuelle Konfigurationen, vor allem im kleinen Umfeld wie bei Dir. Dafür gibts ja den ISTG pro Standort.

 

Einer der wichtigen Vortiel ist, dass Du in diesem Fall keine speziellen Konfigurationen dokumentieren und später beachten musst, wenn z.B. physische Standortverbindungen geändert werden und/oder neue hinzukommen.

 

In der dssite.msc musst Du im Grund nur Standorte erstellen, die Subnetze eintragen und den Standorten zuordnen sowie das Intersite-Replikationsintervall von standardmässig 180 Minuten ggf. verkürzen (Minimum ist 15 Minuten).

[Daim 12]

Huhuu,

 

In der dssite.msc musst Du im Grund nur Standorte erstellen, die Subnetze eintragen und den Standorten zuordnen sowie das Intersite-Replikationsintervall von standardmässig 180 Minuten ggf. verkürzen (Minimum ist 15 Minuten).

 

... und die DCs zu den entsprechenden AD-Standorten verschieben.

 

Jaja, iss ja schon gut. Bin schon wech. ;)

[dmetzger 10]

... und die DCs zu den entsprechenden AD-Standorten verschieben.

 

Ja,ja, ja, Du hast Recht. Das machen wir beide zwar im Schlaf, doch der Präzision wegen ist es dem TO gegenüber notwendig, diesen Punkt zu ergänzen.

 

Jaja, iss ja schon gut. Bin schon wech.

 

Nein, bleib noch ein bisschen. Du warst Diese Woche viel zu wenig hier. :cry:

 

Off-Topic:

Yusuf, ich erwische mich schon dabei, bei jedem Beitrag zu überlegen, wie Du ihn wohl formulieren würdest. Diese Challenge macht mir Spass im kollegialen Sinn!

[Daim 12]

Ja,ja, ja, Du hast Recht.

 

Ich weiß. :cool:

 

Das machen wir beide zwar im Schlaf, doch der Präzision wegen ist es dem TO gegenüber notwendig, diesen Punkt zu ergänzen.

 

Ich denke, sogar der TO hätte daran im Schlaf gedacht. ;)

Aber wie du es bereits geschrieben hast, ich wollte es nicht unerwähnt lassen. :)

 

Nein, bleib noch ein bisschen. Du warst Diese Woche viel zu wenig hier. :cry:

 

Ja, ja, frag' bloß nicht. Ich glaube hierzulande nennt man das so: Ich hatte ziemlich viel um die Ohren. Ja ich weiß, dass ist wirklich "unerhört". Einem Südländer "so" etwas zuzumuten. :D Aber das wird sich bessern (müssen), sonst kündige ich und wandere in die Schweiz aus.

 

Off-Topic:

Yusuf, ich erwische mich schon dabei, bei jedem Beitrag zu überlegen, wie Du ihn wohl formulieren würdest. Diese Challenge macht mir Spass im kollegialen Sinn!

 

Off-Topic:

Das hast du/ich Nils zu verdanken (ohne das böse zu meinen). Jahrelanges zusammenarbeiten in den NGs hat mich zu dem gemacht, was ich heute bin. Und ich bin stolz darauf! ;)

[NilsK 2.792]

Moin,

 

Aber in dem Fall würde doch bei Ausfall der WAN / VPN Verbindung der Server gar nichts mehr auflösen können?

 

jein. Für die beiden DNS-Server träfe das zu, aber auch nur für die. Alle Clients und die anderen Server in der Außenstelle würden ja die beiden lokalen DNS-Server fragen.

 

Wenn man also davon ausgeht, dass die WAN-Verbindung innerhalb der DNS-Cache-Lebensdauer wieder da ist, hat das Design seine Berechtigung.

 

Müsst ich dann als 3. DNS Server zumindest nicht ihn selber eintragen?

 

Dann könntest du gleich die bei faq-o-matic.net favorisierte Variante nutzen ("zweiter DNS ist lokal"), denn in dem Fall hättest du ja gerade nicht mehr das von Daniel angesprochene einheitliche Design über alle Server.

 

Die Clients an den Außenstellen bekommen aber dann schon den DNS Server des jeweiligen Standortes?!

 

Selbstverständlich. Sonst könnte man sich den lokalen Dienst ja auch ganz sparen ...

 

Gruß, Nils

[micha42 29]

Wiederspruch. Die beiden DNS am Hauptstandort zeigen kreuzweise primär auf den jeweils anderen Server am Hauptstandort und sekundär auf sich selbst.(...).

Diese Konfiguration ist m.E. richtig, hat bei mir aber schon mal Probleme ausgelöst.

Bei einem "geplanten" Stromausfall hatte ich die Server heruntergefahren.

Die beiden DC (mit DNS) wieder anzuwerfen hat a) lange gedauert b) noch jeweils 2 Neustarts gebraucht und c) meine Nerven daher arg strapaziert.

Also in einem solchen Fall vorher die Konfiguration ändern. Wenn man dann noch dran denkt; tut man nicht; aber dann weiß man zumindest, dass das langsame hochfahren der Server nix schlimmes ist.

Michael

[NilsK 2.792]

Moin,

 

der Hinweis ist berechtigt - aber das Herunterfahren eines ganzen Standorts ist immer eine besondere Situation, die auch besonders geplant werden sollte. Beliebt sind dabei auch andere Abhängigkeiten, z.B. zwischen Sharepoint und dem SQL Server.

 

Gruß, Nils