DNS 누출이란 무엇인가 — 그리고 실제로 테스트하는 방법

요약: VPN 터널은 기기가 다른 서버로 보내는 IP 패킷을 암호화합니다. DNS는 패킷이 전송되기 전에 이루어지는 조회 — 기기가 "example.com의 IP 주소는 무엇인가?"라고 묻는 과정입니다. 이 조회가 VPN을 통하지 않고 ISP의 리졸버로 전송되면, ISP는 이후 이어지는 암호화된 트래픽을 보지 못하면서도 도메인은 볼 수 있습니다. 이것이 누출입니다. 가장 단순한 이유로 VPN의 핵심 프라이버시 약속을 무력화합니다: 잘못된 DNS 리졸버에게 요청이 전달된 것입니다. 좋은 소식은 누출을 감지하기 쉽고, 대부분 수정도 쉬우며, 잘 만들어진 VPN 앱은 기본적으로 누출을 방지한다는 점입니다. 나쁜 소식은 "대부분"이 "전부"는 아니며, 몇 가지 흔한 설정이 그렇지 않았다면 올바른 VPN 설정에서도 누출을 유발할 수 있다는 것입니다.

DNS가 실제로 하는 일과 누출이 발생하는 이유

DNS — Domain Name System — 은 인터넷의 주소록입니다. 기기가 웹사이트에 연결할 때마다, 사람이 읽을 수 있는 호스트명(example.com)을 라우터가 실제로 패킷을 전달할 수 있는 숫자 IP 주소(93.184.216.34와 같은 형태)로 먼저 변환해야 합니다. 이 변환 단계가 DNS 쿼리이며, 이후에 오는 실제 웹 요청과는 별개의 네트워크 작업입니다.

일반적인 가정용 인터넷에서 DNS 리졸버는 DHCP를 통해 ISP가 지정합니다 — IP 주소를 배포하는 것과 동일한 방식입니다. Wi-Fi에 연결하면 라우터가 기기에 "DNS 서버는 192.168.1.1이며, ISP의 재귀 리졸버로 전달됩니다"라고 알립니다. 사용자가 조회하는 모든 도메인은 그 리졸버를 통해 흐릅니다. ISP는 이를 기록하거나, 데이터 브로커에게 판매하거나(미국에서는 합법), 법 집행 기관에 제공할 수 있습니다.

VPN에 연결하면 두 가지 일이 일어나야 합니다. 첫째, 네트워크 트래픽이 암호화되어 VPN 터널을 통해 라우팅됩니다. 둘째, DNS 리졸버가 변경되어야 합니다 — ISP의 리졸버에서 VPN 제공업체(또는 암호화된 터널을 통해서만 접근 가능한 제3자 프라이버시 중심 리졸버)가 운영하는 리졸버로요. 첫 번째만 이루어진다면 DNS 누출이 발생합니다. 트래픽은 암호화되지만 트래픽에 앞선 조회는 여전히 ISP로 흘러가, 사용자가 방문하려는 모든 사이트를 ISP에게 알립니다.

프라이버시 관점에서 DNS 쿼리는 트래픽 자체만큼이나 많은 것을 드러냅니다. 쿼리는 정확한 도메인(서브도메인까지 — mail.example.com은 www.example.com과 구별 가능)과 타이밍을 노출합니다. 직후의 암호화된 트래픽 양과 결합하면, DNS가 누출되는 VPN은 관찰자에게 거의 모든 의미 있는 방식으로 브라우징 세션을 재구성하기에 충분한 메타데이터를 제공합니다.

DNS 누출이 발생하는 네 가지 방식

DNS 누출은 단일한 버그가 아닙니다. 각기 다른 근본 원인과 해결책을 가진 관련 잘못된 설정의 집합입니다. 발생 빈도 순으로 나열하면:

1. OS 우회 — Windows 분할 DNS / Smart Multi-Homed Name Resolution

Windows에는 Smart Multi-Homed Name Resolution이라는 기능이 있으며, 이 기능이 활성화되면 VPN이 활성 상태일 때도 물리 인터페이스의 ISP 리졸버를 포함하여 모든 사용 가능한 DNS 리졸버에 병렬로 DNS 쿼리를 전송합니다. 가장 빨리 응답하는 리졸버가 채택되고 나머지는 무시되지만, 쿼리 자체는 이미 전송된 후입니다. 대부분의 Windows 기기에서 이 기능은 기본적으로 켜져 있습니다. 수정 방법은 그룹 정책을 통해 이 기능을 비활성화하거나 연결 시 VPN 클라이언트가 비활성화하도록 설정하는 것입니다. Linux도 systemd-resolved가 올바르게 설정되지 않으면 유사한 문제가 있습니다; macOS와 iOS는 이를 더 잘 처리하지만 완벽하지는 않습니다.

2. 분할 터널 잘못된 설정

분할 터널링을 사용하면 일부 앱은 VPN을 통해, 나머지는 일반 연결을 통해 라우팅할 수 있습니다. 흔한 설정 실수는 앱 기반 분할 터널링을 앱별 DNS 설정 없이 구성하는 것입니다 — VPN 터널 밖으로 라우팅된 앱이 여전히 VPN의 DNS 리졸버를 사용하려 하거나, 반대의 경우가 되어 OS가 제공하는 경로로 누출됩니다. 더 나쁜 변형은: 분할 터널이 앱의 TCP 트래픽을 터널 밖으로 올바르게 라우팅하지만, OS 전체 DNS 리졸버가 여전히 ISP의 리졸버로 설정되어 있어 터널링 여부와 관계없이 모든 앱의 DNS 쿼리가 ISP로 누출됩니다. 이 주제는 분할 터널링이 실제로 하는 일에 대한 글에서 자세히 다룹니다.

3. IPv6 폴백

많은 VPN 클라이언트는 IPv4만 라우팅 고려 대상이었을 때 설계되었습니다. IPv4 방화벽 및 라우팅 규칙을 설치하여 DNS를 터널을 통해 올바르게 라우팅하지만, 일치하는 IPv6 규칙은 설치하지 않습니다. 네트워크에 IPv6 연결이 있으면 OS가 DNS 쿼리에 IPv6를 선호하는 경우가 있으며, 이 쿼리는 VPN을 완전히 우회하여 일반 인터페이스로 나갑니다. 이는 2026년 현재 가장 흔한 누출 방식 중 하나이며, ISP에서 듀얼 스택 IPv4/IPv6를 제공하는 가정용 광대역 연결에서 특히 흔합니다. 수정 방법은 IPv6를 전역적으로 비활성화(강경하지만 안정적)하거나, IPv6 경로를 명시적으로 처리하는 VPN 클라이언트를 사용하는 것입니다.

4. WebRTC 및 브라우저 자체 DNS

Chrome, Edge, Firefox, Safari와 같은 최신 브라우저는 OS 리졸버 대신 직접 DNS 조회를 수행할 수 있습니다. 가장 악명 높은 경우는 화상 채팅에 사용되는 P2P 프로토콜인 WebRTC입니다. WebRTC는 STUN 서버를 사용하여 실제 로컬 및 공개 IP 주소를 발견하며, 과거에는 VPN이 활성화된 경우에도 양쪽 모두를 공개했습니다. WebRTC의 "실제" IP 노출은 오랫동안 브라우저 측 누출 문제였으며 명시적인 완화가 필요합니다. 별도로, DNS-over-HTTPS(DoH)를 사용하는 브라우저는 OS 리졸버 설정과 관계없이 Cloudflare, Google, NextDNS로 직접 DNS 쿼리를 라우팅할 수 있습니다 — 이것이 때로는 도움이 되고(공개 리졸버로의 DoH는 ISP로의 평문보다 더 프라이버시 보호), 때로는 해가 됩니다(공개 리졸버가 여전히 쿼리를 보고, 브라우저가 VPN의 DNS 규칙을 우회합니다).

1분 이내에 DNS 누출을 테스트하는 방법

DNS 누출 테스트는 실제로 하는 것보다 설명이 더 오래 걸립니다. VPN을 연결한 후 다음 세 가지 도구 중 하나를 방문하세요. 각각 누출 표면의 약간씩 다른 측면을 드러냅니다.

dnsleaktest.com

클래식한 도구입니다. dnsleaktest.com을 방문하여 "Extended test"를 클릭하고 약 20초를 기다립니다. 이 도구는 고유한 호스트명에 대한 일련의 DNS 쿼리를 발행하고, 실제로 해당 조회를 수행한 리졸버를 보여줍니다. 리졸버 목록에 ISP 이름(Comcast, Verizon, BT 등)이 보이면 누출이 발생하고 있습니다. VPN 제공업체의 리졸버(또는 Quad9나 Cloudflare의 1.1.1.1 같은 프라이버시 중심 공개 리졸버)만 보이면 OS DNS 경로는 정상입니다.

browserleaks.com/dns

dnsleaktest보다 더 상세합니다. 어떤 리졸버가 쿼리를 처리했는지뿐만 아니라, 지리적 위치, ASN(네트워크 운영자), DNS-over-HTTPS 또는 DNS-over-TLS 지원 여부도 보여줍니다. 올바른 유형의 리졸버가 사용되고 있지만 잘못된 국가에 있는 미묘한 누출을 포착하거나, 암호화된 DNS 프로토콜이 실제로 사용 중인지 확인하는 데 유용합니다.

ipleak.net

가장 포괄적인 도구 — DNS 누출, WebRTC 누출, IPv4 및 IPv6 가시성을 테스트하고 지오로케이션이 어떻게 보이는지 보여줍니다. WebRTC 섹션이 중요합니다: VPN 엔드포인트와 일치하는 "공개 IP" 옆에 192.168.x.x 또는 10.x.x.x 범위의 "로컬 IP" 주소가 노출되어 있다면, VPN은 제 역할을 하고 있지만 브라우저가 WebRTC를 통해 누출되고 있는 것입니다. IPv6 섹션은 dnsleaktest가 놓치는 IPv6 폴백 누출을 포착합니다.

정상 결과와 누출 결과의 비교

올바르게 설정된 VPN으로 dnsleaktest.com의 확장 테스트를 실행하면 다음과 같은 결과가 나타나야 합니다:

Test results (clean): Server: 1.2.3.4 Hostname: dns.vpn-provider.com ISP: VPNProviderCo Country: Netherlands Server: 1.2.3.5 Hostname: dns.vpn-provider.com ISP: VPNProviderCo Country: Netherlands Conclusion: No DNS leak detected. All queries went to the VPN's resolver.

그리고 누출이 있는 경우:

Test results (leaking): Server: 1.2.3.4 Hostname: dns.vpn-provider.com ISP: VPNProviderCo Country: Netherlands Server: 75.75.75.75 Hostname: cdns01.comcast.net ISP: Comcast Country: United States Server: 75.75.76.76 Hostname: cdns02.comcast.net ISP: Comcast Country: United States Conclusion: DNS leak detected. ISP resolver (Comcast) received queries.

핵심 신호는 ISP 열입니다. VPN 제공업체(또는 의도적으로 선택한 공개 리졸버) 외에 다른 것이 나타나면 DNS가 누출되고 있습니다. 국가 열에 VPN 출구 국가와 함께 실제 국가가 표시되면 누출입니다. VPN의 엔드포인트 국가만 나타나면 정상입니다.

누출 유형 비교

네 가지 누출 유형 각각은 테스트 결과에서 뚜렷한 특징, 악용할 수 있는 관찰자 집합, 그리고 고유한 수정 방법을 가집니다:

네 가지 흔한 원인 수정하기

OS 우회 누출 수정 (Windows)

Windows 10 및 11에서 그룹 정책(컴퓨터 구성 → 관리 템플릿 → 네트워크 → DNS 클라이언트 → "스마트 멀티홈 이름 확인 해제" → 사용)을 통해 또는 PowerShell로 Smart Multi-Homed Name Resolution을 비활성화합니다: Set-ItemProperty -Path "HKLM:\SYSTEM\CurrentControlSet\Services\Dnscache\Parameters" -Name "DisableParallelAandAAAA" -Value 1. 재부팅이 필요합니다. 잘 관리되는 일부 VPN 클라이언트는 연결 시 이를 자동으로 처리합니다 — 그렇지 않다면 수동으로 수행하세요.

분할 터널 누출 수정

분할 터널 규칙셋을 점검하세요. 보호되어야 할 앱에 대해 TCP 트래픽 및 DNS 쿼리 모두 터널을 통해 라우팅되는지 확인합니다. 일부 VPN 클라이언트는 앱별 DNS를 설정할 수 있지만, 대부분은 지원하지 않습니다. 지원하지 않는다면 더 안전한 기본값은 분할 터널링을 완전히 비활성화하고 전체 터널을 사용하는 것입니다 — 모든 것(모든 DNS 포함)을 VPN을 통해 라우팅합니다. 대부분의 사용자에게 분할 터널링의 편의 이점은 누출 위험을 감수할 만한 가치가 없습니다.

IPv6 누출 수정

가장 신뢰할 수 있는 수정은 터널 내에서 IPv6를 지원하는 VPN 클라이언트를 사용하는 것입니다(최소한 터널이 활성화될 때 IPv6 트래픽을 차단하는 일치하는 IPv6 방화벽 규칙을 설치). 클라이언트를 변경할 수 없다면 물리 네트워크 인터페이스에서 IPv6를 비활성화하세요: Windows에서는 어댑터 속성에서, macOS에서는 시스템 설정 → 네트워크 → 고급 → TCP/IP에서 할 수 있습니다. 강경한 방법이지만(IPv6 연결을 완전히 잃게 됨) 누출 벡터를 제거합니다.

WebRTC 누출 수정

Firefox에서는 about:config에서 media.peerconnection.enabled를 false로 설정합니다. Chrome 및 Edge에서는 WebRTC Network Limiter 또는 uBlock Origin의 WebRTC 차단 옵션과 같은 확장 프로그램을 설치합니다. Safari는 기본적으로 WebRTC를 더 보수적으로 처리하지만 일부 설정에서는 로컬 IP가 누출될 수 있습니다; Safari 17+에서 이 부분이 크게 개선되었습니다. 변경 후 ipleak.net으로 테스트하세요.

"VPN 사용"만으로는 누출이 없다는 보장이 없는 이유

VPN에 연결하면 자동으로 DNS 누출이 방지된다는 흔한 가정이 있습니다. 그렇지 않습니다 — 방지 여부는 VPN 클라이언트가 시스템 DNS 리졸버 변경, ISP로의 직접 DNS를 차단하는 방화벽 규칙 설치, IPv6 처리, Windows SMHNR 비활성화(또는 동등한 OS 수준 우회 기능), 네트워크 변경(Wi-Fi 로밍, 절전/깨어남 주기)에서도 누출이 재발생하지 않는 것 등 일련의 작업을 올바르게 수행하는지에 달려 있습니다.

잘 만들어진 VPN 클라이언트는 이 모든 것을 자동으로 처리하여 사용자가 신경 쓸 필요가 없습니다. 잘못 만들어진 것 — 또는 추가적인 누출 방지 없이 OS 내장 VPN 프로필을 사용하는 "무료" VPN — 은 일부만 처리하여 누출 벡터를 열어 둡니다. 자신이 어떤 범주에 속하는지 알 수 있는 유일한 방법은 연결 후 실제로 누출 테스트를 실행하는 것입니다. 테스트가 정상으로 돌아오면 걱정하지 않아도 됩니다; 누출이 나타나면 수정할 구체적인 문제가 있고 이제 어떤 것인지 알게 됩니다.

iOS, Android, Mac, Windows에서의 DNS 누출 방지

iOS

iOS는 NetworkExtension 프레임워크를 통해 DNS를 처리합니다. 잘 만들어진 VPN 앱은 NEDNSSettings 객체를 사용하여 터널이 활성화된 동안 사용할 커스텀 리졸버를 지정합니다. iOS는 이를 OS 수준에서 강제합니다 — 앱은 명시적인 권한 없이는 설정된 DNS를 우회할 수 없습니다. iOS의 주요 누출 벡터는 iCloud Private Relay입니다. VPN과 함께 활성화되면 VPN의 리졸버 대신 Apple의 리졸버를 통해 DNS를 라우팅할 수 있습니다. 프라이버시를 위해 VPN을 사용하는 경우, 둘 간의 충돌을 방지하기 위해 iCloud Private Relay를 비활성화하세요. iOS 14는 터널을 통해 시스템 수준 DNS도 전송되도록 보장하는 includeAllNetworks 플래그(종종 킬 스위치 동작과 함께 사용)를 추가했습니다.

Android

Android의 VpnService API는 VPN 클라이언트가 모든 터널링된 트래픽에 적용되는 DNS 서버를 지정할 수 있게 합니다. "항상 사용하는 VPN" 시스템 설정에서 "VPN 없이는 연결 차단" 활성화가 가장 강력한 보장을 제공합니다 — 터널이 활성화되지 않으면 어떤 앱도 DNS를 확인할 수 없습니다. Android는 또한 시스템 전체 프라이빗 DNS를 지원합니다(설정 → 네트워크 및 인터넷 → 프라이빗 DNS). 선택한 제공업체로의 DNS-over-TLS 사용을 강제합니다. 항상 사용하는 VPN과 프라이빗 DNS를 결합하면 DNS 누출에 대한 이중 보호를 제공합니다.

macOS

macOS는 scutil과 System Configuration 프레임워크를 사용하여 DNS 설정을 관리합니다. NetworkExtension 프레임워크를 통해 실행되는 VPN 클라이언트는 터널이 활성화된 동안 우선하는 DNS 설정을 설치할 수 있습니다. macOS의 주요 누출 벡터는 브라우저 수준 DNS-over-HTTPS로, 시스템 리졸버를 완전히 우회합니다 — 브라우저 수준 DoH를 비활성화하거나 VPN의 리졸버와 동일한 리졸버를 가리키도록 설정하세요. 터미널에서 scutil --dns로 활성 리졸버를 확인하세요; 최우선 순위 섹션에는 VPN의 리졸버만 나타나야 합니다.

Windows

Windows는 주요 OS 중 가장 큰 누출 표면을 가집니다, 주로 Smart Multi-Homed Name Resolution 때문입니다. SMHNR 비활성화(위에서 다룸) 외에도, VPN의 가상 어댑터가 물리 어댑터보다 높은 메트릭 우선순위를 가지는지, IPv6가 비활성화되거나 올바르게 터널링되는지, 앱이 자체 DNS 재정의로 설정되어 있지 않은지 확인하세요. Windows 11은 개선된 DNS 설정 UI를 추가했지만 기본 동작은 Windows 10과 유사합니다. ipconfig /all 명령은 인터페이스별 활성 리졸버를 보여줍니다.

좋은 VPN 앱이 누출 방지를 위해 내부적으로 하는 일

잘 설계된 VPN 클라이언트는 DNS 누출에 대해 생각할 필요가 없게 합니다. 연결 과정의 기본적인 부분으로 처리합니다. 구체적으로:

• 연결 시 커스텀 리졸버를 설정합니다. 클라이언트는 OS에 "연결된 동안 모든 DNS 쿼리는 이 특정 IP 주소로 전송됩니다" — 일반적으로 터널을 통해서만 접근 가능한 VPN 제공업체 자체 리졸버 — 라고 알립니다. 클라이언트는 연결 해제 시 이전 DNS 설정도 복원합니다.
• 직접 DNS를 차단하는 방화벽 규칙을 설치합니다. 앱이 자체적으로 DNS 서버를 조회하려 해도(예: 8.8.8.8으로 하드코딩된 쿼리), 방화벽 규칙이 UDP 포트 53의 아웃바운드 패킷을 차단합니다. 기기를 떠날 수 있는 DNS는 터널을 통해 흐르는 것뿐입니다.
• 터널 내에서 암호화된 DNS(DoT 또는 DoH)를 사용합니다. 쿼리가 터널 안으로 들어간 후에도, 리졸버에서 서버로의 홉은 DNS-over-TLS(RFC 7858) 또는 DNS-over-HTTPS로 암호화되어 업스트림 운영자가 쿼리 내용을 볼 수 없습니다. DNS-over-HTTPS vs DNS-over-TLS에 대한 글에서 두 프로토콜 간의 장단점을 다룹니다.
• IPv6를 명시적으로 처리합니다. IPv6 경로는 VPN을 통해 터널링되거나(선호), IPv6 폴백을 방지하기 위해 방화벽에서 차단됩니다. 클라이언트는 IPv6 라우팅을 미설정 상태로 두지 않습니다.
• 킬 스위치와 짝을 이룹니다. 터널이 일시적으로 끊어지면 킬 스위치가 터널이 재확립될 때까지 DNS를 포함한 모든 트래픽을 차단합니다. 이는 "터널 끊김, DNS 누출, 터널 복구" 경쟁 조건을 방지합니다. 이에 대해서는 VPN 킬 스위치란 무엇인가에서 자세히 다룹니다.
• 매 연결마다 테스트합니다. 일부 클라이언트는 매 연결 후 내장 누출 테스트를 실행하여 이상 징후를 사용자에게 알립니다. 드물지만 가장 강력한 모델입니다.

Casper's Cloak은 WireGuard 터널 내에서만 접근 가능한 커스텀 DNS 리졸버를 사용하며, DNS-over-TLS를 통해 종단간 암호화되고, IPv6 경로는 명시적으로 터널링되며, Windows SMHNR은 설치 시 비활성화됩니다. 위협 방지 기능은 동일한 리졸버에서 알려진 악성 도메인에 대해 DNS 수준 필터링을 수행하므로, 누출 방지된 DNS가 피싱 및 악성 소프트웨어도 적극적으로 차단합니다. 이 메커니즘은 DNS 수준 필터링이 실제로 작동하는 방식에 대한 글에 문서화되어 있습니다. 결합된 효과: 기본적으로 올바르게 설정되고, 네 가지 흔한 실패 모드 중 어떤 것에서도 누출이 없으며, 그 위에 적극적인 필터링까지 있습니다.

기반 프로토콜 배경으로, DNS-over-TLS의 IETF 명세는 TLS 보안 채널을 통해 DNS를 전송하기 위한 암호화 및 전송 계층 요구 사항을 다루는 RFC 7858에 문서화되어 있습니다. 동일한 프레임워크가 프라이버시 중심 공개 리졸버(Cloudflare, Quad9, NextDNS)가 보안 DNS 엔드포인트에 사용하는 것입니다.

결론: DNS 누출은 VPN의 프라이버시 약속이 조용히 실패하는 가장 흔한 방식입니다. 테스트하기 쉽고, 대부분 수정도 쉬우며, 신뢰하는 VPN이라면 수동 개입 없이 누출 테스트를 통과해야 합니다. 그렇지 못하다면 그것은 신호입니다 — 잘못된 설정이거나 다른 VPN으로 이동할 때입니다.