엔지니어링에는 자체 DNS 영역, 대리인 또는 하위 도메인이 있어야합니까?

조직의 기본 도메인 (AD 포함) example.com이 있습니다. 과거에는 이전 관리자가 dmn.com, lab.example.com, dmn-geo.com 등과 같은 여러 다른 영역과 하위 도메인 및 델리게이트를 서로 다른 엔지니어링 그룹에 대해 생성했습니다. 우리의 DNS는 지금 약간 혼란입니다. 물론 example.com의 워크 스테이션에있는 누군가가 다른 영역 / 하위 도메인의 시스템에 연결하거나 그 반대로 연결해야 할 때 문제가 발생합니다 (부분적으로 영역 전송 및 위임이 대부분 구성되지 않았기 때문에) .

프로덕션 DNS는 Active Directory와 통합되어 있지만 엔지니어링 시스템은 AD와 분리되어야합니다.

우리는 DNS를 재구성하고 이러한 모든 항목을 통합하는 방법을 논의하고 있습니다. 우리가 취할 수있는 세 가지 방법이 있습니다.

• 'dmn.eng'과 같은 새 영역을 만듭니다. 이는 DNS 서버를 사용하거나 이름 서버를 사용하여 엔지니어링하여 IT 부서에서 관리 할 수 ​​있습니다.
• 새 위임 eng.example.com을 생성하고 엔지니어링 DNS를 해당 하위 도메인에 통합 한 후 엔지니어가 대리인의 이름 서버를 관리하게합니다.
• 위임없이 새 하위 도메인 eng.example.com을 만들고 하위 도메인 자체의 DNS를 관리합니다.

대리인 하위 도메인을 만들고 엔지니어가 해당 하위 도메인 내에서 자신의 DNS 구조를 완전히 제어 할 수있게하는 것이 좋습니다. 장점은 DNS가 작동하지 않으면 내 잘못이 아니라는 것입니다.). 그러나 어떤 것이 효과가없는 경우 책임에 대해 여전히 모호한 점이 있으며, 설정, 구성 및 관리를 위해서는 엔지니어링 부서와의 조정이 필요합니다.

하위 도메인을 위임하지 않으면 프로덕션 IT가 비 프로덕션 DNS를 처리하는 데 훨씬 더 많은 작업이 필요하다는 것을 의미합니다 (기본적으로 이미 많은 작업을 수행 했음). 모든 DNS를 완벽하게 제어 할 수 있다는 장점이 있으며, 문제가 해결되지 않을 경우 누가 그 책임을 져야하는지 의심 할 여지가 없습니다. 또한 geo.eng.example.com과 같은 델리게이트를 추가하여 엔지니어링에 필요한 유연성과 제어 기능을 제공 할 수 있습니다.

새로운 지역 인 dmn.eng을 만들어야 할 필요성이나 이점에 대해 확신이 없습니다.

이런 상황에 대한 업계 모범 사례와 권장 사항은 무엇입니까? 엔지니어링과 생산간에 완벽한 이름 확인을 구현하고 제공하는 가장 간단한 솔루션은 무엇입니까? 내가 누락되었을 수있는 각 솔루션에 대한 잠재적 인 이점 또는 함정은 무엇입니까?

정보를 조금 더 추가하기 위해 우리는 상당히 큰 제조 회사입니다. 이 엔지니어들은 R & D, 개발 및 QA에서 일합니다. 실험실에는 종종 자체 서브넷이나 전체 네트워크, DHCP 등이 있습니다. 조직 및 기술과 관련하여, 그들은 작은 세계입니다.

우리는 프로덕션 환경을 보호하기 위해 엔지니어링 실험실 및 네트워크에 대해 일정 수준의 네트워크 격리를 유지하려고합니다 ( 엔지니어링 DHCP 서버를 신뢰할 수있는 AD DHCP 서버로 추가 한 엔지니어에 대해서는 이전 질문 참조 ). 그러나 랩의 워크 스테이션 사용자는 프로덕션 네트워크의 리소스에 액세스해야하거나 프로덕션 네트워크의 워크 스테이션 사용자는 랩 시스템에 연결해야하며 이는 정렬을 정당화하기에 충분한 빈도로 발생합니다. 통합 DNS.

기존 대리자에게는 이미 엔지니어링으로 관리되는 DNS 서버가 있지만 이러한 서버가 설정된 다른 랩의 엔지니어 간에는 통신이 없으므로 가장 일반적인 문제는 하위 도메인 간 이름 확인에 실패하는 것입니다. 엔지니어가 해당 델리게이트 서버를 소유하고 있기 때문에 NS 항목을 수정하여 서로 대화 할 수 없으므로 IT가 전적으로 소유하지 않은 DNS의 이점이 있습니다. 그러나 엔지니어링은 매일 DNS를 변경할 수 있기 때문에 생산 및 엔지니어링을 위해 DNS를 관리하는 것은 어려운 일입니다. 그러나 BigHomie가 그의 답변에서 언급했듯이 이는 아마도 엔지니어링 팀이 실제 DNS 관리자를 고용 (또는 지정)해야한다는 것을 의미합니다. 그 사람과 나는 아주 잘 알고 있어야합니다.

필자는 임의의 최상위 도메인 이름 또는 접미사를 사용하여 새 영역을 만드는 아이디어가 마음에 들지 않지만 이미 임의의 이름을 가진 5 개의 다른 영역이 있으므로 단일 영역으로 통합하는 것이 여전히 개선되고 있습니다. 조직의 여러 그룹에 대해 별도의 최상위 영역이있는 다른 회사가 존재한다는 것을 알고 있으므로 언제 그것이 적절한 지, 그리고 그 접근법의 장점 / 단점이 무엇인지 궁금합니다.

참고로, 저는이 회사에 몇 달 동안 있었으며 이전 AD / DNS 관리자가 회사를 떠났으므로 기존 DNS 구조가 존재하는 이유에 대해서는 언급 할 것이 없습니다.

오늘날 세계에서는 임의의 최상위 도메인으로 새로운 영역을 생성하지 않는 것이 좋습니다.이 영역 은 언제든지 "공식 DNS"로 만들 수 있기 때문입니다.

개인적으로 하위 도메인 위임 시나리오를 선호합니다. (통합하지만 엔지니어링에 대한 통제권 부여)

엔지니어링 부서에서 레코드를 추가 / 제거 할 수있는 MS DNS에 대한 웹 프론트 엔드를 찾을 수도 있으므로 서버 자체는 여전히 프로덕션 IT에서 소유하고 있으며 "그들"만이 관리하는 것은 DNS 항목입니다.

무엇보다도 (mit.edu)를 사용하려는 domain.tld를 소유 하고 있는지 확인하십시오 . 이것이 인터넷에 연결되지 않더라도 그것은 중요하지 않습니다.

적어도 것을 DNS의 계층 구조를 가지고에 큰 이점이 있습니다 다소 또 org 일치가. IT 지원 측면에서 해당 부서를 관리 할 사람 / 사람이있는 경우에만이 작업을 수행했습니다. 이것은 AD를 위해 별도의 영역을 갖는 것과 관련이 있습니다. 웹 주소 등은 별도의 주제이므로 적용되지 않습니다. 나는 dns 계층 구조에 대한 단단하고 빠른 규칙을 모르거나 알지 못합니다. 귀하의 조직의 요구가 그것을 지시 할 것이라고 믿습니다. 일부 영역에는 하위 도메인 (eng.mit.edu)이 필요하고 일부 영역에는 그렇지 않습니다 (예 : hr.mit.edu). 물론, 단지이 있어야 하나의 일관성을 위해 최상위 도메인.

즉, 부서에 하위 도메인이 필요한지 여부는 어떻게 결정됩니까? 워크 스테이션 용인 경우 자체 IT 지원이 있거나 그러한 시스템을 관리 할 수있는 사람이 있습니까? 그렇지 않다면 실제로 dns 영역을 사용하여 기계가 특정 부서에 있음을 지정하는 데 아무런 의미가 없으며 작업을 올바르게 수행하는 다른 많은 방법이 있습니다. 이것들은 당신이 스스로에게 물어봐야 할 질문입니다.

각 영역을 다시 평가하고 결정합니다.

1. 여전히 관련성이 있다면. 해당 영역의 서버 나 워크 스테이션이 여전히 아무것도 가리키고 있습니까?

2. 새로운 영역을 관리 할 사람 영역을 새 계층 구조로 마이그레이션해야한다는 것은 말할 것도 없지만 영역에 대한 전달 주소 / 이름 서버 정보 만 구현 합니까? 아니면 영역 을 적극적으로 관리 하시겠습니까?

AD에서 어떤 시스템을 '절연'합니까? 네트워크 인증 및 / 또는 관리가 필요하지 않습니까? 그것들을 DNS 관점에서 분리하는 이유는 무엇입니까? 의심을 확인하려면 관리가 쉬워야합니다. 엔지니어링 에 많은 dns 관리 가 필요한 경우 스스로 DNS 관리자를 확보해야합니다.

업데이트를 기반으로 정보를 추가하려면 개인적으로 그들에게 자체 하위 도메인 eng.spacelysprockets.com, 및 서브넷을 제공합니다. 적절한 트래픽이 허용되도록 나머지 네트워크에서 방화벽으로 보호해야합니다. 그들이 떠나서 창조하고 싶 eng.eng.local거나 eng.bikes막을 수 없거나 그것을지지하도록 강요해서는 안됩니다 *.

그들이 잘 플레이하면 하위 영역을 사용하고 그들이 끊고 싶고 lab.eng.spacelysprockets.com서브넷의 일부를 결정하면 그 위에 있습니다. 트래픽을 분류 할 수 있도록 전문적인 예의를 갖추어야하지만 모든 사람이 그렇게 생각하지는 않습니다.

인프라의 실제 도메인 이름은 관리 상 이점을 심각하게 제공하므로 고려해야합니다.

* 당신을해야하며 것이다 당신이 다른 두 가지가 있지만 I의 탈선한다.