공용 DNS가 작동한다고 Active Directory를 찾을 수 있는 것은 아니다

VPN이 연결되고 브라우저가 공용 사이트를 열지만 노트북은 여전히 도메인에 로그인하지 못한다. 흔한 결론은 이름이 확인되니 DNS가 정상이라는 것이다. 정상이 아니며, 그 이유는 브라우저 테스트가 도메인에 가입된 클라이언트에 필요한 연쇄 가운데 한 번의 조회만 시험하기 때문이다. 도메인 검색은 먼저 서비스 레코드를 요청하고, 다음으로 그 레코드가 지목하는 컨트롤러의 주소를, 마지막으로 그 컨트롤러가 수신하는 포트까지의 경로를 요청한다. 공용 응답은 이 단계 중 어느 것도 충족하지 못한다.

신화: 이름이 확인되니 DNS는 끝났다

공용 사이트가 확인된다는 것은 어떤 리졸버가 공용 영역의 이름에 대한 A 또는 AAAA 질의 하나에 답했다는 뜻일 뿐이다. Active Directory는 같은 프로토콜을 도메인의 서비스가 어디에 있고 이 클라이언트가 어떤 컨트롤러를 써야 하는가라는 다른 질문에 쓴다. 그 질문은 도메인 이름을 딴 영역 아래 SRV 레코드로 표현되며, 재귀 공용 리졸버가 그것을 보관할 이유는 없다.

레코드가 없으면 리졸버는 부정 응답을 돌려주는데, 그것은 장애가 아니라 정상적인 DNS 응답이다. 그러면 클라이언트는 캐시된 컨트롤러 정보가 있으면 그쪽으로 물러나고, 바로 그래서 데스크톱이 몇 시간 동안 괜찮아 보이다가 재부팅이나 암호 변경 뒤에 실패할 수 있다.

도메인 클라이언트가 실제로 요청하는 것, 순서대로

corp.example 같은 도메인에서 일반 로케이터 질의는 _ldap._tcp.dc._msdcs.corp.example이다. SRV 응답은 후보 컨트롤러와 그 포트를 지목하고, 그다음 클라이언트는 연결을 열기 전에 그 호스트 이름의 주소 레코드를 필요로 한다. 사이트를 인지하는 검색은 사이트 하위 도메인 아래에 질의를 더하며, 응답은 어느 컨트롤러가 우선인지 결정하고 어느 것이 필수인지는 아니다.

nltest /dsgetdc:corp.example
Resolve-DnsName -Type SRV _ldap._tcp.dc._msdcs.corp.example

문제가 생기는 네트워크에서부터 그 순서로 연쇄를 따라가라. 접근할 수 없는 주소로 확인되는 호스트 이름은 라우팅 실패이지 DNS 실패가 아니다. 접근 가능한 컨트롤러에 로케이터 레코드가 빠져 있으면 DNS 실패이지 라우팅 실패가 아니다. 둘은 비슷한 사용자 불평과 전혀 다른 수리를 낳는다.

공용 리졸버가 답하는데도 로그인이 깨지는 이유

어댑터가 클라이언트에 공용 리졸버를 주면 공용 이름은 되고 내부 이름 공간은 안 되는데, 두 번째 공용 리졸버를 더해도 도움이 되지 않는 것은 둘 다 영역을 갖고 있지 않기 때문이다. 흔한 ‘내부 우선, 공용 다음’ 목록도 도메인별 규칙처럼 동작하지 않는다. 첫 서버의 부정 응답은 정당한 응답이며, 응답이 비었다는 이유만으로 클라이언트가 두 번째 서버를 다시 시도하지는 않는다.

내부 리졸버를 두 개 운영한다면 둘 다 AD 이름 공간을 보유하고 클라이언트의 현재 네트워크에서 접근 가능해야 하는데, 분할 터널 설계가 깨뜨리는 지점이 바로 이것이다. VPN이 터널 서브넷을 실어도 내부 리졸버가 터널이 라우팅하지 않는 접두사에 있으면 질의는 답할 수 없는 리졸버로 나간다.

Windows는 특정 이름 공간을 특정 서버로 보낼 수 있는 이름 확인 정책도 적용하며, 어댑터가 표시하는 DNS 주소가 전부는 아니다. 그 정책을 바꾸지 않고 어댑터 목록만 바꾸면 실제 구성이 그대로 남을 수 있고, 적용된 것처럼 보이는 수정이 효과가 없는 이유가 여기 있다.

터널의 DNS와 그 경로를 일치시켜라

리졸버는 밀어 넣지만 그것을 포함한 접두사는 넣지 않는 VPN 프로필은 클라이언트가 닿을 수 없는 리졸버를 만들고, 접두사는 넣지만 리졸버를 넣지 않는 프로필은 클라이언트가 로컬 리졸버에 묻게 만든다. 이 짝을 하나의 구성 항목으로 다루고 프로필을 바꿀 때마다 둘 다 확인해야 하는데, 밀어 넣는 순서가 바뀌거나 새 분할 터널 정책이 둘을 갈라놓을 수 있기 때문이다.

클라이언트가 밀어 넣은 설정을 어떻게 다루는지도 확인하라. 어떤 클라이언트는 DNS 서버를 터널 인터페이스에만 적용하고 물리 어댑터의 리졸버는 그대로 두므로, 어느 쪽이 이기는지는 인터페이스 메트릭과 질의하는 이름에 달려 있다. 물리 어댑터를 비활성화했을 때만 내부 응답이 온다면 고칠 것은 그 기제이지 도메인 레코드가 아니다.

검색 호출과 실제 작업 하나로 승인하라

쓸모 있는 승인 테스트는 로케이터 질의를 실행한 뒤 디렉터리 기반 공유를 열거나 티켓을 요청하는 실제 인증 작업을 하나 수행한다. VPN 전환 전과 후에 같은 장비에서, 중간에 재부팅 없이 하라. 캐시된 자격 증명과 이미 열린 세션은 깨진 경로를 기꺼이 건강해 보이게 만들므로 데스크톱 로그인 성공은 테스트가 아니다.

Microsoft의 DNS 클라이언트 권장 사항은 내부 이름 공간을 확인하는 일과 공용 질의를 상위로 전달하는 일 사이에 같은 선을 긋는데, VPN을 도입할 때 지켜야 할 배치가 이것이다.

실패가 아니라 단지 느린 것이라면 지연을 진단과 분리해 두어라. 검색 중 시간 초과는 접근할 수 없는 컨트롤러, 차단된 포트, 늦게 응답하는 리졸버에서 올 수 있으며 기다림만으로는 어느 것도 증명되지 않는다. 리졸버 설정을 바꾸기 전에 실제 질의와 그 응답, 연결 시도를 기록하라.