Split-DNS 캡처: 각 관측이 어디서 이루어졌는지 밝히기

두 사람이 같은 Split-DNS 문제를 진단하지만 서로 다른 resolver 주소를 얻습니다. 한 사람은 조회 도구를 썼고, 다른 사람은 어댑터에서 패킷을 캡처했으며, 세 번째 사람은 클라이언트 자체의 진단을 읽었습니다. 누구도 거짓말하지 않으며, 누구도 같은 단계를 설명하지 않습니다. 관측 지점을 밝히면 모순이 지도가 됩니다.

하나의 조회, 여러 관측 지점

하나의 내부 이름에 대해 살펴볼 곳은 적어도 다섯 군데입니다. 애플리케이션과 그것이 호출하는 resolver API, 클라이언트의 유효 도메인 정책, 어댑터나 필터에서의 캡처, 통제된 게이트웨이 경계, 그리고 실제로 쿼리를 받는 resolver입니다.

각각은 다른 질문에 답하며, 어느 것 하나만으로 쿼리가 어디로 갔는지 증명할 수 없습니다.

어댑터 캡처는 의도가 아니라 패킷을 보여 줍니다. 클라이언트가 어느 resolver를 골랐는지는 알려 주지 않으며, 빈 캡처는 패킷이 버려진 것이 아니라 캐시된 응답이나 다른 resolver API를 뜻할 수 있습니다. 각 관측을 한 단계에 대한 증거로 다루십시오. 그런 다음 단계들을 경로로 조립하십시오.

클라이언트 필터는 앱과 회선 사이에 있습니다

Split-DNS를 쓰는 VPN 클라이언트는 패킷이 기기를 떠나기 전에 도메인 일치를 적용합니다. 터널 접미사에 속한 이름은 내부 resolver로, 나머지는 모두 로컬 resolver로 갑니다. 필터는 정책이며, 정책은 플랫폼과 클라이언트 버전에 따라 다를 수 있습니다.

Cisco의 Secure Client Split-DNS 지침은 도메인 일치와 Windows 필터를 다루며, 앱이 기본 resolver API를 쓸 때 보는 것과 nslookup 같은 도구가 보는 것을 구분합니다. 바로 그 차이가 핵심입니다.

유효 프로필과 평범한 애플리케이션 조회 하나에서 시작하십시오. 특정 서버를 지명하는 모든 시험은 의도적인 우회입니다. 클라이언트 자체의 진단으로 그것을 설명하고, 그것이 합격 기준이 되게 하지 마십시오.

nslookup은 앱과 다른 경로를 탑니다

nslookup은 자체 DNS 쿼리를 만들고 운영 체제의 resolver 정책을 우회할 수 있습니다. 그래서 특정 서버에 특정 질문을 던지는 데는 유용하고, 애플리케이션이 무엇을 겪을지 시험하는 데는 오해를 부르는 도구입니다.

Windows에서는 이름 확인 정책 표가 어느 접미사가 어느 서버를 쓰는지 결정합니다. 그것을 읽으면 애플리케이션이 따를 정책이 보이며, 흔히 그것이 빠진 조각입니다.

정책을 읽고 나서 같은 질문을 일반 resolver로 던지십시오:

Get-DnsClientNrptPolicy
Resolve-DnsName intranet.hq.example

암호화된 resolver는 쿼리를 숨기지, 연결을 숨기지 않습니다

자체 DNS-over-HTTPS resolver를 가진 브라우저는 전혀 다른 사례입니다. 쿼리는 TLS 안에서 나가므로, 패킷 캡처는 resolver 주소로의 연결을 보여 주지만 질문한 이름은 보여 주지 않습니다.

먼저 브라우저의 관리 정책을 파악하고, 그것을 운영 체제 조회와 비교하십시오. 자체 resolver를 고를 수 있는 브라우저는 Split-DNS 정책을 아예 보지 못할 수 있습니다.

같은 주의가 자체 resolver를 포함한 모든 클라이언트에 적용됩니다. 원격 연결을 식별하는 캡처는 쿼리 이름에 대한 증거가 아닙니다. 이름이 필요하면 resolver 자체의 로그나 애플리케이션의 진단에서 가져오되, 적용되는 개인정보 보호 규칙을 따르십시오.

레이블이 붙은 시험과 비교하십시오

시험용으로 승인된 내부 이름과, 민감한 의미가 없는 공개 이름을 고르십시오. 각각에 대해 시각, 레코드 유형, 응답, 그리고 예상한 정책을 기록하십시오.

허용되는 곳에서는 resolver의 수신을 클라이언트나 게이트웨이의 좁은 관측 하나와 비교하십시오:

nslookup intranet.hq.example 10.55.0.53
Get-DnsClientNrptPolicy | Format-List

비교를 만들기 위해서만 사설 이름을 무관한 공개 resolver로 보내지 말고, 공유하는 모든 것을 가리십시오. 마지막으로 올바른 DNS 응답과 그 뒤따르는 서비스 연결을 분리하십시오. 확인된 사설 주소에는 여전히 경로와 애플리케이션 권한이 필요합니다.