VPN이 세 개의 DNS 서버를 밀어 넣습니다: 어느 것이 응답할까요?

연결한 뒤 설정 페이지를 열면 세 개의 DNS 주소가 나열됩니다; 감사의 질문은 그중 어느 것이 마지막 쿼리를 처리했느냐입니다. 숫자만으로는 아무것도 답하지 못합니다. 클라이언트 푸시, 물리 인터페이스, 도메인별 정책이 모두 같은 화면에 쓰기 때문입니다. 이 항목들은 서로 다른 범위를 가지며, 응답자를 결정하는 것은 위치가 아니라 범위입니다. 먼저 출처를 분리한 다음, 관심 있는 이름을 가진 출처를 시험하세요.

목록이 프로필보다 긴 이유

VPN 클라이언트는 터널 링크용 리졸버 주소를 푸시하고, 운영체제는 그것을 물리 인터페이스가 이미 가지고 있던 것 옆에 둡니다. 라우터, 기업 DHCP 임대, 두 번째 VPN, 도메인별 정책이 각각 자기 항목을 더합니다. 따라서 페이지의 세 주소는 한 작업에 대한 세 후보가 아니라 세 범위를 뜻할 수 있습니다. 숫자를 유출의 증거로 읽는 것이 이 감사의 첫 번째 실수입니다.

한 인터페이스 안에서 클라이언트는 실제로 서버를 순서대로 시도하므로 정렬된 목록이 무의미하지는 않습니다. 대기열이 아닌 것은 병합된 화면이며, 프로필, 물리 링크, 도메인별 규칙의 항목이 단일 순위 없이 나란히 놓입니다. 그 구분이 무엇을 시험할지 결정합니다: 순서는 한 범위 안의 동작을 설명하고, 범위는 나머지 전부를 설명합니다.

암호화 DNS는 애플리케이션 내부에서 그림을 깨뜨립니다. 자체 DNS-over-HTTPS 리졸버를 가진 브라우저나 채팅 클라이언트는 운영체제 목록을 완전히 우회해 쿼리를 보내므로, 설정 페이지의 주소는 앱이 만든 적 없는 트래픽을 설명합니다. 이름이 잘못 나온 것을 프로필 탓으로 돌리기 전에 앱 자체의 리졸버 설정을 확인하세요.

세 가지 점검이 각각 말하는 것

각 출처는 다른 곳에 흔적을 남기고, 어떤 단일 명령도 모두를 보여 주지 않습니다. 설정 페이지 옆에 둘 만한 매핑은 이것입니다:

systemd-resolved을 쓰는 시스템에서 resolvectl status이 권위 있습니다. 링크별 DNS를 라우팅 도메인과 함께 보고하기 때문입니다. macOS는 scutil --dns으로 응답하며, 범위가 있는 리졸버를 시도 순서대로 나열합니다. Windows는 두 절반으로 나눕니다: 인터페이스별 서버에는 Get-DnsClientServerAddress, 접미사 규칙에는 Get-DnsClientNrptPolicy입니다. 실제로 사용 중인 리졸버에 해당하는 명령을 실행하세요. 컨테이너 런타임과 데스크톱 리졸버가 함께 있는 머신에는 여러 개가 설치되어 있을 수 있습니다.

당신의 영역에 응답할 수 없는 백업 리졸버

두 번째 항목은 보통 가용성을 위해 있고, 가용성은 백업이 이름을 알 때만 작동합니다. 공용 리졸버에 내부 호스트 이름을 물으면 NXDOMAIN을 돌려주거나, 무관한 검색 도메인에서 와일드카드 응답을 줍니다. 아무도 확인하지 않은 페일오버는 정확히 필요한 순간에 장애를 만듭니다.

Split DNS는 그것을 막기 위해 있습니다: 회사 접미사는 영역을 가진 리졸버로 가고, 공용 이름은 기본 경로에 남습니다. 설계는 견고하며, 접미사 목록이 완전한지에 달려 있습니다. Microsoft는 Windows에서 이를 구동하는 접미사별 리졸버 정책을 문서화하며, 같은 아이디어가 systemd-resolved의 라우팅 도메인과 macOS의 범위 리졸버로 나타납니다.

백업이 응답할 수 있는 영역을 정책에 있는 접미사와 비교하세요. 그 비교는 사용자가 터널 변경 후 내부 사이트 하나가 해석되지 않는다고 보고하기 전에 틈을 찾습니다.

정책을 통해 질의하고, 우회하지 마세요

서버에 직접 질의하면 정책을 우회하고 그 서버가 말할 것만 보고하므로, 운영체제 리졸버를 통해 질의하세요. 두 응답 사이의 틈이 핵심입니다:

resolvectl query intranet.example.com
dig +short intranet.example.com @198.51.100.53

시스템 질의가 사설 주소를 반환하고 직접 질의가 NXDOMAIN을 반환하면 정책이 작동하며 약점은 백업입니다. 둘 다 같은 공용 응답을 반환하면 이름이 의도한 범위 밖에서 해석되고 있으며, 접미사 목록이 살펴볼 곳입니다. 두 출력을 모두 보관하세요. 리졸버 논쟁은 설정 페이지 스크린샷보다 두 줄로 더 빨리 끝납니다.

아무도 시험하지 않은 대체 경로는 가정일 뿐이므로, 그다음 실패 경로를 연습하세요. 한 번의 질의에 대해 선호 리졸버를 블랙홀로 만들고 어느 주소가 돌아오는지 보세요:

ip route add blackhole 198.51.100.53/32
resolvectl query intranet.example.com
ip route del blackhole 198.51.100.53/32

질의가 끝나는 즉시 그 경로를 지우세요. 그렇지 않으면 다음 사람이 수수께끼를 물려받습니다. 그 시간에 내부 이름이 여전히 해석되면 의도한 범위 밖의 무언가가 응답한 것입니다. 대신 시간 초과가 나면 대체 경로가 없거나 올바르게 범위 지정된 것이며, 리졸버 자체 로그가 둘 중 어느 것인지 알려 줍니다.

결정하세요: 유지, 범위 지정 또는 제거

필요한 이름 공간에 응답하고 프로필 아래에서 도달 가능하게 남아 있으면 두 번째 리졸버를 유지하세요. 접미사 하나만 보아야 한다면 범위를 지정하고, 범위도 문서화된 목적도 없다면 제거하세요. 일이 없는 항목은 이득 없는 미래의 유출이며, 공급업체 기본값은 목적이 아닙니다.

결과를 네 열로 기록하세요: 접미사, 리졸버, 인터페이스, 소유자. 그 한 줄은 어떤 스크린샷보다 빨리 다음 감사 질문에 답하며, 목록을 조용히 재정렬하는 클라이언트 업데이트에서도 살아남습니다.