Wir haben die primäre Domain unserer Organisation (mit AD) example.com. In der Vergangenheit haben frühere Administratoren mehrere andere Zonen erstellt - wie z. B. dmn.com, lab.example.com, dmn-geo.com usw. - sowie Subdomänen und Delegierte, die sich alle auf verschiedene Engineering-Gruppen beziehen. Unser DNS ist im Moment ein bisschen durcheinander. Dies führt natürlich zu Problemen, wenn jemand an einer Arbeitsstation in example.com eine Verbindung zu einem System in einer dieser anderen Zonen / Subdomänen herstellen muss oder umgekehrt (teilweise, weil die Übertragung und Delegierung von Zonen für die meisten von ihnen nicht ordnungsgemäß konfiguriert ist). .
Unser Produktions-DNS ist in Active Directory integriert, Engineering-Systeme sollten jedoch von AD isoliert sein.
Wir diskutieren Möglichkeiten zur Reorganisation von DNS und zur Konsolidierung all dieser verschiedenen Einträge. Ich sehe drei verschiedene Wege, die wir einschlagen können:
- Erstellen Sie eine neue Zone, zB 'dmn.eng'. Dies kann entweder von der IT mithilfe unserer DNS-Server oder vom Engineering mithilfe ihrer Nameserver verwaltet werden.
- Erstellen Sie einen neuen Delegaten eng.example.com, konsolidieren Sie den Engineering-DNS in dieser Unterdomäne und lassen Sie die Ingenieure den Nameserver für den Delegaten verwalten.
- Erstellen Sie eine neue Subdomain eng.example.com ohne Delegierung und verwalten Sie den DNS für die Subdomain selbst.
Ich bevorzuge die Erstellung einer Delegierten-Subdomäne und überlasse den Ingenieuren die volle Kontrolle über ihre eigene DNS-Struktur innerhalb dieser Subdomäne. Der Vorteil ist, dass wenn ihr DNS nicht funktioniert, es höchstwahrscheinlich nicht meine Schuld ist;). Es besteht jedoch immer noch eine gewisse Unklarheit in Bezug auf die Verantwortung, wenn etwas nicht funktioniert, und die Einrichtung, Konfiguration und Verwaltung muss mit dem Engineering abgestimmt werden.
Wenn wir die Unterdomäne nicht delegieren, bedeutet dies viel mehr Arbeit für die Produktions-IT im Umgang mit nicht-produktivem DNS (wofür wir im Wesentlichen bereits viel getan haben). Der Vorteil ist, dass wir die volle Kontrolle über alle DNS haben und wenn etwas nicht funktioniert, besteht kein Zweifel darüber, wessen Verantwortung es ist, es zu beheben. Wir können auch Delegierte wie geo.eng.example.com hinzufügen, um dem Engineering mehr Flexibilität und Kontrolle zu geben, wenn es benötigt wird.
Ich bin mir wirklich unsicher, ob es notwendig oder vorteilhaft ist, eine neue Zone, dmn.eng, einzurichten.
Welche Best Practices und Empfehlungen der Branche gibt es für solche Situationen? Welche Lösung lässt sich am einfachsten implementieren und bietet eine nahtlose Namensauflösung zwischen Engineering und Produktion? Welche potenziellen Vorteile oder Fallstricke hat jede Lösung, die mir möglicherweise fehlt?
Um ein wenig mehr Informationen hinzuzufügen, sind wir ein ziemlich großes Produktionsunternehmen. Diese Ingenieure arbeiten in den Bereichen F & E, Entwicklung und Qualitätssicherung. Labore haben häufig ihre eigenen Subnetze oder ganze Netzwerke, DHCP usw. In Bezug auf Organisation und Technologie sind sie eine Art eigene kleine Welt.
Wir möchten ein gewisses Maß an Netzwerkisolation für technische Labors und Netzwerke aufrechterhalten, um unsere Produktionsumgebung zu schützen (siehe eine frühere Frage zu Ingenieuren, die technische DHCP-Server als autorisierende AD DHCP-Server hinzugefügt haben - das sollte nicht möglich sein). Ein Benutzer an einer Arbeitsstation in einem Labor muss jedoch auf eine Ressource in unserem Produktionsnetzwerk zugreifen, oder ein Benutzer an einer Arbeitsstation in unserem Produktionsnetzwerk muss eine Verbindung zu einem Laborsystem herstellen, und dies geschieht mit einer ausreichenden Häufigkeit, um eine Sortierung zu rechtfertigen -von Unified DNS.
Die vorhandenen Delegaten haben bereits DNS-Server, die vom Engineering verwaltet werden. Es besteht jedoch keine Kommunikation zwischen den Technikern in den verschiedenen Labors, in denen diese Server eingerichtet sind. Daher besteht das häufigste Problem in der fehlgeschlagenen Namensauflösung zwischen Subdomänen. Da die Ingenieure diese Delegierten-Server besitzen, kann ich die NS-Einträge nicht korrigieren, damit sie miteinander kommunizieren - daher der Vorteil von nicht delegiertem DNS, das sich vollständig im Besitz der IT befindet. Das Verwalten von DNS für Produktion und Engineering ist jedoch problematisch, zumal das Engineering täglich Änderungen an DNS vornehmen kann. Aber wie BigHomie in seiner Antwort erwähnt hat, bedeutet dies wahrscheinlich, dass das Engineering einen echten DNS-Administrator einstellen (oder bestimmen) muss. und diese Person und ich müssen uns ziemlich gut kennenlernen.
Die Idee, eine neue Zone mit einem beliebigen Top-Level-Domain-Namen oder Suffix zu erstellen, mag ich nicht unbedingt, aber wir haben bereits 5 andere Zonen mit beliebigen Namen, sodass die Konsolidierung zu einer einzigen noch eine Verbesserung darstellt. Ich weiß, dass es andere Unternehmen gibt, die separate Top-Level-Zonen für verschiedene Gruppen in ihrer Organisation haben. Daher bin ich gespannt, wann dies angemessen ist und welche Vor- / Nachteile dieser Ansatz hat.
Zu Ihrer Information, ich bin erst seit ein paar Monaten bei diesem Unternehmen und der vorherige AD / DNS-Administrator hat das Unternehmen verlassen. Daher kann ich nicht darauf verweisen, warum eine der vorhandenen DNS-Strukturen vorhanden ist.
Our production DNS is integrated with Active Directory, but engineering systems should be isolated from AD.Bei diesem Kommentar frage ich mich, ob Sie ehrlich gesagt in Betracht ziehen sollten, eine separate AD-Gesamtstruktur für das Engineering zu haben.