질문.저는 Windows AD 도메인을 가지고 있는데 한 가지 미스터리한 부분이 있습니다. Windows 도메인/DNS 서버가 Windows 도메인 외부의 도메인을 어떻게 조회합니까?
간단한 홈 네트워크에서 DNS 요청 라우팅은 이해하기 쉽습니다.
Generic Example: Client machine -> (defined DNS or from DHCP) ->
->Router / Gateway -> (usually ISP DNS) -> DNS root servers -> Internet
Specific Example: 192.168.1.101 -> 192.168.1.1 -> 8.8.8.8 -> DNS root servers -> Internet
대조적으로, 현재 내 AD 네트워크에 대해 표시되는 경로는 다음과 같습니다.
Client Machine -> Windows Domain / DNS -> ??????? -> DNS root servers -> Internet
도메인 서버의 네트워크 설정을 확인하면 DNS가 대체 DNS 서버(보조 도메인 서버), 자체 및 루프백으로 설정되어 있으며 그 외에는 아무것도 설정되어 있지 않습니다.
내 인터넷이 작동하므로 어떻게든 Windows 도메인 서버는 서버 업스트림에서 DNS 정보를 가져올 만큼 똑똑합니다. 하지만 이것이 어디서 어떻게 정의됩니까?
답변1
DC가 외부 이름 서버에 쿼리할 수 있는 여러 가지 방법은 다음과 같습니다.
- 루트 힌트
- 글로벌 포워더
- 명시적으로 정의된 스텁 영역, 위임 또는 조건부 전달 영역
- DC의 네트워크 인터페이스 설정 - 확인했습니다.
1번인가 2번인가 추측해보겠습니다. 귀하의 질문에는 네트워크 설정 확인만 포함되어 있습니다. DC의 DNS 관리자를 확인하셨나요?
위의 항목이 모두 비어 있으면 의도하지 않은 일이 진행되고 있는 것이므로 Wireshark를 사용하여 나가는 DNS 쿼리를 추적해야 할 수도 있습니다.
답변2
DNS는 완전히 다른 두 부분으로 구성됩니다. 한 부분은 데이터 게시를 담당하고, 다른 부분은 클라이언트의 DNS 요청을 수락하고 데이터를 수집하여 해당 요청에 응답하는 일을 담당합니다. 데이터 게시 역할을 수행하는 DNS 서버는 실제로 기술적으로 올바른 이름은 아니지만 종종 "권한 있는" 서버라고 합니다. 개인적으로 저는 "DNS 콘텐츠 서버"라는 이름을 선호하지만 이 용어는 널리 사용되지 않습니다. 클라이언트의 요청을 수락하고 응답하는 서버를 종종 "해결" 서버라고 합니다.
이는 실제로 HTTP 서버 및 HTTP 프록시의 작동 방식과 매우 유사합니다. HTTP 서버는 데이터를 게시하고 HTTP 프록시는 클라이언트(브라우저)의 요청을 수락하고 서버에 접속하여 클라이언트가 요청한 데이터를 수집합니다. 웹 브라우저와 DNS 클라이언트의 차이점은 DNS 클라이언트가 자체적으로 콘텐츠 DNS 서버에 접속할 수 없다는 것입니다. DNS 클라이언트해야 한다DNS 확인 서버를 사용하는 반면 웹 브라우저는 HTTP 프록시 없이도 완벽하게 작동할 수 있습니다.
DNS 정보는 계층적이고 분산된 방식으로 저장되므로 단일 쿼리에 응답하려면 전 세계에 있는 여러 DNS 콘텐츠 서버의 정보가 필요합니다. DNS 클라이언트가 "www.serverfault.com"의 주소를 알고 싶을 때 해당 요청을 DNS 확인 서버로 보낼 수 있습니다. 그런 다음 해당 DNS 확인 서버는 전 세계의 DNS 서버에 연결하는 실제 작업을 수행해야 합니다.
먼저 확인 DNS 서버는 전체 쿼리를 루트 서버(콘텐츠 DNS 서버)로 보냅니다. 해당 루트 서버에는 완전한 답변이 없지만하다".com" 도메인의 이름에 대한 자세한 정보를 가지고 있는 DNS 콘텐츠 서버를 알아보세요. 따라서 DNS 확인자는 이제 전체 쿼리를 ".com" 콘텐츠 DNS 서버 중 하나로 보냅니다. 해당 서버도 완전한 답변을 갖고 있지는 않지만 어떤 DNS 콘텐츠 서버가 도메인 이름에 대한 추가 정보를 가지고 있는지 알고 있습니다 servervault.com. 확인 DNS 서버는 클라이언트에 대한 완전한 답변을 얻을 때까지 전 세계의 콘텐츠 DNS 서버에 계속 요청합니다. 물론 확인 DNS 서버는 도중에 정보를 캐시합니다. 캐시에서 ".com" 콘텐츠 DNS 서버가 있는 위치를 알고 있는 경우 ".com" 도메인의 각 쿼리에 대해 루트 콘텐츠 DNS 서버에 연결하지 않습니다.
"전달자"는 전 세계의 콘텐츠 DNS 서버에 접속하여 자체적으로 응답을 시도하는 대신 클라이언트 쿼리를 다른(미리 구성된) 확인 DNS 서버로 보내는 간단한 확인 DNS 서버입니다. 홈 라우터에는 ISP의 확인 DNS 서버를 전달자로 사용하도록 구성된 확인 DNS 서버가 포함되는 경우가 많습니다.
두 가지 다른 역할(콘텐츠 제공 및 확인)이 하나의 DNS 서버에 함께 모이면 혼란스러울 수 있습니다. 이는 Active Directory에서 발생하는 현상입니다. Active Directory에서 DNS는 특정 서비스를 찾을 수 있는 위치에 대한 정보를 게시하는 데 사용됩니다. 예를 들어, 도메인의 클라이언트가 ad.example.com해당 도메인의 Kerberos 비밀번호 변경 서버에 연결하려고 하면 이라는 SRV 레코드에 대한 DNS 요청을 발행합니다 _kpasswd._tcp.ad.example.com. 이 DNS 요청은 다른 DNS 요청과 마찬가지로 클라이언트에 구성된 확인 DNS 서버로 전송됩니다. 그런 다음 확인 DNS 서버는 요청에 응답하기 위해 작업을 시작합니다.
이것이 약간 혼란스러울 수 있는 부분입니다. DNS 확인 서버는 자신이 특정 Active Directory 도메인의 일부임을 알 수 있습니다. 즉, 해당 도메인의 이름에 대해 들어오는 쿼리를 인식할 수 있습니다. 확인자가 이러한 쿼리를 받으면 외부 DNS 서버에 접속하지 않지만 Active Directory 데이터베이스의 정보로 직접 응답할 수 있습니다. 들어오는 쿼리가 도메인의 이름에 대한 것이 아닌 경우 확인자는 콘텐츠 DNS 서버에 연결하여 질문 자체에 대답하려고 시도하거나 (전달자를 사용하도록 구성된 경우) 쿼리를 다른 DNS 확인 서버로 보냅니다. . 이는 귀하의 시나리오에서 발생할 가능성이 높습니다.
문제를 더욱 혼란스럽게 할 수 있는 것은 동적 업데이트입니다. 중요하지 않은 도메인에서는 서비스가 정적이지 않습니다. 도메인 컨트롤러가 추가되거나 제거될 수 있습니다. 워크스테이션에도 동일하게 적용됩니다. 이는 이를 반영하기 위해 DNS의 정보를 업데이트해야 함을 의미합니다. 동적 업데이트는 클라이언트가 DNS에 게시된 정보를 수정할 수 있도록 하는 프로토콜입니다. 클라이언트는 확인 DNS 서버에 쿼리를 보내 새 정보를 보낼 수 있는 콘텐츠 DNS 서버를 찾습니다. Active Directory 통합 DNS 인프라의 경우 확인 DNS 서버는 데이터베이스 자체에 대한 액세스 권한을 갖고 있을 수 있습니다. 이 경우 확인 DNS 서버는 클라이언트에게 정보 자체를 업데이트할 수 있음을 알려줍니다.