Daniel Kugler 10 Geschrieben 27. Dezember 2008 Autor Melden Teilen Geschrieben 27. Dezember 2008 So oft wie du mir jetzt schon den Link geschickt hast sollte ich doch mal die Seite intesiv studieren *fg* Dank dir wieder mal. Gruß Daniel Zitieren Link zu diesem Kommentar
gysinma1 13 Geschrieben 28. Dezember 2008 Melden Teilen Geschrieben 28. Dezember 2008 Hallo Zusammen Noch was zu DNS ... Microsoft empfiehlt bei schlechten Anbindungen die Verwendung von stubzones in den Branches (Aussenstandorte). Gruss Matthias Zitieren Link zu diesem Kommentar
Daniel Kugler 10 Geschrieben 28. Dezember 2008 Autor Melden Teilen Geschrieben 28. Dezember 2008 Guden Mathias, täusch ich mich jetzt oder wie? Stubzones sind doch ähnlich wie secundary Zones nur das in ihnen nur der SOA und die NS drin sind, damit spare ich dann aber doch nicht Traffic da jede Namensauflösung weitergeleitet wird, oder :confused: Gruß Daniel Zitieren Link zu diesem Kommentar
gysinma1 13 Geschrieben 28. Dezember 2008 Melden Teilen Geschrieben 28. Dezember 2008 Hallo Mal etwas zu Stubzones: Grundlegendes zu Stubzonen Doch Du sparst traffic, denn Du sparst Dir den Replikationsverkehr der DNS Partitionen, was deutlich mehr ist, als die punktuellen NSlookups. Zudem die Queries noch gecached werden. Microsoft empfiehlt Stubzones ausdrücklich für solche Konstellationen. Gruss Matthias Zitieren Link zu diesem Kommentar
Daniel Kugler 10 Geschrieben 28. Dezember 2008 Autor Melden Teilen Geschrieben 28. Dezember 2008 Cool Danke Gysinma1 ;-) Ich bin immer mehr zufrieden hier mit dem Forum. Man bekommt gute und vorallem schnelle antworten. Mittlerweile ist es soweit das ich schon hier nach Lösungen suche und andere Berichte lese. Anfangs war es für Prüfungsvorbereitung gedacht. Zitieren Link zu diesem Kommentar
collapse 10 Geschrieben 28. Dezember 2008 Melden Teilen Geschrieben 28. Dezember 2008 Also wenn du sagst jede Minute Traffic kostet dir nen "*****" voll Geld dann empfehle ich dir dringlichst WAN Acceleration Appliances einzusetzten. Z.b. Riverbed. Zitieren Link zu diesem Kommentar
Daniel Kugler 10 Geschrieben 28. Dezember 2008 Autor Melden Teilen Geschrieben 28. Dezember 2008 Damit will ich mich auch noch beschäftigen, habe ich hier zum ersten mal von gehört. Zitieren Link zu diesem Kommentar
Daniel Kugler 10 Geschrieben 30. Dezember 2008 Autor Melden Teilen Geschrieben 30. Dezember 2008 Servus, ich bins mal wieder ;-) Ich bin das ganze jetzt soweit mal am simulieren in ner VM oder besser gesagt mehren :D Nun meine Frage. Da ich ja 3 IP Subnetze habe aber nur eine Domäne wie richte ich DNS am geschicktesten mit den verschieden Zonen ein. Ich dachte mir Forward auf dem ersten DC im erstem Standort eine primary AD integriete Zone, auf den DCs in den den anderen Standorten Stubzones. Aber wie sieht das ganze Reverse aus? In jedem Standort auf einem DC eine primary für das jeweilige Netz und in den anderen Standorten für dieses Netz eine Stubzone. Oder soll ich besser mit Deligierungen arbeiten? Ist das machbar? Gruß Daniel EDIT: Ok das mit den Primary und Stubs wie oben geplant scheint wohl so icht zu funktionieren. Wie mache ich das am besten? Zitieren Link zu diesem Kommentar
gysinma1 13 Geschrieben 30. Dezember 2008 Melden Teilen Geschrieben 30. Dezember 2008 Hallo Ich würde mich da mal zuerst hinter die Literatur setzen. Das mit den Stubzones funktioniert bestens, wenn es richtig verwendet wird. Riverbed haben wir auch im Einsatz hatten diverse ganz üble Geschichten weil wir den ldap Verkehr unter den DC cacheden. Wir mussten diesen exkluden (Zusammen mit Riverbed und MS) und seither läuft es gut. Hier ist ein Link, wo das alles beschrieben ist, wie man nach MS best practice ein Branchoffice aufbaut. Microsoft Corporation Nimm es mir nicht übel, aber mit Try and Error werdet Ihr das nicht schaffen. Gruss Matthias Zitieren Link zu diesem Kommentar
NilsK 2.971 Geschrieben 30. Dezember 2008 Melden Teilen Geschrieben 30. Dezember 2008 Moin, bei deiner relativ kleinen Umgebung verursacht DNS mit Sicherheit keinen nennenswerten Replikationsverkehr. Daher solltest du "ganz normal" die DNS-Zone in AD integrieren und komplett auf alle DCs replizieren lassen. Alle DCs sollten DNS-Server sein. Die Reverse-Zone würde ich genauso anlegen. In AD definierst du dann jeden Standort als Site und ordnest die jeweiligen Subnets zu. Gruß, Nils Zitieren Link zu diesem Kommentar
Daniel Kugler 10 Geschrieben 30. Dezember 2008 Autor Melden Teilen Geschrieben 30. Dezember 2008 Nimm es mir nicht übel, aber mit Try and Error werdet Ihr das nicht schaffen. Da gebe ich dir recht, Literatur studieren ist wichtig aber ich kann nicht alles nur lesen. Übung gehört dazu und dadurch so denke ich lerne ich mehr als nur durch das stumpfe lesen. Danke für den Link, scheint echt interessant zu sein. Werde ich mir mal genauer ansehen. Die Reverse-Zone würde ich genauso anlegen. Danke ich werde es dann mal probieren. Artikel habe ich nicht wirklich viele dazu gefunden. Einen bei MS über subneting in der Reverse und sonst viel über Unix/Linux mit den jeweiligen Dateien. Zitieren Link zu diesem Kommentar
Daniel Kugler 10 Geschrieben 1. Januar 2009 Autor Melden Teilen Geschrieben 1. Januar 2009 So also ich habe jetzt soweit alles eingerichtet und es läuft super. - 1 Domäne - 2 Standorte - Primary Revers AD integriete Zone im jeweiligen Standort und Stubzones AD integriert in dem anderem Standort. Jetzt habe ich neh Frage zu dem sogenannten INSELproblem. Ist es nötig das ich den DNS des anderen Standortes als bevorzugten DNS-Server angebe? Ich denke nein wollte aber nochmal hier auf die Fachexpertise zurückgreifen ;-) Gruß Daniel Zitieren Link zu diesem Kommentar
NilsK 2.971 Geschrieben 1. Januar 2009 Melden Teilen Geschrieben 1. Januar 2009 Moin, das Stubzone-Konzept verstehe ich noch nicht ganz. Du hast einen Standort mit "vollständigen" DNS-Daten und einen mit einer Stubzone? Das würde ich bei der Größe der Umgebung wirklich nicht machen. Der Replikationsverkehr rechtfertigt das nicht. Falls du an einem Standort nur eine Stubzone hast, gibt es kein Inselproblem. Die Stubzone hält ja gar keine Daten. Gruß, Nils Zitieren Link zu diesem Kommentar
Daniel Kugler 10 Geschrieben 1. Januar 2009 Autor Melden Teilen Geschrieben 1. Januar 2009 Also ich habe eine Primary AD int. Forward Zone im Standort A, im Standort B die dazugehörige AD int. Stub Zone. Da ich verschiedene Subnets habe 10.10.7.0 & 10.10.8.0 habe ich am Standort A eine primary AD int. Revers und am Standort B die dazugehörige AD int. Stub für das Netz 10.10.7.0. Am Standort B habe ich eine Primary AD int. Revers für 10.10.8.0 und im Standort A die dazu passende AD int. Stub. Mal etwas zu Stubzones:Grundlegendes zu Stubzonen Doch Du sparst traffic, denn Du sparst Dir den Replikationsverkehr der DNS Partitionen, was deutlich mehr ist, als die punktuellen NSlookups. Zudem die Queries noch gecached werden. Microsoft empfiehlt Stubzones ausdrücklich für solche Konstellationen. Habe mich hierauf bezogen und das hört sich doch alles sehr sinnvoll an. Falls du an einem Standort nur eine Stubzone hast, gibt es kein Inselproblem. Die Stubzone hält ja gar keine Daten. Naja ich habe ja nicht "NUR" eine Stub Zone an einem Standort. Ist etwas verzwickt die Lage ;-) Zitieren Link zu diesem Kommentar
gysinma1 13 Geschrieben 2. Januar 2009 Melden Teilen Geschrieben 2. Januar 2009 Hallo Jaja das ist schon richtig mit den Stubzones und auch Microsoft best practice. In den Prüfungen 70-640 und 70-642 kommen dazu mehrere Fragen was die ideale Lösung für SlowWanLnik Branches sind. Der quantitative Content der ZonenDBs (also die Grösse) ist ja auch nicht das Kriterium, sondern, dass alle nach dem Replikationsintervall gerichtete Zeiten, diese Dbs replizieren obwohl diese klein sind. DNS Strukturen unter Windows 2003 http://download.microsoft.com/download/5/6/9/5695b3a2-bfbb-4638-8058-de94c3c5b7ff/06_CHAPTER_3_Deploying_DNS.doc Und hier hast Du noch mehr zu den Themen Netzwerkdienste. Download details: Windows Server 2003 Deployment Kit: Deploying Network Services Gruss Matthias Zitieren Link zu diesem Kommentar
Empfohlene Beiträge
Schreibe einen Kommentar
Du kannst jetzt antworten und Dich später registrieren. Falls Du bereits ein Mitglied bist, logge Dich jetzt ein.