MasterDnsVPN은 이름만 보면 또 하나의 검열 우회 VPN처럼 보이지만, README를 읽다 보면 관심사가 조금 다르다는 걸 알 수 있습니다. 이 프로젝트는 TCP 트래픽을 DNS query와 response 안에 실어 보내되, DNS 터널이라는 좁은 운송로에서 낭비되는 바이트와 실패한 경로를 얼마나 줄일 수 있는지에 초점을 둡니다.
비교표에서 눈에 띄는 숫자는 전송 헤더 오버헤드입니다. README 기준 DNSTT는 KCP+Noise 조합으로 약 59바이트, SlipStream은 QUIC 기반으로 약 24바이트를 쓰는 반면, MasterDnsVPN은 커스텀 프로토콜과 ARQ로 약 5~7바이트를 제시합니다. DNS payload가 작고 MTU가 빡빡한 환경에서는 이런 차이가 단순한 미세 최적화로 끝나지 않습니다. 실제로 README의 10MB 로컬 다운로드 비교도 MasterDnsVPN 0.270초, SlipStream 0.978초, DNSTT 2.492초로 적혀 있습니다.
더 중요한 건 resolver를 대하는 방식입니다. 클라이언트 설정 샘플에는 8가지 resolver balancing strategy가 있고, least loss, lowest latency, hybrid score, loss-then-latency처럼 런타임 피드백을 쓰는 모드가 포함돼 있습니다. 패킷 duplication, setup packet duplication, stream-aware resolver failover, inactive resolver recheck, timeout-only resolver auto-disable 같은 옵션도 보입니다. 빠른 경로 하나를 찾는 도구라기보다, 여러 DNS 경로가 불안정하게 망가지는 상황을 기본값으로 둔 설계에 가깝습니다.
그만큼 운영 난도는 있습니다. 서버 쪽에서는 터널 서브도메인을 NS로 위임하고, UDP 53을 열고, 암호화 키와 도메인 설정을 맞춰야 합니다. 클라이언트 쪽에서는 resolver 목록, MTU, 압축, 로컬 DNS 캐시, SOCKS5 또는 TCP 모드 같은 선택지가 따라옵니다. 특히 XOR 암호화는 오버헤드가 낮은 대신 보안 강도가 낮다는 트레이드오프가 README에도 드러납니다.
그래서 MasterDnsVPN을 볼 때 핵심은 “DNS로 VPN을 만든다”는 발상이 아닙니다. 이미 오래된 아이디어입니다. 흥미로운 부분은 작은 헤더, packed control, resolver health, packet duplication, 작은 MTU 대응처럼 지루해 보이는 장치들이 실제 생존성을 만든다는 점입니다. 검열 우회 소프트웨어에서 체감 품질은 종종 거대한 프로토콜 이름이 아니라, 실패를 얼마나 자주 가정하고 얼마나 싸게 복구하느냐에서 갈립니다.