Gute Namen / Schlechte Namen

Best Practice

Active Directory-Domänen mit dem offiziellen Domänennamen mit vorangestellter Sub-Domäne betreiben.

Mein Leben wurde nicht gerade einfacher, als Microsoft selbst als Domänenname die „.local“-Variante in verschiedenen Whitepapers zelebrierte. Seit diesem Zeitpunkt bin ich meine Kursteilnehmer und Kunden am missionieren, genau eben diese Art der Domänen-Benennung nicht zu verwenden. Damit ich künftig einfach auf mein Buch verweisen kann, als dies immer und immer wieder zu erklären, möchte ich mit Ihnen gerne einen kurzen Exkurs über „gute Namen / schlechte Namen“ unternehmen:

Internet-Domäne = ADS-Domäne

Bei dieser Variante erhält die Active Directory-Domäne denselben Namen, wie denjenigen, den die Unternehmung auch im Internet trägt. Wenn also unser Internetauftritt unter der Internet-Domäne „itrain.ch“ läuft, dann würden wir in diesem Beispiel auch unsere ADS-Domäne „itrain.ch“ benennen.

Damit externe Benutzer, welche nur auf unsere Website zugreifen möchten keine weiteren internen Informationen erhalten, sollten die beiden gleichlautenden Zonen auf zwei verschiedenen DNS-Servern betrieben werden. Bis dahin wäre es also kein Problem, einen solchen Namen zu wählen, da die beiden gleichlautenden DNS-Zonen ohne weiteres auf verschiedenen, unabhängig voneinander konfigurierten DNS-Servern betrieben werden können.

Da es sich beide Male um denselben Namensraum und somit um dieselbe Zone unter DNS handelt, stehen diese in Konflikt zueinander. Je nachdem, welcher DNS-Server nach einer Information unterhalb der Zone „itrain.ch“ angefragt wird, stellt dieser andere Informationen bereit. Der eine DNS-Server kennt die internen Informationen, welche auch für den Betrieb von Active Directory relevant sind und der andere DNS-Server kennt den Web- und den Mail-Server, etc. Allen internen Clients müssen wir zwingend einen DNS-Server angeben, welcher die Domäneninformationen enthält und alle Besucher unserer Website aus dem Internet fragen unseren externen DNS-Server ab. Genau bei dieser Sache liegt nun unser Problem: Wenn ein interner Client unserer Domäne z.B. auf unsere Website zugreifen möchte, ist dies nicht möglich, da unser interner DNS-Server keinerlei Informationen dazu hat (er besitzt keinen A (Host)-Eintrag namens „www“, welcher einen Namen in eine IP-Adresse auflöst). Wie man das umgehen könnte? Lassen wir uns ein bisschen mit verschiedenen Lösungsansätzen spielen:

Wir geben jedem Client über DHCP die IP-Adressen der zwei verschiedenen DNS-Server mit!

Falsch! Wenn ein Client einen DNS-Server nach einer Information abfragt und dieser keine Antwort ermitteln kann, hüllt sich dieser nicht in Schweigen, sondern teilt dem anfragenden Client mit, dass es diesen Namen nicht gibt. Die Antwort: „kenne ich nicht“ ist demnach auch eine Antwort ist. Sobald ein DNS-Client eine Antwort erhält, ist er zufrieden und würde nie auf die Idee kommen, den alternativen DNS-Server auch noch zu belästigen. Der alternative DNS-Server kommt ausschliesslich dann ins Spiel, wenn der bevorzugte DNS-Server nicht erreichbar ist und somit wirklich keinen Laut von sich gibt.

Als Faustregel bei der Konfiguration von DNS-Clients lautet demnach: Wenn man aus Gründen der Fehlertoleranz mehrere DNS-Server angeben möchte, dann sollten alle DNS-Server auch gleich viel Informationen über die Namensräume haben und vor allem keine widersprüchlichen Informationen abgeben.

Wir konfigurieren auf dem internen DNS-Server einfach eine generelle Weiterleitung, eine bedingte Weiterleitung oder eine Stub-Zone von „itrain.ch“!

Falsch! Auch dieses Szenario ist nicht möglich! DNS-Server haben ein sehr grosses Ego – d.h. wenn diese für einen Bereich die Verantwortung übernehmen (was mit der Konfiguration einer Zone passiert), dann kennen diese den zugewiesenen Bereich auch bis ins Detail. Es erübrigt sich also, die Anfrage weiterzuleiten, da der DNS-Server ja schon eine Antwort gehabt hätte, wenn es diesen Eintrag gäbe.

Ein weiteres Beispiel aus dem echten Leben: Nehmen wir einmal an, Sie kennen die Fussball-Regeln aus dem „FF“ und es fragt Sie jemand danach, was ein „Golden Goal“ ist. Da es diese Regel nicht mehr gibt, haben Sie auch keine Kenntnis darüber und geben als Antwort, dass diese Regel nicht existiert. Dies machen Sie mit einer solchen Überzeugungskraft, dass der Fragende nicht einmal auf die Idee käme, noch eine andere Person danach zu fragen, da dies ja auch ihr Fachgebiet ist.

Eine Weiterleitung (generell oder bedingt) würde demnach nie greifen, da wir ja schon alle Informationen über die Zone „itrain.ch“ haben. Eine bedingte Weiterleitung könnte man gar nicht erst einrichten, da diese Bedingung mit einer konfigurierten Zone in Konflikt stehen würde. Bei einer Stub-Zone sieht das genau gleich aus: Auch hier wäre es ein Namenskonflikt mit einer anderen Zone.

Wir konfigurieren einen A (Host)-Eintrag auf dem internen DNS-Server, welcher die notwendigen IP-Adressen der externen Server (Web, Mail, etc.) auflösen kann.

Richtig! So würde es funktionieren. Aus dieser Vorgehensweise geht jedoch auch hervor, dass es ziemlich aufwändig ist, dies so einzustellen. Zudem müssten bei Änderungen der Adressen auch diese Informationen immer wieder nachgeführt werden.

Wenn es also eine bessere Variante der Namensgebung gibt, dann sollte diese auch gewählt werden! Und diese gibt es, wie Sie später in diesem Abschnitt sehen werden.

NetBIOS-Name = DNS-Domänenname

Diese Variante den DNS-Namen einer Domäne so zu benennen, wie den NetBIOS-Namen der Domäne, stellt wohl die schlechteste Alternative dar (NetBIOS-Name = „ITRAIN“, DNS-Domänenname = „itrain“ – ohne Erweiterung)! Zum Glück ist diese Namensgebung in den neuesten Windows-Versionen gar nicht mehr möglich.

Vorsicht

Schon unter Windows 2000 Server hat dies spätestens nach der Installation von SP2 zu massiven Problemen geführt, da ein Domänencontroller plötzlich nicht mehr wusste, ob es sich bei diesem Namen nun um einen Computer- oder einen Domänennamen handelt. Die DCs haben sich also einfach nicht mehr miteinander repliziert.

Der Fachbegriff für diese Namenswahl (wenn man da wirklich von „Fach“ sprechen kann) lautet: Single-Label Domäne – also ein einstufiger Domänenname. In einer solchen Situation kann nur noch ein Registry-Hack Abhilfe schaffen, welcher unter dem Such-Stichwort „Single-Label Domain“ im Internet gefunden werden kann. Jedoch ist auch in diesem Falle dringend zu raten, die Domäne umzubenennen. Dies geschieht am besten durch einen Neuaufbau der Infrastruktur, da hier auch das Ressource-Kit Tool „rendom.exe“ (Rename Domain) seine liebe Mühe damit hat.

Vorsicht

Das Ressource Kit-Tool „rendom.exe“ dient zum Umbenennen eines Domänennamens. Dieses kann jedoch keineswegs einfach so mit den Parametern „alter Name“ und „neuer Name“ aufgerufen werden. Vielmehr muss dieser Befehl mehrfach mit verschiedenen Parametern zur Ausführung gelangen, eine daraus resultierende XML-Datei muss angepasst werden und es ist ein Reboot aller Domänencontroller der Gesamtstruktur notwendig. Zudem sollte dieses Tool mit Vorsicht eingesetzt werden, falls sich ein Exchange- oder SQL-Server in der Domäne befindet, welche umbenannt werden soll. Kurz zusammengefasst keine Sache, die man am Montag-Morgen erledigen sollte!

 

*.local = ADS-Domäne

Kommen wir langsam zur weitverbreitetsten Variante eines Domänennamens: den „Locals“. Damit sind jegliche Domänen-Namen gemeint, welche über eine nicht offizielle Endung verfügen.

Diese Art der Namensgebung steht zwar niemals im Konflikt mit einem externen Internet-Domänennamen – bietet jedoch gleichzeitig auch wenig Flexibilität, falls einmal eine direkte Erreichbarkeit erreicht werden soll.

Hinweis

Nehmen wir einmal an, dass künftig aus irgendeinem Grund, interne Ressourcen aus dem Internet über einen Namen angesprochen werden sollen: Dies wäre dann schlichtweg unmöglich. Zudem wäre es auch schöner, wenn der interne Domänenname an den extern gültigen Namen angelehnt wäre.

Grundsätzlich kann man sagen, dass diese Art der Namensgebung gar nicht so falsch ist – jedoch mit einer offiziellen Domänen-Endung eleganter gelöst werden könnte. Dieser ADS-Domänenname darf dann jedoch nicht in Konflikt mit dem offiziellen Internet-Domänennamen stehen, was jedoch im folgenden Abschnitt beschrieben wird.

Vorsicht!!!

Die Einschränkungen – v.a. bei der Verwendung von Zertifikaten, welche zwingend denselben Namen tragen müssen, wie der interne Computer – sind frappant. Es macht somit KEINEN Spass RADIUS z.B. für die Wireless-Authentifizierung einzurichten, bei welchem das Zertifikat überprüft werden soll. Dieses muss auf den effektiven internen Computer-Namen (den FQDN) lauten, was so bei "local"-Domains nicht funktioniert. Und dies ist nur ein Beispiel von vielen…

Vorsicht zum Zweiten!!!

"local"-Domains sind grundsätzlich für den mDNS-Standard reserviert, welcher momentan noch im Draft-Status ist. Wenn dieser Standard umgesetzt wird (was sehr gut aussieht), so werden jegliche Namensauflösungsanfragen für ".local"-Namen an eine vordefinierte Multicast-Adresse (anstatt an den DNS-Server) gesendet. Bis dahin muss sich Microsoft eine gute Lösung dafür einfallen lassen, da diese Art der Auflösung sonst nicht mehr für eine Windows-Domäne passen wird… Mehr Infos dazu unter diesem Link: http://files.multicastdns.org/draft-cheshire-dnsext-multicastdns.txt

Vorsicht zum Dritten!!!

Wenn "local" – dann wirklich NUR "local"! Jegliche anderen Top Level-Domänen, welche noch nicht offiziell registrierbar sind, könnten es einmal werden (z.B. "ad" oder "int", welche es schon wurden). Wenn einem dann diese neue Domäne nicht gehört und ein offizielles Zertifikat bestellt werden soll, hat man definitiv ein Problem…

Zu allem anderen ist eine "local"-Domäne einfach nicht professionell und man sollte sich als guter Informatiker schon deshalb davon distanzieren… Wenn das noch eine Altlast sein sollte, weil Microsoft "himself" das einmal sogar in seinen Assistenten erwähnte, dann OK – aber neue Domänen heissen definitiv nicht so!!!

Subdomäne.Internet-Domäne = ADS-Domäne

In den vorherigen Abschnitten wurde schon viel über Namenskonzepte gesprochen, welche nicht angewendet werden sollten. Nur was ist nun der richtige Weg, um eine sinnvolle Namensgebung für die Active Directory-Domäne zu erreichen?

Für mich ist es „Best Practice“, dem offiziellen Internet-Domänennamen, eine Sub-Domäne voranzustellen. Wenn der offizielle Name „itrain.ch“ lautet, dann könnte der Name der Active Directory-Domäne z.B. „office.itrain.ch“, „ads.itrain.ch“ oder gar „local.itrain.ch“ lauten. Mit dieser Variante verbauen wir uns keine künftig evt. benötigten Bedürfnisse, wir stehen nicht im Konflikt mit dem offiziellen Namen und wir verwenden keinen Single-Label Domain.

Best Practice

Bei der Verwendung einer Sub-Domäne für die Benennung der internen Active Directory-Umgebung muss keineswegs eine Delegierung von der übergeordneten Domäne aus erfolgen! Diese kann komplett unabhängig zur offiziellen Namensauflösung betrieben werden, ohne sich jedoch diese Möglichkeit komplett zu verunmöglichen. Diese Benennungsform einer Active Directory-Domäne ist übrigens auch die empfohlene Art unter Windows Server 2008 (endlich)!

VN:F [1.9.22_1171]
Rating: 9.0/10 (10 votes cast)
VN:F [1.9.22_1171]
Rating: +6 (from 6 votes)
Gute Namen / Schlechte Namen, 9.0 out of 10 based on 10 ratings

7 Gedanken zu “Gute Namen / Schlechte Namen

  1. Ich bin ein Verfechter der „*.local = ADS-Domäne“ Strategie (gut kann auch *.msft sein ;-), weil es dadruch eine saubere Trennung von intern und extern gibt.
    Wie stelle ich bei der „Subdomäne.Internet-Domäne = ADS-Domäne“ Strategie sicher, dass die internen Benuzter die „www.internet-domäne“ auflösen kann. Ich sehe da, keine Lösung.

  2. Hi Stefan ;-D

    Das wäre nur dann ein Problem, wenn der interne Domänenname gleichlautend wäre, wie der offiziell genutzte Domänenname (e.g. „itrain.ch“ intern und „itrain.ch“ extern). Somit stünden diese beiden Zonen im DNS (intern vs. extern) in Konflikt. Deshalb habe ich in diesem Artikel auch erwähnt, dass es KEINE gute Idee ist, die beiden Domänen (Internet und Intern) gleich zu benennen. Wenn jedoch die interne Domäne eine Subdomäne der offiziellen Internetdomäne darstellt, ist dies überhaupt KEIN Problem. Der interne DNS ist für die Auflösung von z.B. „edu.itrain.ch“ zuständig, welche NUR intern verwendet wird und der externe DNS ist für den Namensraum (die Zone) „itrain.ch“ zuständig. Falls nun ein Client den internen DNS (DC) nach „www.itrain.ch“ abfragt, dann schaut dieser zuerst einmal nach, ob er für die Zone „itrain.ch“ oder „www.itrain.ch“ (falls eine solche Zone konfiguriert sein sollte) zuständig ist. Falls nicht, dann leitet er die DNS-Abfrage entweder an einen Weiterleitungsserver weiter oder löst diese iterativ über die Root-Server, etc. auf.

    Somit ist das immer noch meine bevorzugte und die allgemein beste Lösung, welche ich hier anpreise ;-D

    Grüessli

    André

  3. Hi André,
    Ich hatte einen Überlegungsfehler drin. Ich dachte, dass wenn der DNS Server für edu.itrain.ch autorathiv ist, dann würde er kein „Forewarding“ für itran.ch machen. „Manchmal_bin_ich_echt_blond“. Aber ich lasse auch deine Meinug gelten, aber ich finde contoso.msft immer noch besser 😉
    Gruss
    Stefan
    BTW: Ich wusste schon vorher was eine Stubzone ist, aber DNS Vortrag war an der Geekmanina war trotzdem unterhaltsam 😉
    Gruus Stefan

  4. Danke André, Du hast mich mit der „Subdomäne.Internet-Domäne = ADS-Domäne“ Methode überzeugt, die M$ Empfehlung über die Zonen-Planung ist haarsträubend, dringend zu empfehlen ist, das man sich bevor man eine ADS-Domäne aufbaut, als erstes „DNS and BIND“ von O’REILLY zur Brust nehmen sollte, schaden kann’s auf keinen fall !! auch in der POSIX Welt wird abgeraten, was M$ als Empfehlung von sich gibt!
    VG Donkey

  5. Hallo André,

    danke für den kurzen Blog, er wird mir viele Stunden nochmalige Arbeit erleichtern! Seit vielen Jahren setze ich mal wieder eine AD auf und habe mir für den WS2008R2 passende Literatur gekauft. Wie immer kam das Bollwerk erst nach dem ersten basteln…

    Ich habe die AD als Subdomain unserer bei einem Provider gehosteten Domain aufgesetzt, dazu brav einen A-Record Eintrag beim Provider vorgenommen und fand mich voll toll das ich es logisch abgearbeitet habe. Dann kam das Buch und warnte!!!!! ausdrücklich davor die eigene TLD als Domäne einzutragen, dies wäre nur mit Schwierigkeiten etc verbunden, alles ganz lapidar in einem Nebensatz erwähnt.
    Ich hatte schon wieder schlaflose Nächte, sah mich von vorne beginnen. Fragte mich warum immer noch so blöde „local“ Endungen verwendet werden müssen, obwohl es mittlerweile viele Webanwendungen fürs Firmennetz gibt und dieser Mißstand immer noch nicht behoben sei.

    Also habe ich mich heute an meinem freien Tag mal auf die Suche nach sinnvollen FQDN für eine Domäne gemacht. Dabei stieß ich dann auf deinen Blog und nun wieder stolz wie bolle, alles richtig gemacht zu haben. Denn nur so ergibt es meiner Meinung nach Sinn. Jetzt bin ich offen und flexibel für allen Seiten des Internet und Intranet.

    Lediglich der internet A-Record Eintrag mit Verweis auf den DNS des Providers hat mir noch zum perfekten Glück gefehlt, obwohl es total logisch ist und ich auch selber drauf kommen hätte sollen. Aber egal. Danke auf jeden Fall für diesen wirklich wichtigen Beitrag.

    Michael

  6. Hallo André

     

    Was mir aber immer noch etwas Kopfzerbrechen macht, ist die vorgehensweise beim erstellen einer neuen Domain.

     

    Wenn ich z.B. eine Firma abbilden möchte und dazu gleich noch eine Testumgebung dann wäre dies nach deinem Blog ja z.B. ads.company.com für die interne Domain und z.B. test.company.com für die Testumgebung.

    Wie beginne ich denn nun mit der Installation?

    Direkt mit ads.company.com oder erstelle ich als erstes eine Domain company.com und ads und test als Subdomain?

     

    Kannst Du da etwas Licht ins dunkle bringen?

     

    Wäre Dir sehr dankbar.

    Danke und Gruss Stefan

     

      

Schreib einen Kommentar