DNS 유출은 어떻게 확인할까? 프록시 DNS 문제 4단계 점검법

핵심 요약: IP 검사를 통과했다는 것은 접속 출구가 바뀌었다는 뜻일 뿐, DNS 쿼리도 같은 경로를 지났다는 뜻이 아닙니다. 프록시와 DNS는 서로 다른 두 구간을 맡습니다. 프록시는 연결이 어느 네트워크 출구로 나가는지를 정하고, DNS는 도메인 이름을 IP로 바꿉니다. 이름 풀이 쿼리가 예상 밖의 경로를 지나가면 그것이 DNS 유출입니다. 확인은 네 단계면 충분하지만, 테스트를 실행하는 것보다 결과를 읽어 내는 일이 더 중요합니다.

프록시를 설정하고 IP 확인 사이트를 열면 화면에는 프록시 IP가 표시됩니다. 그래서 네트워크 환경에 문제가 없다고 넘어갑니다. 며칠 뒤 계정 이상을 조사해서야 DNS 쿼리가 줄곧 로컬 회선으로 나가고 있었음을 알게 됩니다.

원인이 프록시 자체가 아닐 수 있습니다. DNS 쿼리가 애초에 프록시 경로를 밟아 본 적이 없을 가능성이 있습니다.

프록시를 켰는데도 DNS를 확인해야 하는 이유

프록시와 DNS는 별개의 두 구간이며, 프록시를 켰다는 것이 DNS까지 넘겨받았다는 뜻은 아닙니다. 프록시는 연결을 어느 네트워크 출구로 보낼지 정하고, DNS는 도메인 이름 풀이를 담당합니다. 둘은 서로 다른 네트워크 단계에 관여하므로, 프록시가 정상 작동한다고 해서 DNS 쿼리가 기대대로라고 할 수 없습니다.

실제 요청의 흐름으로 보겠습니다. 사이트에 접속할 때 클라이언트는 DNS 쿼리로 대상 도메인의 IP를 먼저 얻거나, 도메인 이름을 프록시 쪽에 맡기거나 둘 중 하나입니다. 어느 쪽이 될지는 프록시 프로토콜, 클라이언트 구현 방식, 브라우저의 DNS 설정이 정합니다. 프록시를 켰다고 해서 모든 풀이 쿼리가 예상 경로를 따라간다고 자동으로 단정할 수는 없습니다. 판단은 실제 검사에 맡겨야 하며, 프록시가 "연결됨"으로 표시된다는 이유만으로 안심할 일이 아닙니다.

한 가지 경계선도 분명히 해 둡니다. DNS 유출은 실제 공개 IP 노출과 같은 말이 아닙니다. 새어 나가는 것은 도메인 쿼리의 경로이며, 어떤 도메인을 조회했는지를 해석 서비스 제공자나 로컬 네트워크가 볼 수 있습니다. 실제 IP가 노출됐는지는 별도의 IP 검사로 판단합니다. 싱가포르 사이버보안국은 VPN 보안 권고에서 DNS 유출 테스트와 IP 주소 노출 테스트를 두 가지 독립된 검사로 꼽았습니다. 이유는 다름 아니라, 두 검사가 같은 문제를 검증하지 않기 때문입니다(CSA의 VPN 보안 지침 참고).

DNS 유출은 보통 어떻게 생기는가

가장 흔한 원인은 세 가지이며, 모두 설정과 관련될 뿐 프록시의 우열과는 무관합니다. 하나씩 살펴봅니다.

프록시가 일부 트래픽만 처리하는 경우

프록시 설정에 따라서는 브라우저의 웹 요청만 넘겨받고 이름 풀이는 로컬 시스템이 맡는 경우가 있습니다. 그렇게 되는지는 프록시 프로토콜과 클라이언트의 처리 방식에 달려 있습니다. 웹 요청은 프록시로, 풀이 쿼리는 로컬로 나가는 상태라면, 검사 결과에 로컬 네트워크의 리졸버가 나타납니다.

브라우저의 보안 DNS가 따로 켜져 있는 경우

Chrome과 Firefox는 모두 DNS over HTTPS(DoH)를 지원합니다. 켜 두면 풀이 쿼리가 암호화된 HTTPS 연결로 지정된 해석 서비스에 전달되어, 로컬 네트워크가 쿼리를 직접 훔쳐볼 기회를 줄일 수 있습니다. 다만 암호화가 곧 쿼리가 프록시를 지난다는 뜻은 아니고, 고른 해석 서비스가 현재 환경의 기대에 부합한다는 보장도 없습니다. Firefox의 이 기능은 따로 켜고 끌 수 있습니다. 자세한 내용은 Mozilla 공식 문서를 참고하세요.

시스템·브라우저·프록시 클라이언트가 각자 다른 설정을 쓰는 경우

가장 알아채기 어려운 유형입니다. 시스템은 하나의 리졸버를 쓰고, 브라우저는 DoH를 켜서 또 다른 리졸버로 바꾸고, 프록시 클라이언트는 하나를 더 설정합니다. 겹치고 겹치면 풀이 경로는 블랙박스가 됩니다. 프록시 프로그램이 "연결됨"을 표시하는 것만으로는 판단할 수 없고, 실제로 돌아가는 브라우저가 어느 경로를 지났는지 봐야 합니다.

풀이 경로가 로컬 ISP에 놓이면 쿼리는 ISP의 해석 서비스를 지나갑니다. ISP 프록시의 원리와 활용 상황 글을 함께 참고할 수 있습니다.

DNS 유출 확인 방법: 네 단계

검사 자체는 어렵지 않습니다. 관건은 검사 전에 기대치를 세우고, 검사 후에 대조하는 것입니다. 이 네 단계를 거쳐야 결론이 서게 됩니다.

1단계: 예상 결과를 먼저 적어 둡니다. 검사 전에 세 가지를 분명히 합니다. 지금 프록시의 출구가 어느 지역인지, 도메인 풀이는 누가 맡아야 하는지, 브라우저에서 DoH가 켜져 있는지. 기대치가 없으면 결과를 봐도 판단할 수 없습니다.

2단계: 프록시를 켠 상태로 테스트를 돌립니다. DNS 유출 검사를 지원하는 사이트를 이용합니다. 예컨대 dnsleaktest.com에서 확장 테스트(Extended test)를 실행하면 화면에 더 많은 리졸버가 표시됩니다. BrowserLeaks의 DNS 검사 페이지에서 리졸버의 소속 조직을 확인할 수도 있습니다. 리졸버 이름, 소속 조직, 지역을 적어 둡니다.

3단계: 기대치와 대조해 판단합니다. 결과의 리졸버가 지금의 시스템·브라우저·프록시 설정과 맞는지 확인합니다. 리졸버가 기대했던 DNS 서비스에 속하고 뜻밖의 로컬 풀이 경로가 없다면, 이번 테스트는 기대대로라고 1차 판단할 수 있습니다. 로컬 ISP나 낯선 해석 서비스가 나오면, 먼저 그것이 정말 예상 밖의 설정에 속하는지 확인합니다. 그다음 프록시 클라이언트의 DNS 처리, 브라우저 보안 DNS, 시스템 네트워크 설정을 한 항목씩 짚어 봅니다. 곧바로 프록시 고장으로 몰아가지 않습니다. 한 번의 검사는 그때의 테스트 조건을 반영할 뿐, 모든 요청에 문제가 없음을 보장하지는 않습니다.

4단계: 설정을 한 곳만 고쳐 다시 검사합니다. 고치더라도 한 번에 한 곳입니다. 프록시 클라이언트의 DNS 처리, 브라우저 DoH 스위치, 시스템 네트워크 설정 중 하나를 바꾸고 나서 다시 검사해 비교합니다. 여러 항목을 한꺼번에 바꾸면 어느 변경이 효과를 냈는지 알 수 없게 됩니다.

검사 결과 읽는 법

같은 결과라도 읽는 법을 틀리면 단서가 오독으로 바뀝니다. 자주 나오는 다섯 가지 결과와 각각의 대응입니다.

함정이 하나 더 있습니다. 공용 리졸버는 대개 Anycast와 분산 노드를 쓰기 때문에, 검사 페이지에 표시되는 리졸버 위치가 실제로 쿼리를 처리하는 서버 위치와 일치하지 않을 수 있습니다. 그렇다고 유출인 것도 아닙니다. 판단의 기준은 언제나 쿼리가 예상 밖 경로를 지났는지 여부입니다. 낯선 지역의 리졸버가 보여도 설정부터 확인하고 결론을 내립니다.

DNS 유출, WebRTC 유출, 브라우저 지문은 무엇이 다른가

네 가지 검사는 각각 다른 정보를 들여다보며, 한 항목을 통과했다고 다른 항목도 통과한 것이 아닙니다. 나란히 놓고 봐야 경계가 가장 분명합니다.

DNS와 WebRTC는 둘 다 "유출"이라는 말이 붙어서 가장 헷갈리기 쉬운 한 쌍입니다. 그러나 검사 원리도 대응 방식도 완전히 다릅니다. WebRTC 유출의 검사와 설정 방법은 별도 글에서 다뤘으니 여기서는 넘어갑니다. 한편 IPv6 유출은 같은 계열의 또 한 항목으로, IPv6 주소가 프록시를 우회하는지를 봅니다. 방법은 IPv6 유출 검사 방법 글을 참고하세요.

이 네 항목은 서로 다른 정보를 반영하며 하나가 다른 하나를 대신할 수 없습니다. 프록시 환경을 점검할 때는 공개 IP를 먼저 확인하고, 다음으로 DNS와 WebRTC를 보고, 마지막에 지문과 환경 설정을 대조하는 순서를 권합니다. 항목의 우선순위는 실제 상황에 맞춰 정하면 됩니다.

MostMate를 쓸 때 이 검사들을 절차에 어떻게 배치할까

점검 순서는 출구 먼저, 다음 풀이, 다음 WebRTC, 마지막으로 환경 설정입니다. MostMate로 여러 브라우저 환경을 관리할 때는 프록시 연결 확인과 DNS 유출 검사를 나눠 진행할 수 있습니다.

프록시 설정이 첫 번째 항목입니다. 환경에 프록시를 묶은 뒤 제품 안의 프록시 테스트로 연결 상태를 확인하고, 프로토콜 종류(HTTP, HTTPS, SOCKS5, SSH)와 인증 정보도 함께 대조합니다. 프록시 테스트 통과가 DNS 유출 검사를 대신하지는 않습니다. DNS 쿼리의 실제 경로는 프록시 클라이언트, 브라우저, 시스템 설정에 따라 달라지기 때문입니다.

그다음에는 해당 프록시를 묶은 환경에서 DNS 검사 페이지를 엽니다. 방법은 앞의 네 단계와 같습니다. 리졸버 소속이 기대에 맞는지 봅니다.

두 번째는 환경 자체의 분리입니다. 멀티 계정 상황에서는 환경별 프록시, Cookie, 지문 매개변수가 각자 독립되도록 하고 서로 빌려 쓰지 않습니다. 분리의 구체적 범위는 브라우저 환경 분리의 범위와 설정 글을 참고하세요. 환경의 프록시를 잘못 묶거나 설정을 공유하면 검사 결과는 대조의 의미를 잃습니다. 분리는 세션과 설정 관리에 도움을 주지만, DNS 경로가 저절로 올바라지는 않으며 외부 검사를 대신하지도 못합니다.

세 번째, 경계선을 기억합니다. 지문 브라우저의 역할은 환경을 가지런히 정리하는 것이고, 프록시가 실제로 작동하는지, DNS가 기대 경로를 지나는지는 여전히 외부 검사로 확인해야 합니다. 검사를 통과했다고 끝이 아니며, 설정 변경이나 시스템 업데이트 후에는 다시 검사하는 편이 좋습니다.

자주 묻는 질문

프록시를 켰는데 DNS 검사에 로컬 리졸버가 나옵니다. 프록시가 고장 난 건가요?

단정할 수 없습니다. 프록시가 웹 요청만 넘겨받고 풀이 쿼리는 시스템이나 브라우저가 따로 처리하고 있을 가능성이 있습니다. 프록시 클라이언트의 DNS 처리와 브라우저 DoH 설정을 한 항목씩 확인하고, 하나를 고칠 때마다 검사해 보세요.

DNS 유출로 실제 IP가 노출되나요?

곧바로 같다고 볼 수 없습니다. DNS 유출이 비추는 것은 도메인 풀이 요청의 경로이며, 실제로 무엇이 노출되는지는 네트워크 설정과 검사 상황에 따라 달라집니다. 실제 공개 IP가 숨겨져 있는지는 별도의 IP 검사로 확인하고, DNS 풀이 경로는 따로 점검합니다.

지문 브라우저를 써도 DNS 유출이 생기나요?

생길 수 있습니다. 지문 브라우저가 관리하는 것은 환경 분리와 지문 매개변수입니다. DNS 동작은 프록시 프로토콜과 시스템·브라우저 설정에 달려 있으므로 검사는 생략할 수 없습니다.

DNS 검사를 통과한 뒤에는 무엇을 더 확인해야 하나요?

WebRTC 유출과 브라우저 지문 두 항목이 남아 있습니다. 각자 맞는 도구로 검증합니다. 모두 통과해야 이 환경의 네트워크 계층 점검이 끝납니다.

맺음말

DNS 유출 검사의 가치는 "통과"나 "실패" 판정을 받는 데 있지 않고, 지금 환경의 네트워크 요청이 기대에 부합하는지 확인하는 데 있습니다. 공개 IP, DNS, WebRTC, 브라우저 지문에는 각자 맞는 검사 방법이 있으며, 한 항목의 결과로 다른 항목의 검증을 대신할 수 없습니다. 어떤 지문 브라우저를 쓰든 프록시나 네트워크 설정이 바뀐 뒤에는 다시 검사하기를 권합니다.

여러 브라우저 환경을 관리해야 한다면, 먼저 MostMate의 환경 설정과 프록시 관리 방식을 살펴보고 이 글의 절차대로 하나씩 검증해 보세요. 프록시 계층을 더 안정적으로 구성하고 싶다면 MostMate 다운로드에서 받을 수 있습니다. 무료 버전은 환경 두 개까지 제공되니, 먼저 첫 환경의 검사 절차를 끝까지 돌려 보세요.