Kỹ thuật nên có vùng DNS, đại biểu hoặc tên miền phụ riêng?

Chúng tôi có tên miền chính của tổ chức (với AD) example.com. Trước đây, các quản trị viên trước đây đã tạo ra một số khu vực khác - chẳng hạn như dmn.com, lab.example.com, dmn-geo.com, v.v. - cũng như các tên miền phụ và đại biểu tất cả đều dành cho các nhóm kỹ thuật khác nhau. DNS của chúng tôi ngay bây giờ là một chút lộn xộn. Và tất nhiên, điều này gây ra vấn đề khi ai đó tại máy trạm trong example.com cần kết nối với hệ thống ở bất kỳ khu vực / tên miền phụ nào khác hoặc ngược lại (một phần vì chuyển vùng và ủy quyền không được cấu hình đúng cho hầu hết trong số họ) .

DNS sản xuất của chúng tôi được tích hợp với Active Directory, nhưng các hệ thống kỹ thuật nên được cách ly khỏi AD.

Chúng tôi đang thảo luận về cách tổ chức lại DNS và hợp nhất tất cả các mục khác nhau này. Tôi thấy ba con đường khác nhau mà chúng ta có thể thực hiện:

• Tạo một vùng mới tức là 'dmn.eng'. Điều này có thể được quản lý bởi CNTT, sử dụng máy chủ DNS hoặc kỹ thuật của chúng tôi bằng cách sử dụng máy chủ tên của họ.
• Tạo một đại biểu mới eng.example.com, hợp nhất DNS kỹ thuật vào tên miền phụ đó và để các kỹ sư quản lý máy chủ tên cho đại biểu.
• Tạo một tên miền phụ mới eng.example.com không có ủy quyền và tự quản lý DNS cho tên miền phụ.

Tôi ủng hộ việc tạo một tên miền phụ ủy nhiệm và để các kỹ sư có toàn quyền kiểm soát cấu trúc DNS của riêng họ trong tên miền phụ đó. Ưu điểm là nếu DNS của họ không hoạt động, rất có thể đó không phải là lỗi của tôi;). Tuy nhiên, vẫn còn một chút mơ hồ về trách nhiệm khi một cái gì đó không hoạt động và nó sẽ yêu cầu phối hợp với kỹ thuật để thiết lập, cấu hình và quản trị.

Nếu chúng tôi không ủy quyền tên miền phụ, điều đó có nghĩa là sẽ có nhiều công việc hơn để sản xuất CNTT xử lý DNS không sản xuất (về cơ bản chúng tôi đã làm rất nhiều). Ưu điểm là chúng tôi có toàn quyền kiểm soát tất cả DNS và khi một cái gì đó không hoạt động, không có nghi ngờ gì về trách nhiệm của ai là sửa nó. Chúng tôi cũng có thể thêm các đại biểu, chẳng hạn như Geo.eng.example.com, để giúp kỹ thuật linh hoạt hơn và kiểm soát khi họ cần.

Tôi thực sự không chắc chắn về sự cần thiết hoặc lợi ích của việc tạo ra một khu vực mới, dmn.eng.

Vì vậy, các thực tiễn và khuyến nghị tốt nhất của ngành cho các tình huống như thế này là gì? Giải pháp nào là đơn giản nhất để thực hiện và cung cấp độ phân giải tên liền mạch giữa kỹ thuật và sản xuất? Một số lợi ích tiềm năng hoặc cạm bẫy cho mỗi giải pháp mà tôi có thể thiếu là gì?

Để thêm một chút thông tin, chúng tôi là một công ty sản xuất khá lớn. Những kỹ sư này làm việc trong R & D, Development và QA. Các phòng thí nghiệm thường có mạng con riêng hoặc toàn bộ mạng, DHCP, v.v. Liên quan đến tổ chức và công nghệ, chúng là loại thế giới nhỏ bé của riêng chúng.

Chúng tôi muốn duy trì một số mức độ cách ly mạng cho các phòng thí nghiệm kỹ thuật và mạng để bảo vệ môi trường sản xuất của chúng tôi (tham khảo một câu hỏi trước đó về các kỹ sư đã thêm máy chủ DHCP kỹ thuật làm máy chủ AD DHCP có thẩm quyền - điều đó không thể xảy ra). Tuy nhiên, người dùng tại máy trạm trong phòng thí nghiệm sẽ cần truy cập tài nguyên trong mạng sản xuất của chúng tôi hoặc người dùng tại máy trạm trên mạng sản xuất của chúng tôi sẽ cần kết nối với hệ thống phòng thí nghiệm và điều này xảy ra với tần suất đủ để chứng minh một loại -Trong DNS thống nhất.

Các đại biểu hiện tại đã có máy chủ DNS được quản lý bởi kỹ thuật, nhưng không có giao tiếp giữa các kỹ sư trong các phòng thí nghiệm khác nhau nơi các máy chủ này được thiết lập, do đó, vấn đề phổ biến nhất là không giải quyết được tên giữa các tên miền phụ. Vì các kỹ sư sở hữu các máy chủ được ủy quyền đó, tôi không thể sửa các mục NS để khiến chúng nói chuyện với nhau - do đó lợi thế của DNS không được ủy quyền hoàn toàn thuộc sở hữu của CNTT. Nhưng quản lý DNS cho sản xuất và kỹ thuật là một vấn đề đau đầu, đặc biệt là khi kỹ thuật có thể thực hiện thay đổi DNS hàng ngày. Nhưng như BigHomie đã đề cập trong câu trả lời của mình, điều này có lẽ có nghĩa là kỹ thuật sẽ phải thuê (hoặc chỉ định) một quản trị viên DNS thực sự; và người đó và tôi sẽ phải làm quen khá tốt.

Tôi không nhất thiết thích ý tưởng tạo một khu vực mới với một tên miền cấp cao nhất hoặc hậu tố, nhưng chúng tôi đã có 5 khu vực khác với các tên tùy ý nên việc hợp nhất thành một khu vực duy nhất vẫn là một cải tiến. Tôi biết rằng các công ty khác tồn tại có các khu vực cấp cao nhất cho các nhóm khác nhau trong tổ chức của họ, vì vậy tôi tò mò về việc khi nào thì phù hợp và những lợi thế / bất lợi của phương pháp đó là gì.

FYI, tôi mới chỉ ở công ty này được vài tháng và quản trị viên AD / DNS trước đó đã rời công ty, vì vậy tôi không có gì để tham khảo về lý do tại sao bất kỳ cấu trúc DNS hiện tại nào tồn tại.

Trong thế giới ngày nay, tôi không khuyên bạn nên tạo các khu vực mới với các tên miền cấp cao nhất tùy ý , vì chúng có thể biến nó thành "dns chính thức" bất cứ lúc nào.

Cá nhân tôi sẽ ủng hộ kịch bản ủy quyền tên miền phụ, vì nó có vẻ phù hợp với những gì bạn cố gắng làm. (Hợp nhất nhưng kiểm soát kỹ thuật)

Có thể bạn thậm chí có thể tìm thấy một web-end cho MS DNS nơi kỹ thuật có thể thêm / xóa các bản ghi, để bản thân máy chủ vẫn thuộc sở hữu của IT sản xuất và điều duy nhất "chúng" quản lý là các mục DNS.

Đầu tiên và quan trọng nhất, hãy đảm bảo bạn sở hữu domain.tld mà bạn dự định sử dụng (mit.edu). Ngay cả khi điều này không bao giờ kết nối với internet, đó không phải là vấn đề.

Có những lợi ích to lớn khi có một hệ thống phân cấp của dns mà ít nhất là phần nào phù hợp với tổ chức org. Tôi chỉ thấy điều này được thực hiện khi có ai đó / người quản lý bộ phận đó về mặt hỗ trợ CNTT. Điều này liên quan đến việc có các khu riêng biệt cho các mục đích của AD. Địa chỉ web và vv là một chủ đề riêng biệt và điều này sẽ không áp dụng cho điều đó. Tôi không có hoặc biết bất kỳ quy tắc cứng và nhanh nào cho hệ thống phân cấp dns, tôi tin rằng nhu cầu của bạn sẽ quyết định điều đó. Một số khu vực có thể yêu cầu một tên miền phụ (eng.mit.edu) và một số vùng sẽ không (ví dụ: hr.mit.edu). Tất nhiên, chỉ nên có một tên miền cấp cao nhất để thống nhất.

Điều đó đang được nói, điều gì quyết định liệu một bộ phận có cần một tên miền phụ hay không? Nếu đây là cho các máy trạm, họ có hỗ trợ CNTT của riêng họ hay những người có khả năng quản lý một hệ thống như vậy không? Nếu không, thực sự không có điểm nào trong việc sử dụng vùng dns để chỉ định rằng một máy nằm trong một bộ phận nhất định, có rất nhiều phương pháp khác sẽ làm tốt công việc. Đây chỉ là những câu hỏi bạn sẽ phải tự hỏi chính mình.

Tôi sẽ đánh giá lại từng khu vực và xác định

1. Nếu nó vẫn còn liên quan. Có máy chủ hoặc máy trạm vẫn chỉ vào bất cứ điều gì trong khu vực đó?

2. Ai sẽ quản lý khu mới. Không cần phải nói khu vực sẽ phải được di chuyển sang hệ thống phân cấp mới của bạn, nhưng bạn chỉ thực hiện một thông tin địa chỉ / máy chủ tên miền cho khu vực, hay bạn sẽ chủ động quản lý khu vực?

Những hệ thống nào được 'cách ly' khỏi AD? Những điều này sẽ không yêu cầu xác thực và / hoặc quản lý mạng? Lý do để tách chúng khỏi phối cảnh DNS là gì? Để xác nhận sự nghi ngờ của bạn, tất cả là về sự dễ dàng quản lý. Nếu kỹ thuật cần có quản lý dns nhiều, họ sẽ nhận được bản thân một quản trị DNS.

Để thêm thông tin dựa trên cập nhật của bạn, cá nhân tôi cũng sẽ cung cấp cho họ tên miền phụ của riêng họ eng.spacelysprockets.comvà cả mạng con. Nó nên được tường lửa từ phần còn lại của mạng với lưu lượng thích hợp được phép đi qua. Nếu họ muốn tắt và tạo eng.eng.localhoặc eng.bikesbạn không thể ngăn họ, bạn cũng không nên buộc phải hỗ trợ *.

Nếu họ chơi đẹp, hãy sử dụng subzone và quyết định họ muốn thoát ra lab.eng.spacelysprockets.comvà một phần của mạng con, đó là trên chúng. Có lẽ nên lịch sự chuyên nghiệp để cho bạn biết để bạn có thể phân đoạn lưu lượng truy cập đó, nhưng mọi người đều không nghĩ như vậy.

Một tên miền thực cho cơ sở hạ tầng của bạn sẽ nghiêm túc cung cấp cho bạn một lợi thế về quản lý, bạn nên xem xét nó.

* Nếu bạn và bạn sẽ là hai điều khác nhau, nhưng tôi lạc đề.