저는 현재 홈랩용 DNS 서버를 설정하고 있습니다. 예를 들어 연구실 도메인에 해당하는 영역 파일을 만들었고 home.lab이제 서버는 해당 영역에 대한 권한 있는 서버임을 알고 에 대한 쿼리에 응답할 수 있습니다 device.home.lab.
이제 다른 장치에서 이 DNS 서버를 사용하여 영역에 대한 권한을 부여하고 싶지만 home.lab여전히 글로벌 인터넷 도메인을 확인할 수 있어야 합니다. home.lab조회에만 사용하도록 최종 호스트를 설정하고 그렇지 않은 경우에는 다른 호스트를 설정하는 방법이 없는 것 같습니다 . 지금까지 몇 가지 해결책을 볼 수 있습니다.
- 다른 영역도 재귀적으로 해결하도록 이 서버를 설정합니다(설명된 대로 작동함).이 질문에)
- 서버가 자신의 영역이 아닌 다른 영역을 요청하면 루트 서버에 대한 참조로 응답하고 거기에서 클라이언트가 자체적으로 계층 구조를 재귀적으로 요청하도록 합니다.
- 요청이 있을 경우
home.lab권한 있는 DNS 서버의 응답을 전달하고 그렇지 않은 경우 캐시된 응답을 전달하는 다른 DNS 서버를 설정합니다.
첫 번째 옵션은 권한 있는 서버가 나머지 도메인에 대한 재귀 확인자로서의 이중 의무도 가지기 때문에 좋지 않은 것 같습니다. 두 번째는 비효율적입니다. 그러면 클라이언트가 모든 새 도메인에 대한 계층 구조를 수동으로 확인해야 하므로 속도가 상당히 느려질 수 있습니다.
따라서 지금까지는 세 번째 옵션이 가장 좋은 것 같습니다. BIND9에서 이를 어떻게 설정해야 하며/또는 대체 솔루션을 고려해야 합니까?
답변1
첫 번째 옵션은 권한 있는 서버가 나머지 도메인에 대한 재귀 확인자로서의 이중 의무도 가지기 때문에 좋지 않은 것 같습니다.
소규모 LAN/홈랩 사용의 경우 이는 실제로 문제가 되지 않습니다.
(예를 들어 Active Directory 환경에서는 일반적으로 관리자가 모든 클라이언트에게 전용 확인자 대신 AD DNS 영역을 호스팅하는 AD DC를 직접 사용하도록 지시합니다.불필요한,하지만 엄밀히 말하면 나쁘지는 않습니다.)
일부 극단적인 경우(예: DNSSEC AD 플래그)가 있을 수 있지만 결과적으로 그렇게 생각합니다.~ 아니다Resolver 기능을 권한 있는 서버에 추가하는 것과 그 반대 - 머신이 Resolver인 것처럼 권한 있는 서버를 사용하도록 만드는 것입니다.이미행위.
두 번째는 비효율적입니다. 그러면 클라이언트가 모든 새 도메인에 대한 계층 구조를 수동으로 확인해야 하므로 속도가 상당히 느려질 수 있습니다.
또한 대부분의 클라이언트는 작동하지 않습니다.그루터기해결자 - 추천을 따르지 않습니다.
반면에 전체 리졸버는은닉처추천. 여러분이 사용하고 있는 공용 DNS 확인자(ISP, Google 또는 다른 것)도 모든 새 도메인에 대한 계층 구조를 확인해야 합니다. 확실히 전 세계 모든 DNS 레코드의 전체 복사본을 보관하지는 않습니다. 느리지는 않습니다. 왜냐하면 적어도 첫 번째 수준(TLD)은 일반적으로 메모리 내에 캐시되어 있고 어쨌든 일반적인 도메인에 대한 계층 구조 수준이 그다지 많지 않기 때문입니다.
따라서 지금까지는 세 번째 옵션이 가장 좋은 것 같습니다. BIND9에서 이를 어떻게 설정해야 하며/또는 대체 솔루션을 고려해야 합니까?
BIND9에서 type static-stubhomelab 인증 서버를 가리키는 영역을 만듭니다. (영역과 유사 type forward하지만 "static-stub"은 권한 있는 서버를 직접 가리킬 것으로 예상하는 반면 "forward"는 다른 확인자에 연결될 것으로 예상합니다. 정확한 차이점은 잘 모르겠습니다.)
다른 모든 도메인의 경우 forwarders{}전역 BIND 구성에서와 같이 업스트림 서버를 지정할 수 있습니다. 이는 필수 사항이 아닙니다. BIND9 자체는 루트 DNS 서버에서 참조를 추적할 수 있습니다(그리고 "루트 힌트" 의사 영역이 구성되어 있는 한 기본적으로 그렇게 합니다).그렇지 않다느립니다(물론 자체 대용량 캐시가 있는 업스트림 서버로 요청을 전달하는 것보다 속도가 느릴 수 있음).
일반적인 대안은 Unbound입니다(권한 있는 서버 기능을 최소화하고 확인자로 사용하는 데 더 중점을 둡니다). Unbound 구성은 stub"static-stub" 대신 영역 유형을 사용한다는 점을 제외하면 유사합니다 . 언바운드 전달 쿼리를 만들려면 ".""type: 전달" 영역으로 구성하세요.
사용자 정의 TLD를 만드는 것은 DNSSEC 검증과 잘 작동하지 않는다는 점을 명심하십시오. 루트 영역에는 존재하지 않음을 증명하는 NSEC 레코드가 있으므로 lab.LAN 확인자 및 때로는 호스트 자체 모두에서 도메인을 검증에서 명시적으로 제외해야 할 수도 있기 때문입니다. . home.arpa.이러한 종류의 사용을 위해 도메인 만 예약되어 있습니다(의도적으로 서명되지 않은 NS 레코드 포함).
(또는~할 수 있게 하다DNSSEC, 내부 영역에 서명하고 모든 검증 확인자에 사용자 지정 "신뢰 앵커"를 지정합니다. 홈 랩에서는 DNSSEC가 실제로 필요하지 않지만 여기서의 장점은 특히 BIND에서 트러스트 앵커를 추가하는 것이 제외를 추가하는 것보다 쉬울 수 있다는 것입니다.)