Smart DNS는 VPN이 아닙니다: 그 DNS 설정이 실제로 바꾸는 것
Smart DNS 설정은 몇몇 서비스의 이름 조회 방향을 바꿉니다. 암호화된 터널이 아니며, 그 차이가 누가 당신의 트래픽을 볼 수 있는지를 결정합니다.
TV를 Smart DNS 리졸버로 향하게 하면 스트리밍 앱 하나가 동작하기 시작하고, 결론은 저절로 써집니다. 이건 더 싸고 더 빨리 설치되는 VPN이라고요. 그렇지 않으며, 그 차이는 사소한 게 아닙니다. 바뀐 것은 TV가 호스트 이름이 어디에 있는지 물었을 때 받은 답입니다. 바뀌지 않은 것은 모든 패킷이 여전히 당신의 집을 열린 채로, 같은 경로로, ISP가 이미 아는 같은 주소에서 떠난다는 점입니다. 신화는 DNS 설정이 터널이라는 것입니다. 현실은 더 좁고, 보면 알 수 있듯 더 유용합니다.
신화: DNS 변경은 트래픽 경로를 바꾼다
일반 DNS는 앱에 어디로 연결할지 알려 줍니다. Smart DNS 서비스는 선택된 호스트 이름에 제공자 자신의 인프라에 속한 주소로 응답하므로, 앱은 서비스로 직접 가지 않고 그곳으로 연결됩니다. 그다음 제공자는 그 하나의 흐름을 실제 목적지로 중계합니다. 기기에서 다른 것은 움직이지 않습니다.
TV나 콘솔에서 이 요령이 아예 통하는 이유가 그것입니다. 클라이언트도, 인터페이스도, 라우팅 테이블 항목도, 암호화 계층도 없습니다. 기기는 늘 하던 일을 그대로 합니다. 이름을 풀고 돌아온 대상에 연결합니다. 당신이 바꾼 것은 답이지 모든 패킷의 경로가 아닙니다.
이 이름은 무관한 DNS 프로젝트도 쓰므로, 이름에서 기능 집합을 추정하지 말고 제공자의 자체 문서를 확인하세요. 표준 Smart DNS 프로토콜은 없습니다. 한 제품의 범위는 다른 제품에 대해 신뢰할 만한 무엇도 말해 주지 않습니다.
실제로 무엇이 방향이 바뀌고, 무엇이 아닌가
기기별이 아니라 흐름별로 나열하면 그 차이를 쉽게 볼 수 있습니다.
| Flow | Steered by Smart DNS? | Why |
|---|---|---|
| A supported streaming hostname | Yes, usually | The resolver returns a provider address for that name |
| The same app's other hostnames | Only if the provider lists them | Steering is per-name, and lists are curated |
| Your browser, email, game downloads | No | Their names resolve to the ordinary destination |
| Traffic from devices not using that resolver | No | Nothing forces a device onto a particular resolver |
| Payload encryption | No | Unrelated to name resolution |
직접 볼 수 있습니다. 제공자의 리졸버에 호스트 이름을 묻고, 같은 이름을 공개 리졸버에 물어 보세요:
dig +short @<provider-resolver> example-stream.example
dig +short @1.1.1.1 example-stream.example답이 다르면 이름 계층에서 방향이 바뀐 것입니다. 답이 같으면 그 서비스가 그 이름을 다루지 않거나 기기가 그 리졸버를 쓰지 않는 것입니다. DNS 설정 오류처럼 보여 흔히 고장 난 계정으로 오해되는 실패입니다.
같은 냄새가 나는 두 번째 실패도 있습니다. 많은 제공자는 지금 쓰는 공인 주소를 기준으로 승인하므로, 주소가 바뀌기 전까지는 계정이 동작합니다. 통신사 수준 NAT 회전이나 그 위에 겹친 VPN이 그 주소를 옮기면, 이름 해석은 계속 성공하는데도 중계 서버가 당신을 거부합니다. 등록 항목은 접근 제어이지 독점적 출구의 증거가 아닙니다.
암호화된 DNS는 완전히 세 번째입니다
HTTPS를 통한 DNS와 TLS를 통한 DNS 는 기기와 리졸버 사이의 교환을 보호합니다. 질의를 암호화하고 인증하므로 로컬 네트워크가 그것을 읽거나 다시 쓸 수 없습니다. DoH는 이를 443 포트의 평범한 HTTPS 트래픽에 실어 나르며, 그래서 필터에는 웹 트래픽처럼 보입니다. 이것은 조회를 위한 기밀성 기능입니다.
서비스를 방향 짓는 것은 다른 기능입니다. 답 자체가 중개자를 가리킵니다. 한 제품이 둘을 동시에 제공할 수 있고 많은 제품이 그렇게 하지만, 하나가 다른 하나를 뜻하지는 않습니다. 조회를 암호화한다고 동영상 한 바이트도 다른 나라를 거친 적은 없습니다.
그래서 «암호화된 DNS»는 누가 당신의 질의를 읽을 수 있는지에 답합니다. 누가 당신의 트래픽을 볼 수 있는지에는 답하지 않으며, 새 출구 주소를 주지도 않습니다. DNS over HTTPS 명세 가 그 보호가 무엇을 덮는지에 대한 올바른 참조이며, 라우팅에 대해서는 아무 말도 하지 않습니다.
각 구성에서 누가 무엇을 보는가
Smart DNS에서는 리졸버가 당신이 찾는 이름을 보고, 제공자의 중계 서버가 자신이 나르는 연결을 보며, ISP는 나머지 전부를 어떤 주소에 언제 얼마나 연결했는지라는 열린 텍스트 구조로 여전히 봅니다. 방향이 바뀐 흐름에서는 콘텐츠가 목적지까지 TLS로 보호되므로 중계 서버는 읽을 수 없는 암호화 세션을 전달하지만, 당신이 연결했다는 사실과 어디서 얼마 동안인지는 볼 수 있습니다.
VPN에서는 터널 운영자가 당신의 트래픽과 목적지를 봅니다. 이는 하나로 집중된 신뢰 결정입니다. ISP는 한 종단점으로 가는 암호화된 흐름만 봅니다. 노출은 다르며, 자동으로 적은 것은 아닙니다. 어느 모델도 한 사이트가 열리는지로 평가해서는 안 됩니다.
속도는 라벨이 아니라 경로를 따릅니다. 선택적 중계는 무관한 트래픽을 우회로에 싣지 않을 수 있고, 이는 그렇지 않으면 모든 것을 터널에 넣을 기기에 실제 이점입니다. 그것도 보장은 아니며, 어떤 구성도 적극적으로 탐지하려는 서비스에 대한 영구적 접근을 약속하지 않습니다.
Smart DNS가 올바른 도구일 때
기기가 VPN 클라이언트를 아예 실행할 수 없을 때, 즉 TV, 콘솔, 네트워크 스택이 잠긴 셋톱박스일 때와 이름이 있는 서비스 하나만 중요할 때 정말 올바른 도구입니다. 그 기기의 모든 패킷을 터널에 넣고 싶지 않다고 의도할 때도 합리적입니다.
요구가 암호화, 기기 전체의 출구 주소, 또는 로컬 네트워크와 ISP로부터의 보호일 때는 잘못된 도구입니다. 그것들은 터널의 속성이며, 어떤 리졸버 설정도 그것을 만들어 내지 않습니다. 그리고 같은 기기에서 VPN을 계속 돌리면 등록 기반 승인이 깨질 것으로 예상하세요. 당신의 공인 주소가 이제 터널의 것이기 때문입니다.
이 결정을 순서대로 진행하고 참인 첫 줄에서 멈추세요:
- 트래픽이 암호화되고 기기 전체가 새 출구에 있어야 합니까? VPN을 쓰고, 연결 표시가 아니라 그 경로와 예외를 확인하세요.
- 터널을 만들 수 없는 기기에서 이름이 있는 몇몇 서비스만 필요합니까? Smart DNS가 비례합니다.
- 조회는 비공개이되 트래픽은 옮기고 싶지 않습니까? 그것은 암호화된 DNS이며, 위의 어느 것도 아닙니다.
- 제공자가 현재 주소에 의존합니까? 그것이 바뀌는 순간 장애를 예상하세요.