개인 네트워크의 최상위 도메인 / 도메인 접미사?

사무실에는 순수한 내부 DNS 설정을 가진 LAN이 있으며 클라이언트는 모두로 이름이 지정됩니다 whatever.lan. 또한 VMware 환경이 있으며 가상 머신 전용 네트워크에서 가상 머신의 이름을 지정합니다 whatever.vm.

현재, 가상 머신이 네트워크는 우리의 로컬 영역 네트워크에서 도달 할 수없는, 그러나 우리는, 이러한 가상 컴퓨터를 마이그레이션 할 수있는 생산 네트워크를 설정하는 것 랜에서 도달 할 수 있습니다. 그 결과, 우리는 우리가 우리가 설정하는 새로운 네트워크의 손님에 적용되는 도메인 접미사 / TLD에 대한 규칙에 정착하기 위해 노력하고 있지만, 우리는 좋은 하나 가지고 올 수없는, 주어진 .vm, .local그리고 .lan우리 환경에는 모두 기존의 의미가 있습니다.

그렇다면이 상황에서 가장 좋은 방법은 무엇입니까? 순전히 내부 네트워크에 사용하기에 안전한 TLD 또는 도메인 이름 목록이 있습니까?

발명 된 TLD를 사용하지 마십시오. ICANN이이를 위임하면 큰 어려움에 처하게됩니다. 동일한 더미 TLD를 사용하는 다른 조직과 병합하는 경우에도 마찬가지입니다. 이것이 전 세계적으로 고유 한 도메인 이름이 선호되는 이유입니다.

표준 RFC 2606 은 예제, 문서, 테스트에 대한 이름을 보유하지만 일반적인 용도로는 사용할 수 없으며 좋은 이유가 있습니다. 오늘날 실제적이고 고유 한 도메인 이름을 얻는 것이 너무 쉽고 저렴하여 더미 하나.

따라서 장치를 구입 iamthebest.org하고 사용하여 장치 이름을 지정하십시오.

인터넷에서 사용할 수없는 이름을 가진 내부 시스템에 회사 등록 도메인의 하위 도메인을 사용하십시오. (물론 내부 DNS 서버에서 해당 이름 만 호스팅합니다.) 가상의 Example Corporation에 대한 몇 가지 예는 다음과 같습니다.

인터넷 서버 :
www.example.com
mail.example.com
dns1.example.com

내부 머신 :
dc1.corp.example.com
dns1.corp.example.com
client1.corp.example.com

"corp"를 사용하여이 하위 도메인이 내부 회사 네트워크의 시스템을 설명했음을 나타내지 만 "internal": client1.internal.example.com과 같이 여기에서 원하는 것을 사용할 수 있습니다.

또한 DNS 영역과 하위 도메인은 네트워크 번호 체계와 일치 할 필요가 없습니다. 예를 들어 우리 회사에는 각각 자체 서브넷이있는 37 개의 위치가 있지만 모든 위치는 동일한 (내부) 도메인 이름을 사용합니다. 반대로, 하나 또는 몇 개의 서브넷 만 가질 수 있지만 많은 피어 내부 도메인 또는 하위 도메인 수준을 사용하여 시스템을 구성 할 수 있습니다.

내부 하위 도메인을 사용하는 또 다른 이점이 있습니다. FQDN 대신 검색 접미사와 호스트 이름 만 사용하면 개발, QA 및 프로덕션 모두에서 작동하는 구성 파일을 작성할 수 있습니다.

예를 들어, 항상 구성 파일에서 "database = dbserv1"을 사용하십시오.

개발 서버에서 검색 접미 부를 "dev.example.com"=> 사용 된 데이터베이스 서버로 설정하십시오. dbserv1.dev.example.com

QA 서버에서 검색 접미 부를 "qa.example.com"=> 사용 된 데이터베이스 서버로 설정하십시오. dbserv1.qa.example.com

프로덕션 서버에서 검색 접미 부를 "example.com"=> 사용 된 데이터베이스 서버로 설정하십시오. dbserv1.example.com

이렇게하면 모든 환경에서 동일한 설정을 사용할 수 있습니다.

이 질문에 대한 이전 답변이 작성되었으므로 지침을 다소 변경하는 몇 가지 RFC가있었습니다. RFC 6761 은 개인 네트워크에 대한 특정 지침을 제공하지 않고 특수 용도 도메인 이름에 대해 설명합니다. RFC 6762는 여전히 등록되지 않은 TLD를 사용하지 말 것을 권장하지만 어쨌든 수행 될 경우도 있음을 인정합니다. 일반적으로 사용되는 .local 은 멀티 캐스트 DNS (RFC의 주요 주제)와 충돌 하므로 부록 G. 개인 DNS 네임 스페이스 는 다음 TLD를 권장합니다.

• 인트라넷
• 내부의
• 사유의
• 사
• 집
• 란

IANA 는 두 RFC를 모두 인식 하지만 부록 G에 나열된 이름을 포함하지는 않습니다.

다시 말해서, 당신은 그것을해서는 안됩니다. 그러나 어쨌든 그렇게하기로 결정한 경우 위의 이름 중 하나를 사용하십시오.

이미 언급했듯이 개인 네트워크에는 등록되지 않은 TLD를 사용하지 않아야합니다. 특히 ICANN은 거의 모든 사람이 새로운 TLD를 등록 할 수 있도록 허용합니다. 그런 다음 실제 도메인 이름을 사용해야합니다

반면 RFC 1918 은 다음과 같이 명확합니다.

이러한 주소에 대한 간접 참조는 엔터프라이즈 내에 포함되어야합니다. 이러한 참조의 대표적인 예로는 DNS 리소스 레코드 및 내부 개인 주소를 참조하는 기타 정보가 있습니다. 따라서 네임 서버는 개인 레코드가 인터넷에서 전송되지 않도록보기를 사용해야합니다.

우리는 호스트의 가상 이름 지정과 물리적 계층의 차이를 고려하지 않는 경향이 있습니다. 실제로 물리적 계층에서 호스트 구성 (소프트웨어)을 추상화하려고했습니다.

그래서 우리는 하드웨어 아이템을 구매하고 그 위에 호스트 아이템을 생성합니다 (그리고 우리의 문서에 간단한 관계를 보여줍니다).

목적은 호스트가 존재할 때 DNS가 결정 요소가되어서는 안된다는 것입니다. 예를 들어 머신이 한 공간에서 다음 공간으로 이동함에 따라 성능이 낮은 웹앱은 값 비싼 CPU 사이클을 소비 할 필요가 없습니다. 가상화 이름 지정 체계를 유지하며 모든 것이 계속 작동합니다.

이것이 도움이 .aws될지는 모르겠지만 AWS 계정 내의 내부 DNS의 경우 tld로 사용 하며 완벽하게 작동하는 것 같습니다.

나는 사용하지 말아야 할 TLD가 있다는 것을 알고 있지만 그 외에는 너무 엄격하지 않다고 생각합니다.

인증 소스를 TLD로 사용하는 일부 대기업에서 근무했습니다. 인증 소스로 Active Directory를 사용하여 MS / Windows 서버 인 경우 인증 소스를 사용하고 .ad다른 일부는 그 .ldap이유는 무엇입니까? '동일한 소스를 사용하지 않습니까? 아니면 동일한 디렉토리 서비스에서 복제하는 서버를 알고 있습니까? 모르겠습니다.

행운을 빕니다