Czy inżynieria powinna mieć własną strefę DNS, delegować lub subdomenę?

Mamy podstawową domenę naszej organizacji (z AD) przyklad.com. W przeszłości poprzedni administratorzy utworzyli kilka innych stref - takich jak dmn.com, lab.example.com, dmn-geo.com itd. - a także poddomeny i delegaci, z których wszystkie są przeznaczone dla różnych grup inżynieryjnych. Nasz DNS jest teraz trochę bałaganu. I oczywiście powoduje to problemy, gdy ktoś na stacji roboczej w example.com musi połączyć się z systemem w którejkolwiek z tych innych stref / subdomen lub odwrotnie (częściowo dlatego, że transfer strefy i delegowanie strefy nie są odpowiednio skonfigurowane dla większości z nich) .

Nasz produkcyjny DNS jest zintegrowany z Active Directory, ale systemy inżynieryjne powinny być odizolowane od AD.

Omawiamy sposoby reorganizacji DNS i konsolidacji wszystkich tych różnych pozycji. Widzę trzy różne ścieżki, które możemy podjąć:

• Utwórz nową strefę, tj. „Dmn.eng”. Może to być zarządzane przez dział IT za pomocą naszych serwerów DNS lub inżynieria za pomocą ich serwerów nazw.
• Utwórz nowego delegata eng.example.com, skonsoliduj inżynieryjny DNS w tej subdomenie i pozwól inżynierom zarządzać serwerem nazw dla delegata.
• Utwórz nową subdomenę eng.example.com bez delegacji i sami zarządzaj DNS dla subdomeny.

Opowiadam się za utworzeniem subdomeny delegowanej i pozwoleniem inżynierom na pełną kontrolę nad własną strukturą DNS w ramach tej subdomeny. Zaletą jest to, że jeśli ich DNS nie działa, najprawdopodobniej to nie moja wina;). Jednak nadal istnieje pewna dwuznaczność dotycząca odpowiedzialności, gdy coś nie działa i będzie wymagała koordynacji z inżynierią w celu skonfigurowania, skonfigurowania i administrowania.

Jeśli nie delegujemy poddomeny, oznacza to o wiele więcej pracy dla produkcyjnego działu IT obsługującego nieprodukcyjne DNS (co w zasadzie już dużo robiliśmy). Zaletą jest to, że mamy pełną kontrolę nad całym systemem DNS, a gdy coś nie działa, nie ma wątpliwości, czyją odpowiedzialność to naprawić. Możemy również dodawać delegatów, takich jak geo.eng.example.com, aby zapewnić inżynierom większą elastyczność i kontrolę, gdy tego potrzebują.

Naprawdę nie jestem pewien, czy konieczne jest stworzenie nowej strefy dmn.eng.

Jakie są najlepsze praktyki i zalecenia branżowe w takich sytuacjach? Jakie rozwiązanie byłoby najłatwiejsze do wdrożenia i zapewniłoby bezproblemowe rozpoznawanie nazw między inżynierią a produkcją? Jakie są potencjalne korzyści lub pułapki dla każdego rozwiązania, którego może mi brakować?

Aby dodać trochę więcej informacji, jesteśmy dość dużą firmą produkcyjną. Ci inżynierowie pracują w dziale badań i rozwoju, rozwoju i kontroli jakości. Laboratoria często mają własne podsieci lub całe sieci, DHCP itp. Jeśli chodzi o organizację i technologię, są one swego rodzaju małym światem.

Chcemy utrzymać pewien poziom izolacji sieci dla laboratoriów inżynieryjnych i sieci w celu ochrony naszego środowiska produkcyjnego (odwołaj się do wcześniejszego pytania dotyczącego inżynierów, którzy dodali inżynierskie serwery DHCP jako autorytatywne serwery AD DHCP - to nie powinno być możliwe). Jednak użytkownik na stacji roboczej w laboratorium będzie musiał uzyskać dostęp do zasobu w naszej sieci produkcyjnej lub użytkownik na stacji roboczej w naszej sieci produkcyjnej będzie musiał połączyć się z systemem laboratoryjnym, a dzieje się to z wystarczającą częstotliwością, aby uzasadnić sortowanie -jednolity DNS.

Obecni delegaci mają już serwery DNS zarządzane inżynieryjnie, ale nie ma komunikacji między inżynierami w różnych laboratoriach, w których te serwery są skonfigurowane, więc najczęstszym problemem jest nieudane rozpoznawanie nazw między poddomenami. Ponieważ inżynierowie są właścicielami tych serwerów delegowanych, nie mogę poprawić wpisów NS, aby rozmawiały ze sobą - stąd korzyść polegająca na tym, że DNS nie jest delegowany w całości przez IT. Jednak zarządzanie DNS dla produkcji i inżynierii jest uciążliwe, zwłaszcza że inżynieria może wprowadzać zmiany DNS codziennie. Ale jak wspomniał BigHomie w swojej odpowiedzi, prawdopodobnie oznacza to, że inżynierowie będą musieli zatrudnić (lub wyznaczyć) prawdziwego administratora DNS; i ta osoba i ja będziemy musieli się dość dobrze poznać.

Niekoniecznie podoba mi się pomysł stworzenia nowej strefy z dowolną nazwą domeny lub sufiksem najwyższego poziomu, ale mamy już 5 innych stref z dowolnymi nazwami, więc konsolidacja w jedną jest wciąż ulepszeniem. Wiem, że istnieją inne firmy, które mają oddzielne strefy najwyższego poziomu dla różnych grup w swojej organizacji, więc jestem ciekawy, kiedy jest to właściwe i jakie są zalety / wady tego podejścia.

Do Twojej wiadomości, pracuję w tej firmie dopiero od kilku miesięcy, a poprzedni administrator AD / DNS opuścił firmę, więc nie mam nic do wyjaśnienia, dlaczego istnieje jakakolwiek istniejąca struktura DNS.

W dzisiejszym świecie nie polecam tworzenia nowych stref z dowolnymi domenami najwyższego poziomu , ponieważ mogą one przekształcić się w „oficjalne dns” w dowolnym momencie.

Osobiście wolę scenariusz przekazania subdomeny, ponieważ wydaje się, że pasuje do tego, co próbujesz zrobić. (Konsoliduj, ale daj kontrolę inżynierii)

Być może uda ci się nawet znaleźć front-end dla MS DNS, w którym inżynieria mogłaby dodawać / usuwać rekordy, tak aby sam serwer był nadal własnością produkcyjnego działu IT, a jedyną rzeczą, którą „zarządzają”, są wpisy DNS.

Przede wszystkim upewnij się, że jesteś właścicielem domeny.tld, której planujesz używać (mit.edu). Nawet jeśli to nigdy nie łączy się z Internetem, nie o to chodzi.

Istnieje ogromna korzyść z posiadania hierarchii dns, która przynajmniej częściowo pasuje do organizacji. Widziałem to tylko wtedy, gdy ktoś / ludzie zarządzają tym działem w zakresie wsparcia IT. Odnosi się to do posiadania oddzielnych stref do celów AD. Adresy internetowe itp. Są osobnym tematem i nie będzie to miało zastosowania. Nie mam ani nie znam żadnych twardych i szybkich reguł dla hierarchii dns. Wierzę, że potrzeby twojej organizacji to podyktują. Niektóre strefy mogą wymagać poddomeny (eng.mit.edu), a niektóre nie (np. Hr.mit.edu). Oczywiście dla spójności powinna istnieć tylko jedna domena najwyższego poziomu.

Biorąc to pod uwagę, co decyduje o tym, czy oddział potrzebuje subdomeny, czy nie? Jeśli dotyczy to stacji roboczych, czy mają one własne wsparcie IT lub osoby zdolne do zarządzania takim systemem? Jeśli nie, to naprawdę nie ma sensu używać strefy dns do określania, że ​​maszyna jest w pewnym stanie, istnieje wiele innych metod, które dobrze wykonają to zadanie. To tylko pytania, które musisz sobie zadać.

Dokonałbym ponownej oceny każdej strefy i ustalił

1. Jeśli nadal jest to istotne. Czy w tej strefie nadal znajdują się serwery lub stacje robocze?

2. Kto będzie zarządzał nową strefą. Oczywiste jest, że strefa będzie musiała zostać przeniesiona do nowej hierarchii, ale czy po prostu implementujesz informacje o adresie / serwerze nazw dla strefy, czy aktywnie zarządzasz strefą?

Jakie systemy są „odizolowane” od AD? Czy nie będą wymagały uwierzytelnienia sieciowego i / lub zarządzania? Jaki jest powód ich oddzielenia od perspektywy DNS? Aby potwierdzić swoje podejrzenia, chodzi o łatwość zarządzania. Jeśli inżynieria potrzebuje takiej administracji dns, powinna sama uzyskać uprawnienia administratora DNS.

Aby dodać informacje na podstawie Twojej aktualizacji, osobiście podałbym im ich własną subdomenę eng.spacelysprockets.com, a także podsieć. Powinien być zaporę ogniową z pozostałej części sieci, umożliwiając odpowiedni ruch. Jeśli chcą odejść i stworzyć eng.eng.locallub eng.bikesnie możesz ich powstrzymać, nie powinieneś być zmuszony do wspierania tego *.

Jeśli dobrze się bawią, skorzystaj ze podstrefy i zdecyduj, że chcą się zerwać lab.eng.spacelysprockets.comoraz część podsieci, to na nich. Prawdopodobnie powinna to być profesjonalna uprzejmość, aby poinformować Cię, abyś mógł również segmentować ten ruch, ale nie wszyscy tak myślą.

Prawdziwa nazwa domeny dla twojej infrastruktury poważnie dałaby ci przewagę w zarządzaniu, powinieneś to rozważyć.

* Jeśli ty i czy będziesz dwie różne rzeczy, ale ja dygresję.