VPN DNS 누수 원인과 해결을 위한 DNS 요청 흐름 이해하기

VPN 사용 시 DNS 누수는 DNS 요청이 어느 경로로 나가는지에 따라 발생합니다. 전체 터널과 분할 터널, 그리고 Windows 네트워크 우선순위 문제까지 DNS 노출 원인을 자세히 설명합니다.

Mar 08, 2026

Contents

DNS 요청 흐름, 한 줄로 잡고 가기 VPN을 켰을 때 DNS가 새는(노출되는) 대표 지점 3곳 “그럼 VPN 쓰면 DNS는 누가 처리해요?” 현실적인 시나리오 4가지 흔한 오해 3개만 정리하고 끝내기 핵심 정리: “DNS 노출은 길(라우팅) 싸움”이에요

DNS 요청 흐름, 한 줄로 잡고 가기

DNS는 “사람이 읽는 주소(도메인)”를 “컴퓨터가 가는 주소(IP)”로 바꿔주는 전화번호부 같은 존재예요. NordVPN 자료에 따르면, 사용자가 도메인을 입력하면 장치가 DNS 리졸버(해석해주는 서버)로 쿼리를 보내고, 리졸버가 캐시를 보거나 다른 DNS 서버에 물어봐서 IP를 찾아오거든요(https://nordvpn.com/ko/features/private-dns/).

VPN을 켰다고 이 전화번호부 문의가 무조건 숨겨지는 건 아니고, “DNS가 어느 길(라우팅)로 나가느냐”에 따라 노출 지점이 달라집니다.

제가 2023년에 독일(프랑크푸르트) 리전의 AWS Client VPN 환경을 점검해드렸던 케이스에서도, 분할 터널 설정 때문에 DNS가 로컬 ISP로 빠져서 사내 도메인 질의가 그대로 보이는 상황이 실제로 나왔거든요.

도메인 입력부터 DNS 리졸버와 권한 서버를 거쳐 IP를 받아오는 DNS 요청 흐름 요약

VPN을 켰을 때 DNS가 새는(노출되는) 대표 지점 3곳

1) 내 PC/폰에서 “어느 DNS를 쓸지” 결정하는 순간

VPN 연결이 되면 보통 VPN이 “이 DNS 서버 써요”라고 장치에 알려주거나, 반대로 장치가 기존에 쓰던 로컬 DNS(집 공유기/통신사 DNS/공용 DNS)를 계속 쓰기도 해요. 여기서부터 갈림길이 시작이죠.

실무에서 이 포인트가 중요한 이유는, VPN을 ‘켜는 행위’보다 “DNS 서버가 실제로 뭘로 잡혔는지”가 누수 여부를 거의 결정해버리는 경우가 많아서예요.

특히 회사/클라우드 쪽 구성에서는 VPN 엔드포인트에 DNS 서버 IP를 지정할 수 있는데, AWS re:Post에 따르면 AWS Client VPN은 DNS 서버를 지정하지 않으면 클라이언트 장치의 로컬 DNS를 사용합니다(https://repost.aws/ko/knowledge-center/client-vpn-how-dns-works-with-endpoint).

즉, “VPN은 켰는데 DNS는 원래대로 통신사 쪽으로 물어보는” 그림이 나올 수 있어요. 이때는 DNS 요청이 VPN 밖으로 나가서, 로컬 네트워크나 ISP(통신사) 관점에서 “어떤 도메인 물어봤는지”가 보일 여지가 생깁니다(환경마다 다를 수 있어요).

VPN 연결 시 클라이언트가 VPN DNS 또는 로컬(공유기/통신사) DNS 중 무엇을 쓰는지 결정하는 분기점

2) 라우팅이 갈리는 지점: 전체 터널 vs 분할 터널

VPN은 크게 두 가지 모드가 흔해요.

전체 터널(Full tunnel): 인터넷 트래픽을 전부 VPN로 태워요

분할 터널(Split tunnel): 회사망/VPC 같은 특정 대역만 VPN로, 나머지 인터넷은 원래 인터넷으로 나가요

이 차이가 DNS에 그대로 영향을 줍니다. Security Stack Exchange 답변에서도 핵심을 “0.0.0.0(기본 경로)가 VPN 게이트웨이로 잡히는지에 달렸다”고 정리해요(https://security.stackexchange.com/questions/13900/if-i-use-a-vpn-who-will-resolve-my-dns-requests).

기본 경로가 VPN으로 가면 DNS도 보통 VPN을 타기 쉽고, 기본 경로가 로컬로 남아 있으면 DNS가 로컬로 빠질 확률이 커지죠.

여기서 흔한 오해 하나. “VPN이면 DNS 요청도 무조건 암호화돼요?”

Baeldung 자료에서는 VPN이 모든 인터넷 트래픽을 라우팅/암호화하는 구성이라면 DNS 요청도 ISP 통제 밖(즉, VPN 터널 안)으로 들어간다고 설명합니다(https://www.baeldung.com/cs/dns-request-vpn). 다만 이건 “정말로 DNS가 VPN 터널로 들어가도록 라우팅된 경우”에 해당하는 얘기예요. 분할 터널이거나, DNS 서버가 로컬로 잡혀 있거나, 우선순위가 꼬이면 예외가 생깁니다.

전체 터널과 분할 터널에서 기본 경로(0.0.0.0/0) 설정에 따라 DNS 트래픽이 VPN으로 가는지 갈리는 구조

3) OS 네트워크 우선순위/어댑터 바인딩이 꼬이는 지점(특히 Windows)

“설정은 VPN DNS로 해놨는데 왜 자꾸 다른 DNS로 나가요?” 같은 상황이 은근 흔하거든요. AWS re:Post에 따르면 Windows에서 네트워크 어댑터 바인딩 순서(우선순위) 문제로 OpenVPN 클라이언트가 VPN 어댑터 대신 기본 네트워크 어댑터의 DNS 설정을 사용하는 경우가 있습니다(https://repost.aws/ko/knowledge-center/client-vpn-fix-dns-query-forwarding).

쉽게 말해, 길 안내 표지판이 두 개 있는데 OS가 “이 길이 더 빠르네?” 하고 엉뚱한 출구로 DNS를 내보내는 거예요.

이 경우 노출은 “VPN 밖으로 DNS가 새는 것”뿐 아니라, 내부망 이름(예: 사내 전용 도메인)을 외부 DNS에 물어보는 바람에 쿼리가 쓸데없이 밖으로 나가는 형태도 생길 수 있어요(환경에 따라 재현 여부는 다릅니다).

“그럼 VPN 쓰면 DNS는 누가 처리해요?” 현실적인 시나리오 4가지

1) VPN 사업자/회사 DNS가 처리

VPN이 전용 DNS를 푸시하고, DNS 트래픽도 터널로 들어가면 이 케이스예요. 외부에서 보면 DNS는 “VPN 서버 쪽에서 나가는 것”처럼 보입니다.

2) 내가 원래 쓰던 로컬 DNS(공유기/통신사/공용 DNS)가 처리

VPN은 켰지만 DNS 설정이 안 바뀌었거나, 분할 터널/우선순위 문제로 로컬로 나가면 이 케이스가 됩니다.

3) 특정 목적지만 VPN DNS, 나머진 로컬 DNS(혼합형)

기업 환경에서 내부 도메인만 내부 리졸버로 보내고, 일반 인터넷은 로컬 DNS로 보내는 설계가 있을 수 있어요. 설정이 깔끔하면 효율적이지만, 헷갈리면 “어디까지가 VPN 보호 구간인지” 사용자가 체감하기 어렵습니다.

4) 클라우드 내부 프라이빗 DNS를 VPN 통해 처리

AWS Client VPN 같은 구성에서 VPC 내부 리소스 이름을 풀어야 하면, Route 53 Resolver 인바운드 엔드포인트 같은 걸로 프라이빗 DNS 확인을 붙일 수 있어요. AWS re:Post 자료에서도 이런 방식으로 VPC 내 프라이빗 DNS 확인이 가능하다고 설명합니다(https://repost.aws/ko/knowledge-center/client-vpn-how-dns-works-with-endpoint).

VPN 사용 중 DNS가 노출될 수 있는 대표 지점 3가지를 카드 형태로 정리한 그림

흔한 오해 3개만 정리하고 끝내기

1) “VPN 켜면 방문한 사이트가 완전히 안 보이죠?”

VPN은 “누가 내 트래픽을 중간에서 보느냐”를 바꾸는 기술에 가깝고, DNS가 어디로 가는지/HTTPS가 제대로 적용됐는지에 따라 보이는 정보가 달라요. 특히 DNS가 로컬로 나가면 도메인 질의 자체는 밖에서 관찰될 수 있습니다.

참고로 이런 ‘DNS 질의가 평문으로 관찰될 수 있다’는 전제는 DNS의 기본 동작(RFC 1034/1035)에서도 드러나는 부분이라, 결국 보호하려면 라우팅뿐 아니라 DNS 암호화(DoT/DoH)나 터널링 정책까지 같이 봐야 하거든요.

2) “DNS만 VPN으로 보내면 끝 아닌가요?”

DNS는 ‘어디로 갈지 묻는’ 단계고, 실제 접속 트래픽이 VPN 밖으로 나가면 다른 메타데이터가 남을 수 있어요. 반대로 트래픽은 VPN인데 DNS만 로컬이면 “DNS 누수”처럼 보일 수 있고요. 결국 둘이 한 팀플레이입니다.

3) “설정은 맞는데 가끔 새는 건 제 탓이죠?”

꼭 그렇진 않아요. 특히 Windows는 어댑터 우선순위 같은 OS 레벨 변수로 의도와 다르게 동작할 수 있다고 AWS re:Post에서 짚습니다(https://repost.aws/ko/knowledge-center/client-vpn-fix-dns-query-forwarding). 사용자가 멍청해서가 아니라, 네트워크가 원래 좀… 성격이 급해요.

VPN에서 DNS 누수를 줄이기 위한 설정/대응 체크리스트(전용 DNS, 전체 터널, DoH/DoT, IPv6, 킬스위치)

핵심 정리: “DNS 노출은 길(라우팅) 싸움”이에요

다만, 이 글에서 말한 내용은 ‘일반적인 VPN + 일반적인 DNS 리졸버 구성’ 기준이라서, 회사에서 강제 프록시/보안 에이전트/전용 DNS 암호화 정책(DoH/DoT)을 같이 쓰는 환경이면 흐름이 달라질 수 있어요.

DNS 요청은 “도메인 → IP” 변환을 위한 문의이고, VPN을 켰을 때도 이 문의가 어디로 나가는지에 따라 노출 지점이 달라집니다(NordVPN 자료 참고).

전체 터널이면 DNS도 VPN으로 들어갈 가능성이 크지만, 분할 터널/기본 경로 설정에 따라 로컬로 빠질 수 있어요(Security Stack Exchange 자료 맥락).

클라우드/기업 VPN은 DNS 서버를 따로 지정할 수 있고, 지정 안 하면 로컬 DNS를 쓰는 식으로 동작할 수 있습니다(AWS re:Post).

Windows에선 어댑터 우선순위 때문에 “VPN DNS 설정이 무시되는” 케이스도 실제로 보고됩니다(AWS re:Post).

원하시면, 지금 쓰는 환경(윈도우/맥, VPN 앱 이름, 전체 터널인지 분할 터널인지, DNS를 수동으로 바꿨는지)만 알려주시면 “어느 단계에서 노출될 가능성이 큰지”를 흐름도로 딱 찍어서 정리해드릴게요.