요약: 스마트폰의 앱이 analytics.facebook.com에 연결하려 할 때, 먼저 DNS를 통해 해당 호스트명의 IP 주소를 조회해야 합니다. 필터링 DNS 리졸버는 이 조회를 가로채고, 해당 목적지가 트래커임을 인식한 뒤 IP 주소 반환을 거부합니다. 연결이 열리지 않으며, 데이터는 기기를 벗어나지 않습니다. 이는 우아하고 강력한 방식이지만, 정직한 논의라면 반드시 언급해야 할 네 가지 한계가 있습니다. 암호화된 트래픽 내용을 볼 수 없고, 동일 도메인에서 제공되는 광고는 필터링할 수 없으며, 일부 앱은 시스템 DNS를 완전히 우회하고, 암호화 DNS 프로토콜(DoH/DoT/ECH)이 네트워크 가시성 환경을 변화시키고 있습니다. 아래에서 메커니즘을 먼저 설명하고, 각각의 한계와 DNS 필터링이 여전히 강점을 발휘하는 영역을 차례로 살펴봅니다.
메커니즘, 다섯 단계로
스마트폰에서 발생하는 모든 네트워크 연결은 다음 순서로 진행됩니다(의식하든 그렇지 않든):
- 앱이 서버에 접속하려 합니다. Instagram이 스토리를 로드하려 하거나, Facebook SDK가 핑거프린트 데이터를 전송하려 하거나, Safari가 웹 페이지를 열려 합니다. 이 모든 과정은 호스트명으로 시작됩니다 —
graph.facebook.com,cdn-news.com,www.example.com. - OS가 DNS에 호스트명의 IP를 요청합니다. 컴퓨터는
graph.facebook.com에 직접 통신하지 않습니다 —157.240.22.174와 통신합니다. DNS는 호스트명을 IP로 변환하는 디렉터리 역할을 합니다. - DNS 쿼리가 리졸버로 전달됩니다. VPN 없이는 보통 ISP의 리졸버나 사용자가 설정한 DNS(일반적으로 Google의
8.8.8.8또는 Cloudflare의1.1.1.1)로 쿼리가 전송됩니다. Casper나 다른 DNS 필터링 도구를 사용하면, 쿼리는 암호화된 터널을 통해 저희 리졸버로 전달됩니다. - 필터링 리졸버가 목적지를 평가합니다.
graph.facebook.com이 트래커 차단 목록에 있나요? 피싱 도메인 ML 분류에 해당하나요? 사용자 맞춤 허용 목록에 있나요? 평가는 한 자릿수 밀리초 단위로 이루어집니다. - 리졸버가 응답을 반환하거나 거부합니다. 정상 도메인의 경우: 실제 IP가 반환되고, 앱이 연결되며, 정상적으로 진행됩니다. 차단된 도메인의 경우: "NXDOMAIN" 또는
0.0.0.0응답이 반환되고, 앱의 연결 시도가 실패하며, 데이터는 기기를 벗어나지 않습니다.
이것이 전체 메커니즘입니다. 기기 내 DPI 트릭도, 커널 훅도, 인증서 삽입 같은 꼼수도 없습니다. 모든 IP 연결은 호스트명 조회로 시작해야 하며, 그 조회는 리졸버가 제어하는 평문입니다. 조회를 거부하면 연결도 거부됩니다.
이 방식이 유독 강력한 이유
세 가지 구조적 특성이 DNS 수준 필터링을 비례적으로 효과적으로 만듭니다:
- 앱을 가리지 않습니다. 브라우저 확장 프로그램은 설치된 브라우저만 보호합니다. Safari 콘텐츠 차단기는 Safari만 보호합니다. Casper의 DNS 필터는 Instagram, YouTube 앱, 날씨 위젯, 스마트 TV 스트리밍 앱, Mail, Slack, Mac의 모든 메뉴바 유틸리티 등 DNS 조회를 수행하는 모든 것을 보호합니다.
- 프로토콜을 가리지 않습니다. HTTP, HTTPS, WebSocket, 맞춤형 바이너리 프로토콜 등 DNS 조회로 시작하는 모든 것이 필터링됩니다. 그 위의 암호화 계층은 관계없습니다 — 리졸버는 암호화 협상이 시작되기 전에 가로챕니다.
- 중앙 집중식입니다. 계정의 모든 기기가 하나의 설정 업데이트로 동일한 보호를 받습니다. 브라우저 확장 프로그램 군집 관리가 필요 없습니다.
이것이 DNS 수준 도구(Pi-hole, NextDNS, AdGuard DNS, 그리고 저희 Casper)가 지난 5년간 소비자 프라이버시 필터링의 지배적인 패턴이 된 이유입니다. 하지만 강력함은 양날의 검입니다 — DNS 필터링이 실패할 때는 조용히, 그리고 대규모로 실패하는 경향이 있습니다.
한계 1 — 암호화된 트래픽 내부를 볼 수 없습니다
DNS 필터링은 URL이나 페이로드가 아닌 호스트명을 기준으로 동작합니다. 도메인이 전체 차단 목록에 있으면 해당 도메인의 모든 페이지와 엔드포인트가 차단됩니다. 도메인이 전체 허용 목록에 있으면 해당 도메인의 모든 페이지와 엔드포인트가 허용됩니다. DNS 계층에는 중간 지점이 없습니다 — IP가 해석되면 리졸버는 앱이 다음에 무엇을 하는지 볼 수 없습니다.
이는 전용 서브도메인을 사용하는 대부분의 추적 인프라에는 문제가 없습니다: analytics.facebook.com, tag-manager.google.com, events.amplitude.com. 서브도메인을 차단하면 호스트 사이트는 그대로 동작하면서 분석 기능만 차단됩니다. 하지만 광고나 트래커가 정상 콘텐츠와 동일한 도메인을 사용하는 경우는 어려운 문제입니다 — Instagram은 Meta의 자체 인프라에서 콘텐츠와 스폰서 게시물을 모두 제공하고, YouTube는 googlevideo.com에서 동영상과 프리롤 광고를 함께 제공하며, X는 타임라인과 동일한 호스트명에서 프로모션 트윗을 제공합니다. DNS 수준 필터링으로는 이들을 구별할 수 없습니다.
실질적 의미: Casper는 일반적인 스마트폰 사용자가 일주일간 접하는 광고와 트래커의 약 80~90%를 차단합니다. 나머지 10~20%는 퍼스트파티 호스팅 방식이므로 다른 개입이 필요합니다 — 보통 DOM 렌더링 계층의 브라우저 확장 프로그램(Chrome/Firefox의 uBlock Origin, 내장된 Brave Shields, AdGuard의 Safari 확장 프로그램)으로, 이들은 렌더링된 페이지를 볼 수 있어 특정 요소를 숨길 수 있습니다. 최고 수준의 커버리지를 원한다면 두 계층을 모두 사용하도록 명시적으로 권장합니다. Casper는 브라우저 확장 프로그램이 놓치는 네트워크 계층을 커버하고, 브라우저 확장 프로그램은 DNS가 놓치는 DOM 계층을 커버합니다.
한계 2 — 일부 앱은 시스템 DNS를 완전히 우회합니다
점점 더 많은 앱들이 시스템 DNS 리졸버를 사용하지 않습니다 — 자체 DNS-over-HTTPS(DoH) 또는 DNS-over-TLS(DoT) 구현을 탑재하여 사용자가 설정한 DNS를 우회하고 Cloudflare, Google, 또는 개발사 자체 인프라에 직접 통신합니다.
Firefox는 기본적으로 이 방식을 사용합니다(Mozilla의 Trusted Recursive Resolver 프로그램). Chrome은 사용자의 기존 DNS 리졸버가 Google의 자동 감지 목록에 있을 때 이 방식을 사용합니다. 일부 인기 Android 앱(Brave, Discord, Signal, 여러 스트리밍 앱)은 하드코딩된 DoH 엔드포인트를 탑재합니다. 동기는 대체로 프라이버시입니다 — ISP 수준의 DNS 감시를 방지하기 위한 것이지만, 부작용으로 사용자가 설정한 DNS 필터링이 해당 앱에는 적용되지 않습니다.
실질적 의미: iOS에서는 이런 경우가 드물고 Apple의 NetworkExtension 프레임워크가 Casper에게 대부분의 앱 수준 DoH 시도를 가로채기에 충분한 훅을 제공합니다. Android에서는 상황이 더 복잡합니다 — 일부 앱은 저희가 볼 수 없는 경로로 호스트명을 해석합니다. Casper의 대응은 두 가지입니다: (a) DoH 우회 동작이 알려진 앱 목록을 공개하여 사용자가 필터 범위 밖에 무엇이 있는지 알 수 있도록 하고, (b) Android에서는 앱별 VPN 라우팅을 사용하여 특정 앱에서 필터링을 원하는 경우 중요한 트래픽을 시스템 DNS 경로로 강제 전환합니다. 이것이 Android의 더 유연한 VPN 아키텍처가 iOS보다 진정으로 유리한 몇 안 되는 영역 중 하나입니다.
한계 3 — CDN과 공유 인프라로 인해 테넌트별 차단이 불가능합니다
많은 웹사이트와 서비스가 IP 수준에서 호스트명을 공유합니다 — cdn-namespace.cloudfront.net은 동일한 Cloudfront 엔드포인트 뒤에서 수천 개의 다른 조직에 콘텐츠를 제공할 수 있습니다. 호스트명을 차단하면 그것을 공유하는 모든 이가 차단되고, 허용하면 모든 이가 허용됩니다. DNS 리졸버는 특정 요청이 어떤 테넌트를 향하는지 알 방법이 없습니다.
이것이 문제가 되는 가장 일반적인 경우: Google의 추적 엔드포인트를 차단하면서 기능적 엔드포인트는 허용하려는 경우. googletagmanager.com은 순수 추적용으로 안전하게 차단할 수 있습니다. 하지만 googleapis.com은 Maps 타일부터 Cloud Storage, Firebase Auth까지 Analytics 수집과 함께 모든 것을 호스팅합니다 — 차단하면 엄청난 수의 앱이 동작하지 않습니다. Casper의 기본 차단 목록은 전용 트래커 엔드포인트를 차단하면서 공유 기능 엔드포인트는 열어두도록 조정되어 있지만, 앱이 깨지지 않는 선에서 세분화할 수 있는 수준에는 상한선이 있습니다.
실질적 의미: 일부 추적 신호는 해당 호스트명이 정상적인 기능과 너무 얽혀 있어 차단할 수 없기 때문에 통과됩니다. 주요 사례들은 지원 문서에 정리해 두었으니 무엇이 빠지는지 확인하실 수 있습니다. 일부 앱이 깨지는 것을 감수하고 더 엄격한 차단을 원하는 사용자를 위해 "공격적" 프리셋을 제공합니다.
한계 4 — 암호화된 클라이언트 헬로(ECH)가 가시성을 변화시키고 있습니다
TLS 핸드셰이크는 역사적으로 SNI(Server Name Indication) 필드를 통해 목적지 호스트명을 노출했습니다 — DNS가 암호화된 경우에도 네트워크 관찰자는 어떤 사이트에 연결 중인지 볼 수 있었습니다. IETF의 ECH(Encrypted Client Hello) 표준은 이 마지막 조각을 암호화하며, 2025~2026년에 걸쳐 광범위하게 배포되고 있습니다(Cloudflare는 2024년 말 기본 활성화, Firefox는 안정적으로 지원, Chrome은 단계적 배포 중).
프라이버시 측면에서 이는 진정으로 좋은 일입니다 — ISP가 TLS 수준에서도 방문 사이트를 볼 수 없게 됩니다. DNS 수준 필터링에는 직접적인 변화가 없습니다: 저희는 TLS 관찰이 아닌 DNS 조회 자체를 기준으로 동작하기 때문입니다. 하지만 ECH는 사용자가 종종 인식하지 못한 채 리졸버 기능을 서드파티에 위임하는 암호화 DNS(DoH/DoT/ODoH/Oblivious DNS) 확산 추세의 일부입니다. 이러한 위임은 사용자가 설정한 필터링 도구를 우회하는 경로가 될 수 있습니다.
실질적 의미: 소비자 프라이버시 스택이 분산되고 있습니다. Apple의 iCloud Private Relay는 암호화된 트래픽을 Apple의 리졸버를 통해 라우팅합니다(사용자 DNS 우회). 일부 브라우저의 기본 DoH도 마찬가지입니다. ECH는 수동 관찰자로부터의 프라이버시에는 좋지만, 자신의 트래픽에 대한 사용자 주도권을 줄입니다. Casper의 대응은 사용자가 원하는 위치(자신의 필터링 리졸버)에서 원하는 네트워크 수준 가시성을 제공하고, 더 넓은 암호화 추세에 맞서는 것이 아닌 통합하는 방향으로 나아가는 것입니다.
DNS 수준 필터링이 여전히 강점을 발휘하는 영역
한계를 언급한다고 해서 DNS 필터링이 나쁜 선택이라는 의미는 아닙니다 — 단지 정직한 논의를 의미할 뿐입니다. 여전히 가장 깔끔한 개입 방식인 경우들:
- 내장 SDK에 의한 행동 추적. Facebook SDK, Mixpanel, Amplitude, Segment, AppsFlyer — 모두 DNS 필터링이 깔끔하게 차단하는 전용 트래커 호스트명을 사용합니다. 이것이 볼륨 기준으로 가장 큰 범주이며, 사용자들이 가장 막고 싶어하는 것입니다. Casper의 트래커 차단이 이를 직접 커버합니다.
- 모든 앱의 광고 네트워크. DoubleClick, AdMob, 주요 광고 네트워크 수집 엔드포인트 모두 전용 호스트명을 사용합니다. 이들을 차단하면 브라우저 확장 프로그램이 실행되지 않는 수많은 모바일 앱의 광고가 차단됩니다. 실제 효과를 확인해 보세요.
- 피싱 및 악성코드 도메인. DNS 계층에서의 실시간 위협 점수화는 공개 차단 목록에 추가되기 전 제로데이 피싱 도메인을 잡아냅니다. Casper의 위협 보호의 AI 분류기가 진가를 발휘하는 계층으로, 세 가지 실제 피싱 캠페인 분석에서 자세히 다루고 있습니다.
- 앱 간 핑거프린트 유출. iOS의 앱 추적 투명성(ATT)이 IDFA를 차단해도 앱은 여전히 핑거프린트 데이터를 유출합니다 — 하지만 어딘가로 전송해야 합니다. DNS 계층은 앱이 사용했을 식별자와 관계없이 유출을 잡아냅니다. ATT가 막지 못하는 것들에 대한 심층 분석을 참고하세요.
- OEM 및 운영체제 텔레메트리. Samsung Knox 분석, Xiaomi 클라우드, Apple의 분석 엔드포인트, Windows 텔레메트리 — 모두 OS의 기능 부분을 건드리지 않고 DNS 필터링이 차단할 수 있는 전용 호스트명을 사용합니다.
- 적대적 네트워크 보호(공공 WiFi). DNS 트래픽을 운반하는 VPN 터널은 로컬 네트워크에서 흐르는 다른 모든 것도 암호화합니다 — 그래서 DNS 필터링 혜택이 작은 경우에도 카페 WiFi에서의 암호화 혜택은 실질적입니다.
실제로 작동하는 2계층 모델
가장 철저한 보호를 원하는 사용자에게는 두 가지 보완적인 계층을 조합하는 패턴이 가장 효과적입니다:
- 네트워크 계층(DNS 수준 필터): 기기의 모든 앱을 커버하고, 전용 호스트명을 사용하는 트래커/광고/피싱 트래픽의 약 80~90%를 차단합니다. Casper가 여기에 위치합니다.
- DOM 계층(브라우저 콘텐츠 차단기): Chrome/Firefox의 uBlock Origin, 내장된 Brave Shields, 또는 AdGuard의 Safari 확장 프로그램. DNS가 정상 콘텐츠와 구별할 수 없는 Instagram, YouTube, X 등의 퍼스트파티 호스팅 광고를 잡아냅니다.
각 계층은 상대방이 커버할 수 없는 빈틈을 채웁니다. 두 계층을 함께 사용하면 95% 이상의 커버리지를 달성하며, 어느 하나만 사용하면 약 80%에 그칩니다. 저희가 이야기해 본 프라이버시를 중시하는 대부분의 사용자들은 정확히 이 조합을 사용하고 있습니다.
결론
DNS 수준 필터링은 소비자 프라이버시 위협의 가장 큰 부분 — 내장 SDK 추적, 광고 네트워크 유출, 피싱 도메인 해석, OEM 텔레메트리 — 에 개입하기에 적합한 위치입니다. 마법이 아니며, 모든 경우를 커버하지도 않습니다. 위에서 언급한 네 가지 한계는 실재하며, 이를 숨기는 벤더는 제대로 판매하지 않거나 해서는 안 되는 것을 파는 것입니다. 나머지 경우를 위해 네트워크 계층과 브라우저 DOM 계층을 함께 사용하고, 적대적 네트워크 암호화는 별도의 혜택으로 함께 얻을 수 있다고 생각하면, 2026년 소비자 위협 환경의 대부분을 커버할 수 있습니다.